LingCoreX.AI is preparing a plugin layer that sits before upstream model execution. The goal is to let teams shape requests with predictable controls such as prompt compression and sensitive-data masking, while keeping the core OpenAI-compatible integration path simple.
The plugin layer is designed for teams that want more control over what enters the model, how much context is consumed, and which compliance safeguards run before a request leaves their environment.
Placement
Pre-request
Plugins are designed to run before the final upstream payload is sent.
Goal
Higher control
Reduce avoidable token waste and avoid sending accidental secrets to the LLM.
Status
Partially live
Token compression is live now, while privacy masking and audit logging are the next capabilities being defined.
Compress long prompts while preserving the parts that carry reasoning value.
Token Compressor is designed for prompts that contain repetitive policy text, noisy transcripts, duplicated instructions, or long context blocks. The target outcome is a shorter payload with lower token cost and better context fit, while keeping the model aligned with the original task intent.
Use cases
Long-running agent sessions that accumulate repeated planning text and boilerplate.
RAG workflows where retrieved documents are useful but overly verbose.
Enterprise prompts with standard operating policies repeated on every call.
Guardrails
Reasoning stability remains a design goal, but no compression step can guarantee identical behavior for every prompt shape.
High-risk workflows should compare original and compressed outputs before production rollout.
Teams can choose whether compression is automatic, rule-based, or manually approved.
Conceptual example
Original request
SYSTEM: Follow the company policy below... [2,000 tokens of repeated governance text] USER: Summarize the latest incident report and propose three next actions.
Compressed request
SYSTEM: Apply the approved governance rules, privacy posture, and escalation policy from profile A. USER: Summarize the latest incident report and propose three next actions.
Redact secrets and sensitive identifiers before the payload reaches the model.
Privacy Masker is intended for teams that want a pre-send sanitation step. It scans the outgoing payload for values such as passwords, API keys, private identifiers, contact details, or internal credentials and replaces them with stable masks such as [Password], [APIKEY], or [Personal ID] before the request is forwarded upstream.
Use cases
Support teams pasting user incidents that may contain credentials or personal identifiers.
Engineering prompts that include config files, logs, or deployment output with embedded secrets.
Multi-tenant workflows where internal IDs should not leave the organization boundary in raw form.
Guardrails
Masking reduces accidental disclosure risk, but it does not replace a full data-classification program.
Teams should still define what must never be sent to a third-party model under any circumstances.
Pattern-based masking should be reviewed against real data formats so false positives and misses are acceptable.
Conceptual example
Original payload
User says their password is hunter2, API key sk-live-abc123, and Personal ID CN-556677 before requesting account recovery guidance.
Masked payload
User says their password is [Password], API key [APIKEY], and Personal ID [Personal ID] before requesting account recovery guidance.
Store every LLM exchange in your own bucket and review it with built-in audit tooling.
Team Message Audit routes the full request and response payload of every LLM call to an S3 bucket or Alibaba Cloud OSS bucket that the team owns and controls. Because LingCoreX does not retain user message data, teams that need long-term records for compliance or security review must supply their own storage. Once data is stored, the built-in audit tool lets authorised admins search prompt content, inspect raw logs, and analyse usage patterns across team members. Each audited request consumes 1 credit.
Use cases
Compliance teams that need a tamper-evident record of all LLM interactions for internal or regulatory audit.
Security reviewers who want to verify that no sensitive data is escaping through prompts.
Team leads who need visibility into what prompts members are sending to the model.
Guardrails
The storage bucket is configured and owned by the team — LingCoreX writes the log payload but does not have read access to the stored data.
If the target bucket is unreachable at request time, teams must define a fallback policy: block the request or pass it through without logging.
Access to the audit tool should be restricted to authorised admins to prevent unintended exposure of team member prompt content.
How it works
Without plugin
Request is forwarded to the upstream model. The response is returned to the caller. No message content is stored anywhere by LingCoreX.
With Team Message Audit enabled
Before the response is returned the full request and response payload is written to the team's S3 / OSS bucket. Admins can then open the audit tool to inspect prompt content and raw logs per team member.
After token compression, the same plugin layer can support more request governance without changing the application-facing API contract.