Runtime Data Security for Agentic AI — 6-Part Series
Part 1: Why Traditional DLP Breaks in Agentic AI ← You are here
Part 2: Beyond Masking: The Challenge of Safe Data Reveal (Coming Week 2)
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)
A customer support agent needs a payment reference, a token or transaction ID, to issue a refund. A summarization agent reading the same ticket needs none of it. A billing agent needs only the last four digits to match a transaction. A fraud agent needs the full credit card number, but only when a case is open and only for the account it is reviewing.
Traditional DLP sees one thing across all four: sensitive data, a 16-digit string that matches a card pattern. It makes one choice: block, redact, or allow.
Traditional DLP makes one decision. Agentic AI requires many decisions about the same data: the right answer depends on which agent is asking, what it is doing, which tool the data is about to flow into, and what point in the workflow we are at.
Traditional DLPs were built to answer one question: “is this sensitive?” Agentic systems must answer a different one: “who is asking, for what purpose, through which agent, into which tool, right now?” Those are not the same question, and no amount of pattern tuning turns one into the other.
This post is about why that is a difference in kind, not a difference in settings.
What You’ll Learn
- Why DLP and Runtime Data Security for Agentic AI are different categories, not different settings
- How an agentic workflow turns one decision into many about the same data
- Why the dangerous data crossings are internal, not at the network edge
- What “runtime context is the new perimeter” means in practice
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)
How DLP decides, and why it fit classic systems
DLP makes its decision in a specific way, and three things about that decision are worth naming, because they are exactly what changes later.
First, DLP decides from content alone. It scans bytes, matches them against patterns and classifiers, and acts on the match. Sensitivity is treated as a fixed property of the data: this is a card number, so apply the card-number rule.
Second, DLP sits at fixed, known boundaries. Email gateways, endpoints, network egress, cloud storage APIs. These are the chokepoints data passes through, and they are defined in advance.
Third, the actor is a person or a fixed application with a known identity, doing one understood thing.
These assumptions held because, in classic systems, engineers wired the data paths ahead of time. A refund feature was code that a developer wrote: read the order, call the payment API with a payment token, send a receipt to the email service, write a log line. The path was fixed, reviewable, and the same every time it ran. You knew which data went where because someone decided it in advance, and you could place a control at each known hand-off. In that world, “is this sensitive?” plus “is it leaving an approved boundary?” is a complete enough decision.
None of this was wrong. It is the right model for systems where the data flow is designed up front.
Why this breaks in agentic systems
In an agentic system, developers still define the building blocks: which tools exist, what permissions each one has, and the orchestration boundaries the agent runs inside. What they do not script is the exact path. Within those constraints, the agent reads the user’s prompt and selects at runtime what to do: which tools to call, which MCP servers or databases or APIs to pull from, and how to combine what comes back. A simple prompt might touch one source. A complex one might fan out across several, pull from each, and merge the results into a single context before acting. The same agent handles “refund this duplicate charge” and “summarize this ticket” with completely different data flows, chosen on the spot.
That is the shift. The set of tools and permissions is still designed up front, but the exact path through them is no longer fixed. It is selected per prompt, by the agent, at runtime.
Expand one refund request to see what the agent decides to do:
User: "Refund the duplicate charge on this customer's account."
→ Orchestrator agent reads the prompt and selects the steps:
→ lookup tool (MCP) → Postgres: pulls name, email, payment reference + last 4 (full PAN only in legacy records), address
→ LLM: reasons over that record to confirm the charge is a duplicate
→ payment tool (MCP) → Stripe: needs a payment token or transaction ID (full PAN only in legacy/network cases)
→ notification tool → email service: needs name + last 4 only
→ audit log → logging pipeline: needs none of it
A developer defined the available tools and their permissions, but did not script this exact sequence. The agent assembled it from the prompt, inside those constraints. Now walk the three DLP assumptions through it.
The decision cannot come from the data alone. The payment credential in the record never changed, but the right action changed at each step: keep it out of the LLM’s reasoning, hand the payment tool a token or transaction ID rather than the raw number, send only the last four to email, send nothing to the log, and surface the full PAN only to a fraud check that is authorized for it. DLP decides what to do by looking at the data itself, see a card number, apply the card-number rule. But here the same value moves through every step while the correct action is different each time. Looking at the bytes tells you it is a payment credential. It cannot tell you which of those actions to take. Only the context can: which agent, which task, which destination, what moment.
There is no fixed boundary to guard. In the wired-path world you put a control at each known hand-off. Here the hand-offs are selected at runtime and there are many of them inside a single request: agent to LLM, agent to each MCP server, MCP to database. The sensitive data is supposed to cross several of them. A control that blanket-blocks the payment credential from reaching the payment tool breaks the refund. A control that lets it pass everywhere leaks it into the LLM context, where it can be logged or cached, and into the email. The dangerous crossing is internal, and it does not look like data leaving an approved edge.
The actor is not a fixed person or app. The thing making the requests is an orchestrator agent that spawns sub-agents and calls tools, all under one session identity. “User Jane can see salary data” is true and beside the point. The real question is whether the newsletter-drafting sub-agent acting for Jane should pull salary data into a prompt. The same identity now does many different things in one session, so identity alone does not tell you what to allow.
Put together: because the agent selects the path at runtime, you cannot decide the right action by looking at the data alone, you cannot pre-place a control at a fixed boundary, and you cannot decide from identity alone. Agentic AI collapses the data perimeter. The line that matters is no longer a point on the network map; it is the moment of decision: this data, into this tool, for this task, for this agent, now. That is what “runtime context is the new perimeter” means in plain terms.
The core of it: where the old approach fails
Four concrete failures follow from runtime-decided flows.
Failure 1: classification is the input, not the decision
DLP classifies, then acts on the label. In agentic systems the label is necessary but nowhere near enough, because two requests for the same kind of data need opposite actions. You can detect “this is a card number” perfectly and still not know whether to reveal it, because the answer depends on the agent, task, and destination, none of which the classifier sees. Any design that stops at “we found PII” has solved the easy part.
Failure 2: the boundary is in the wrong place
The instinct is to control the exit, where data leaves your environment. But the most dangerous leak in the refund flow is internal: the full card number landing in the LLM context, where it may be logged, cached, reused in a later turn, or printed in a reply. The LLM call looks like a normal API request, so it never trips an exit control. By the time data reaches a network edge, the exposure already happened inside the workflow. The control has to move inline, into the path between each step.
Failure 3: removal breaks the agent
DLP’s safe default is to remove: black out the field, drop the value, swap in [REDACTED]. For a document going to a human, fine. For data feeding an agent, removal often breaks the job. Compare three ways to protect the same record before it enters a prompt:
Option A, blanket redaction. Customer [REDACTED] charged [REDACTED] on [REDACTED]. The model can no longer reason about the refund. Safe and useless.
Option B, pass-through with exit filtering. Let the agent see everything, scan on the way out. The agent works, but the card number is now in the context, in tool-call arguments, in traces, and in the model provider’s logs. You kept the function and lost the data the moment it entered the runtime.
Option C, context-preserving transformation. Replace the card number with a format-preserving stand-in that maintains the expected structure (a same-shape token, not a usable card) and the name with a steady stand-in (John Smith becomes Person_42 every time). The agent reasons normally because the data still looks and acts like data. The real number appears only at the one hop that needs it, the Stripe call, through a controlled reveal. Function kept, exposure cut.
Option C is not a DLP operation. DLP’s verbs are detect and block. This is detect, transform while keeping it useful, route, and selectively reveal. Different verbs, different design.
Failure 4: there is no idea of “for which task”
A person using a system is one identity doing one thing. An agent is one identity doing many things in a session, and the same agent should get different data depending on the task in front of it. The newsletter task and the payroll-fix task may run in the same process under the same service identity, but one must never touch salary data and the other must. DLP has no hook for this, because a payroll clerk is a payroll clerk all day. Task-scoped access is a new need, and it has to be checked per tool call.
The tradeoff: where does the inline control live?
Once the decision has to happen at runtime and inline, you hit a fork.
Put the logic inside the agent. Lowest latency, full context on hand. But every agent rebuilds security, policy scatters across teams, an agent bug becomes a security bug, and a prompt-injected agent is also your enforcement point. You made the thing you are trying to control responsible for controlling itself.
Put it in a separate runtime layer the data flows through. A control point sits between agents, LLMs, tools, and MCP servers, transforms data in the path, and decides reveal at each hop. Policy is central and auditable, agents stay simple, and the control point is independent of an agent that can be tricked by its own input. The cost is real: more latency per hop, another component to run, and the work of giving the layer enough context to decide well. The independence is the point. You would not let an app be the only judge of its own database permissions. You should not let an agent be the only judge of what data it may reveal.
There is no free option. Inline-in-agent is fast and fragile. Inline-as-layer is sturdy and adds a hop. Most serious systems land on the layer, because “the agent decides” is too risky once agents take untrusted input, which they always do.
Real examples
Healthcare. A summarization agent drafting a discharge summary needs the clinical story, medications, and timeline, but not the MRN, SSN, or insurance ID, and those must never reach the model provider. A care-coordination agent booking a follow-up does need the MRN to write back to the EHR. Same chart, two agents, opposite reveal decisions, decided by task and destination.
Banking. A dispute agent reading a chargeback should see masked card numbers (last four) to talk with the customer, and the full number only for the payment-network reversal that legacy rails still require, scoped to the disputed transaction. Blanket allow is too broad. Blanket mask breaks the reversal.
HR. An employee-helpdesk agent answering “how much PTO do I have left?” needs the asking employee’s own balance and nothing else. A comp-analysis agent needs salary bands across the company but not names. A newsletter agent should reach neither. The task differs, not the user or the data type.
Enterprise search / RAG. The same query from a sales rep and a contractor should return different reveals from the same chunks. Blocking everything at index time destroys the corpus. Deciding at query time, per person and purpose, keeps it.
What to actually build
Split detection from decision. Treat finding sensitive data as one job (“what and where”) and authorization as a separate runtime decision (“reveal, mask, tokenize, or block, given this agent, task, tool, and user”). Mixing them is the original DLP mistake.
Make the control point inline and independent of the agent. Put it in the path between users, agents, LLMs, tools, and MCP servers, with enough context to decide: caller, agent, task, destination tool. Do not let agents be the only enforcers over their own untrusted input.
Default to context-preserving transformation, not removal. Prefer format-preserving tokens and steady stand-ins so agents keep working. Save hard blocking for cases where no safe transform exists.
Treat reveal as the special, audited move. Masking is the cheap default. Unmasking is the sensitive act: scope it to the one tool call and task that needs it, and log every reveal with who, what, why, and when. The next post in this series is all about why safe unmasking, not masking, is the hard part.
Make the whole thing auditable by design. Every decision (what was found, masked, or revealed, for which agent and task) should leave a record. In agentic systems that trail is also your debugger and your incident-response base, not just a compliance checkbox.
Protecto is one example of this layer: it sits in the runtime path and makes per-hop detection, masking, tokenization, and reveal decisions from context. The point is the shape, not the product: a context-aware, inline, agent-independent decision point. You could build the pattern yourself. What you cannot do is get there by tuning a classic DLP rule set.
