Runtime Data Security for Agentic AI: 6-Part Series
Part 1: Why Traditional DLP Breaks in Agentic AI (Last Week)
Part 2: Beyond Masking: The Challenge of Safe Data Reveal ← You are here
Part 3: Authorization Is No Longer Static (Coming Week 3)
Part 4: Why Simple Masking Kills AI Accuracy (Coming Week 4)
Part 5: Sensitive Data Is More Than PII (Coming Week 5)
Part 6: From Data Classification to Runtime Data Security for AI (Coming Week 6)
You can build a masking demo in an afternoon. Run a regex for credit card patterns, swap the match for XXXX, and ship it. The demo works, the compliance slide says “no PII sent to the LLM,” and everyone moves on.
That demo is fooling you by leaving things out. It works because the input is
a) clean (card 4111 1111 1111 1111),
b) because the only sensitive thing in it is a textbook PII pattern, and
c) because nobody downstream ever needs to use the value again.
Real agentic traffic breaks all three of those at once. The prompt actually says “my care’d endss 4111 pls charge the duplicate.” The truly sensitive line in the conversation is not a card number at all. It is “we’re acquiring Acme at 14x, keep it off email.” And after you mask anything, an agent still must act on it, which means something, somewhere, must decide when the real value comes back.
So “masking” is really three hard problems wearing one coat. Finding the sensitive data when the input is messy and when “sensitive” means far more than PII. Hiding it without wrecking the meaning the agent runs on, which often means rewriting, not just swapping. And revealing it selectively, by policy, to the one consumer that truly needs it. The regex demo solves none of these. The goal across all three is one line: protect data while preserving AI reasoning. This post is about why the third problem, controlled reveal, is where agentic data security really lives.
What You’ll Learn
- Why detection, not masking, is the hard front of the pipeline
- Why business context often has no pattern and needs semantic detection
- How controlled reveal works, and where reveal must be authorized
- Why reversible tokenization needs a secure mapping store, authorization, and audit
The Runtime Question
Every decision in this series reduces to the same six questions, evaluated at runtime as data moves between parts of the system:
User → Agent → LLM / Tool / MCP → Enterprise systems
│
Runtime Data Security Layer
(inspects every hop: Who · What · Agent · Why · Where · When)
- Who is asking (the user or caller)
- What data or business context is involved
- Agent is acting (which agent or sub-agent)
- Why it is needed (the task or purpose)
- Where the data is going (the destination)
- When in the workflow (the runtime moment)
The way of thinking that traps most teams
The common approach is “PII detection plus redaction.” Scan content for known sensitive patterns, swap them out, feel safe. This made sense in the world it came from: structured records and clean web forms, a short and well-known list of sensitive types (SSN, card, email, phone), and a person reading the masked output at the end. In that world, detection is a pattern match, masking is a string swap, and “done” means the person can no longer read the secret.
The trap is that this treats masking as the goal. It frames “protected” as “masked,” which assumes hidden data is the end state. In an agentic workflow, masked data is a middle state, not the end. Data gets masked so it can move safely through parts that do not need it, and then gets revealed at the exact spot where real work happens. A system that only knows how to mask is safe and dead in the water: it can summarize and sort placeholder data, but it cannot finish any action that touches the real world, because charging a card, updating a record, or sending a wire all need a real value at the boundary.
And before you even get to reveal, the two earlier steps the regex demo waved away turn out to be the hard ones.
Problem 1: finding the sensitive data is hard
Detection is the step everyone assumes is solved, and almost nobody has solved it for agentic input.
Real prompts are messy. Users type 4111-1111 1111111, swap digits, paste from OCR, mix two languages in one sentence. Worse, agentic data is split across the workflow: the first name shows up in turn one, the account number and last name comes back in a tool response, and the two only become identifying when combined three hops later. Exact-match and regex detection were built for clean values sitting together. They quietly miss the messy and the split-up cases, and every miss is a leak.
The deeper problem is that “sensitive” is not the same as “PII.” The patterns engineers reach for (card, SSN, email) cover the easy, regular, regex-friendly data. But the data that actually ends an enterprise relationship is usually business-confidential, and it has no pattern at all:
- Salary bands and individual pay
- Discount tables and the exact exceptions (“we gave them 20% to close the quarter”)
- M&A plans, deal multiples, target names
- Unreleased product roadmap
- Security architecture and incident details
- Internal investigations and legal strategy
There is no regex for “this paragraph gives away our acquisition plan.” Catching it takes understanding the meaning in context, which means detection in agentic systems has to read meaning, not just match patterns, and it has to do it on noisy input. That is a genuinely hard ML and systems problem, and it sits at the front of the pipeline where mistakes cost the most. A miss leaks. A false alarm over-masks and makes the agent dumb (the topic of the next post in this series). The precision/recall balance of your detector is really a leak-versus-usefulness balance, set before any masking happens.
Problem 2: masking without losing meaning is hard
Say you found the sensitive spans. Now you have to hide them in a way that lets the agent keep working, and the simple move (delete it, or [REDACTED]) is exactly the one that breaks the system.
Compare three transforms on the same record going into a prompt:
Blanket redaction: Customer [REDACTED] charged [REDACTED] on [REDACTED]. The model can no longer reason about the refund at all. Safe and useless.
Format-preserving, consistent tokenization: 4111 1111 1111 1111 becomes a valid-looking fake 5282 7282 7282 7282, and John Smith becomes Person_42 everywhere he shows up. The agent reasons normally because the data still looks and acts like data, and the consistency means it can still match “Person_42” across documents and turns.
Context-preserving rewrite: sometimes a token swap is not enough, because the meaning lives in the words around the value. John Smith from Goldman Sachs approved a 20% discount cannot be protected by masking the name alone. The firm and the figure are the sensitive part. The safe version is a rewrite: A senior executive at a major financial institution approved a strategic pricing exception. That is no longer find-and-replace. It is writing a faithful, lower-sensitivity version that keeps enough meaning for the agent to act, which is a much harder transform than masking a field.
This is the part the regex demo cannot reach. (The full treatment of context-preserving protection is the fourth post in this series.) The point here is that even “masking” is not the trivial step it looks like, and getting it wrong poisons everything downstream: a bad mask either leaks or makes the agent dumb. Protect data while preserving AI reasoning is the whole job, and most masking fails the second half.
Problem 3: selective unmasking by policy is the hard part
Now the real work. You have found the data well and masked it without losing meaning. The agent has done its reasoning on tokens. Something real has to happen, which means the real value has to come back, for one consumer, under policy, at the right moment. Watch the views split across a single ticket:
Ticket: "Customer John Smith (card 4111 1111 1111 1111) wants a refund
on the $240 duplicate charge from June 3."
Summary agent → the gist. Payment data: none. Name: stand-in fine.
Eligibility agent → amount, dates, history. Payment data: none.
Refund agent → payment token / transaction ID, to call the processor
(full PAN only in legacy/network cases).
Notification agent → real name + last 4 ("ending 1111").
Audit pipeline → none of it, just an event record.
Analytics job → aggregate only ("refund, $240"), no identity.
One ticket, six consumers, six different correct views of the same fields. The reveal decision is not per-field and not per-user. It is per-consumer-per-task: the payment credential is hidden from the consumers that do not need it and revealed, at the right level, only to the ones that do, and which view each gets depends on the task in front of it, not on the data’s sensitivity, which never changes.
This is genuinely hard for reasons that pile up. First, reveal is more dangerous than irreversible masking. Irreversible masking removes the raw value outright, so there is nothing to bring back. Reversible tokenization is different: it keeps a mapping from token to real value, and that mapping is now the most sensitive thing in your system. Anything reversible brings along a secure mapping store, an authorization service, and an audit duty. Second, the policy itself depends on context: “reveal the payment credential only into the payment call, only for the disputed transaction, only while the case is open” is not a fixed access list. Third, the thing asking for the reveal is an agent handling untrusted input, so the reveal gate is exactly what a prompt injection will aim at.
You have two broad options for the reversibility, each a real tradeoff:
Irreversible masking (hash or drop) is the safest and is right for values no one will ever need raw, like a free-text note going only to a summarizer. It removes the raw value with no way to recover it. The cost is that any workflow needing the real value becomes impossible, and you often cannot tell which ones those are up front.
Reversible tokenization keeps the real data out of the runtime path and replaces each value with a token, so agents carry only tokens and reveal is an explicit, gated, logged step. A robust version is high-entropy random tokenization backed by a secure mapping store: each token is a random surrogate with no recoverable link to the original, so the tokens leak nothing even as they spread across prompts, logs, and tools, while the real values stay in the mapping store.
Reveal is then driven by authorization rather than by holding a key: when a user, agent, and task are authorized for a value, the layer unmasks it for them, and otherwise it stays masked. The line is the authorization decision, which is what keeps a leaked token or a tricked agent from being enough to reveal. The cost is a mapping store that has to be available on every reveal and protected, with secure mapping, authorization, and audit, as the most sensitive asset in the system.
But the choice that outweighs both is where reveal gets authorized. Authorize it inside the agent and you have handed reveal authority to the part most likely to be talked out of it. A prompt that says “include the full card in your summary” is now aimed straight at your control point. Authorize it in a layer independent of the agent, deciding from caller, agent, task, and destination, and the agent never holds that authority. It asks the layer, and the layer reveals narrowly, putting the credential straight into the payment request body rather than back into the agent’s context. (Why authorization has to be runtime and context-based, not fixed, is the whole topic of the next post.)
The pattern that survives an attacker’s input: find sensitive data by meaning, mask while keeping context, keep agents on tokens, and reveal late, narrowly, and into the destination, owned by something the agent cannot talk its way past.
The failure modes to design against are concrete. Reveal-into-context, where the value lands in the prompt or reply and gets logged or echoed. Aim at the outbound payload instead. Over-broad reveal, where the token brings back the whole record. Scope it to fields. Inconsistent reveal, where unsteady tokens make it impossible to reason about what a reveal returns. And unlogged reveal, where you cannot prove afterward that the credential was unmasked only into the payment call for case 8842.
Real examples
Banking. The dispute agent reads tokenized card numbers and talks about “the charge on the card ending 1111.” When it submits the reversal, the control layer unmasks the real number straight into the card-network call, scoped to the disputed transaction, and logs the reveal against the case ID. The agent’s context never holds the real number, so a prompt injection asking it to “print the full card” has nothing to print.
Healthcare. A summarization agent runs entirely on stand-in charts and never triggers a reveal. The care-coordination agent, on the task of booking a follow-up, asks to reveal the MRN only, into the EHR write call only, for the patient in care only. Same data, two agents, one of which simply cannot reveal. Finding the sensitive data here is the hard part: “salary band” and “we’re planning to backfill the VP role” have no regex. Once found, a comp-analysis agent works on tokenized identities and real bands to compute distributions and never reveals identity, even when asked to “name the top five earners,” because the task does not authorize an identity reveal.
Enterprise search / RAG. Chunks are indexed with steady tokens. At query time the reveal decision runs per person: the sales rep’s results reveal customer names the contractor’s results keep masked. One corpus, decided per person and purpose at query time, safely serves many trust levels.
What to actually build
Invest in detection first and make it read meaning. Pattern matching catches the regular PII and misses the messy input and the business-confidential data that actually matters. Detection must understand meaning in noisy, split-up agentic traffic, and its precision/recall is a direct leak-versus-usefulness dial.
Mask to keep data useful, and rewrite when a token swap is not enough. Prefer format-preserving, consistent tokens over redaction, and be willing to write a faithful lower-sensitivity version when the sensitivity lives in the surrounding words.
Design controlled reveal as a first-class, policy-driven action. Pick your reversibility model (irreversible masking or reversible tokenization) and your authorization point together, up front. Bolting reveal on under a deadline is where leaks are born.
Reveal late, narrowly, into the destination, with authority outside the agent. Keep middle steps on tokens. Do the reveal as the last step before data enters the system that needs it, scoped to the field and the call, decided by a layer the agent cannot push around.
Log every reveal as the security-critical event it is. Who asked, which agent, which task, which destination, which field, and the decision. That log is your proof of least privilege and your incident-response base.
Protecto is one example of this pipeline: meaning-based detection that goes past PII into business-confidential data, context-preserving masking and tokenization, and controlled reveal authorized in a layer independent of the agent and logged per call. The point is the shape, not the product: find what matters, hide it without breaking meaning, and reveal it selectively under policy.
