The Model Never Needed to See Your Data

There is a sentence that appears in almost every AI governance framework written in the last two years: 'ensure PII is removed from prompts before they reach external models.' It is well-intentioned. It is also only half right.

Removing PII from a prompt does prevent that data from reaching an external provider. But it also prevents the AI from reasoning about the people and organisations your business actually works with. When you redact john@acme.com, you do not just protect John's email address. You make the AI functionally blind to the relationship that email address represents.

Today we are shipping Stateful Tokenization in OBEL v3.2.0. The premise is simple: the model never needed to see your data. It only needed a stable reference to it.

What we got wrong about the redaction model

The standard approach - replace PII with [REDACTED:EMAIL] - was designed to solve a specific problem: prevent customer data from appearing in an AI provider's training logs or fine-tuning pipelines. For that narrow goal, redaction works.

But enterprise AI usage in 2026 is not narrow. Lawyers are asking AI to review NDAs with named counterparties. Finance teams are asking AI to analyse transactions that involve account holders. Executives are asking AI to draft communications for named clients. In all of these cases, the AI needs to know about the entity - not the raw personal data, but the fact that an entity exists, has a relationship with another entity, and is referenced consistently across a conversation.

Redaction breaks this. When [REDACTED:EMAIL] appears three times in a thread, the AI has no way to know whether all three instances refer to the same person. The context graph that makes the AI's output useful is destroyed at exactly the moment you most need it - when the work is sensitive.

How Stateful Tokenization works

The idea is straightforward: instead of replacing john@acme.com with nothing meaningful, replace it with a stable, indexed token. [EMAIL_001]. The same email address, every time it appears, in every turn of the conversation. The AI can reason: [EMAIL_001] works at [ORG_001], their phone is [PHONE_001], they are the counterparty named in [EMAIL_002]'s proposal. The entire entity graph is preserved. The real values are not.

When the AI's response comes back referencing [EMAIL_001], OBEL re-hydrates it at the proxy boundary before the response reaches you. You see john@acme.com. The AI saw only a token. The external provider's logs contain tokens.

Try it. Type a message containing an email address or phone number and watch what happens at each boundary.

The token map - the encrypted record linking [EMAIL_001] to the real value - lives only in your organisation's vault, encrypted with your vault key using AES-256-GCM. OBEL cannot read it. The provider cannot read it. Only your proxy can, at re-hydration time.

The next AI security challenge: agentic data exfiltration

The June 12 incident established that AI model access is subject to geopolitical risk. That was the 2026 wake-up call for infrastructure. What we are watching now - and what most enterprise security teams have not yet fully modelled - is a different kind of exposure: data exfiltration through agentic AI systems.

The threat pattern looks like this: an autonomous agent is given broad access to internal systems - a CRM, a shared drive, a project management tool. It executes a task. Somewhere in that task, it retrieves data that includes PII, customer details, or commercially sensitive information. That data gets included in the agent's reasoning context and transmitted to an external model API as part of a subsequent tool call. The exfiltration is not intentional. It is incidental. It is also real.

This is not hypothetical. In OBEL's own Trace Patterns data across customer deployments, we see a consistent pattern: agents that connect to CRM systems trigger PII detection at a rate 4-6x higher than chat interactions. The data is not in the user's prompt - it arrives through tool results. Standard prompt scrubbing does not catch it.

Stateful Tokenization addresses this at the boundary. Whatever the agent retrieves - from its internal tools, from RAG queries, from API calls - it enters the LLM context as tokens, not as real values. The entity graph is preserved for reasoning. The data is not transmitted.

RAG poisoning: the challenge after that

Looking further out, the security challenge that is materialising in research but has not yet hit enterprise environments at scale is RAG poisoning - the deliberate injection of adversarial content into knowledge bases that retrieval-augmented generation systems will surface in response to legitimate queries.

The attack surface is novel because it does not target the model and it does not target the user. It targets the data layer that sits between them. A poisoned document in your knowledge base can cause the AI to generate subtly incorrect guidance, leak retrieval context from other queries, or execute injected instructions embedded in what appears to be a normal document.

OBEL already classifies and scrubs every retrieved RAG chunk before it enters a prompt - a deliberate architectural decision that differs from standard RAG implementations that treat retrieved content as trusted. The emerging work is in anomaly detection: identifying retrieval patterns that suggest a document is behaving adversarially rather than informationally. This is on our roadmap. If you are building knowledge bases at scale in regulated environments, it should be on yours.

“The next AI security breach will not come from a user sending a bad prompt. It will come from an agent retrieving a poisoned document and treating it as instruction.”

- Denis Bouton, ninthLABS

What changes in practice

For OBEL customers on STANDARD tier and above, Stateful Tokenization is available today in Settings - Governance - ARGUS-i. It requires vault configuration (your VAULT_ENCRYPTION_KEY must be set). Toggle it on - existing conversations are unaffected; new conversations use tokenization from the first message.

For organisations evaluating OBEL: the question we would ask you to sit with is not whether your current AI deployment handles PII scrubbing. It is whether your scrubbing approach preserves entity context for the AI, or destroys it along with the data. If the AI cannot distinguish between two different people whose emails have both been redacted to [REDACTED:EMAIL], your governance is degrading your outcomes.

• Tokenization is transparent to users - you see real values in all responses
• Secrets (API keys, passwords, tokens) are always hard-redacted - never tokenized
• Token maps are encrypted with your vault key - only your proxy can re-hydrate
• Audit logs record TOKENIZED_* events - compliance posture is unchanged
• Works across Chat, Spaces, and CLI proxy - same pipeline, same boundary