Runtime Data Security for Agentic AI: 6-Part Series
Part 1: Why Traditional DLP Breaks in Agentic AI
Part 2: Beyond Masking: The Challenge of Safe Data Reveal
Part 3: Authorization Is No Longer Static
Part 4: Why Simple Masking Kills AI Accuracy
Part 5: Sensitive Data Is More Than PII ← You are here
Part 6: From Data Classification to Runtime Data Security for AI (Coming Week 6)
A user asks an enterprise AI assistant a normal question:
“Why did we lose the Acme deal?”
The agent does what agents do. It retrieves CRM notes, pricing history, discount approvals, sales leadership comments, and a couple of internal strategy docs, then combines them into one clear answer:
“Acme received a 28% discount exception, well above our standard enterprise pricing. Leadership approved it because they viewed Acme as a strategic logo ahead of the planned healthcare expansion.”
There is no PII in that answer. No PHI. No PCI. No name, no email, no card number. Every PII scanner in your stack would wave it through. And yet that one paragraph leaks your pricing strategy, your discount policy, your competitive positioning, and an unannounced expansion plan. For most companies that is more damaging than leaking a phone number.
This is the blind spot. We built data protection around the data that regulators named, and the most valuable enterprise data was never on that list. This post is about the other half of sensitive data, the business context that has no pattern, and why agentic AI makes protecting it both harder and more urgent.
What You’ll Learn
- Why your most valuable enterprise knowledge often contains no PII
- Why business context has no pattern and slips past DLP
- How agentic AI turns isolated facts into sensitive business intelligence
- A framework: identity-, business-, and context-sensitive data
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)
We built data protection around compliance
The first generation of data protection was shaped by regulation. Credit card numbers because of PCI. Health records because of HIPAA. Social Security numbers, emails, and phone numbers because privacy law said so. The category we call “sensitive data” is really “the data a regulator told us to protect,” and that framing quietly set the boundaries of every DLP and classification tool we use today.
There was also a practical reason this data came first: it is easy for a machine to find. PII has patterns. A card number is sixteen digits with a checksum. An SSN has a shape. An email has an @. These values have formats and known structures, so a regex or a trained classifier can spot them with high precision. Detection was tractable, the rules were clear, and compliance gave everyone a reason to fund the work.
None of that was wrong. It is the right place to start, and identity data genuinely needs protecting. The mistake is treating that list as the whole definition of sensitive, when it was only ever the subset that was both legally required and easy to detect.
The most valuable data has no pattern
Walk through what actually hurts when it leaks, and almost none of it is PII:
Pricing: discount tables, special pricing agreements, the negotiation strategy behind a deal. Product: the roadmap, launch timing, unreleased features. M&A: acquisition targets, valuation assumptions, who is talking to whom. Security: incident reports, known vulnerabilities, architecture diagrams. HR: compensation philosophy, succession plans, performance reviews. Legal: open investigations, litigation strategy, privileged opinions.
This is the data that moves a stock price, loses a deal, or hands a competitor your playbook. And it shares one property that breaks every pattern-based tool: there is no regex for it. No fixed format, no checksum, no @. “We plan to acquire Acme at 14x to block a competitor” looks like ordinary English. What makes it sensitive is not the shape of the characters. It is the meaning. You cannot match your way to it; you have to understand it.
Why agentic AI makes this worse
In traditional applications, this data stayed in silos. The CRM held CRM data, finance held finance data, the product wiki held the roadmap. Each system had its own access controls, and crucially, no single component pulled across all of them and synthesized a conclusion. The architecture itself limited exposure, not because anyone designed it that way for security, but because integration was hard.
Agentic systems erase those silos on purpose. Within the tools and permissions developers give it, an agent retrieves from several systems at runtime, combines what it finds, and summarizes it into a single answer. That is the whole value proposition. It is also exactly what creates the new risk.
Look at what combination does. On their own, three facts are unremarkable:
- CRM: “Acme is a strategic customer.”
- Finance: “Acme gets a 30% discount.”
- Product: “Acme is a design partner for the healthcare module.”
Each one, in isolation, is close to harmless and might pass any individual access check. Combined, they reveal your account strategy, your pricing exception, and an unannounced product direction tied to a named customer. The synthesis is the sensitive artifact, and it did not exist in any single source. The agent created it.
That is the line worth keeping: agentic AI turns isolated facts into sensitive business intelligence. The same capability that makes agents useful, pulling scattered context together into one coherent picture, is the capability that manufactures business-sensitive data on the fly, out of pieces that no existing tool flagged.
Why DLP struggles with this
DLP is good at exactly what it was built for. Show it an SSN, a card number, or an email, and it will catch them reliably, because those are stable patterns. The trouble is that business sensitivity is not a pattern. It is contextual, and it emerges from meaning that a value-level scanner cannot see.
Watch sensitivity appear as context accumulates:
- “20%” is nothing. A number.
- “20% discount” is maybe something, depending.
- “20% discount approved for Goldman Sachs to secure a strategic banking expansion” is highly sensitive.
The exact same “20%” is harmless in the first line and damaging in the third. No pattern distinguishes them, because the difference is not in the characters but in the surrounding meaning, the named customer, the approval, the strategic intent. A system that decides sensitivity by matching values will either miss the third line entirely or, if you make it aggressive enough to catch it, drown everything in false positives. Pattern matching cannot price context, and context is the whole game here.
Protecting business context while preserving AI reasoning
This is where the rest of the series connects, because the controls that protect identity data turn out to be the same controls you need for business context, just pointed at a harder detection problem. Protect data while preserving AI reasoning applies here exactly as it did for PII.
You need semantic detection: finding sensitive content by what it means, not by what it matches, so you can flag “an acquisition thesis” or “a pricing exception” that no regex would catch.
You need context-preserving protection: transforming that content so the agent can still reason, rewriting “a 28% exception for Acme ahead of the healthcare push” into “a significant pricing exception for a strategic account” rather than blanking it out and making the assistant useless. (Blog 4 in this series is entirely about why bad masking makes the agent stupid.)
You need dynamic authorization: deciding who and which agent, on which task, is allowed to see the combined picture, because the deal-review agent and the newsletter agent should not get the same answer. (Blog 3.)
You need controlled reveal: some agents and destinations need the full detail, most need a reduced view, and that decision is made at runtime per consumer. (Blog 2.)
And you need all of it at runtime, while the data is being retrieved and combined, not as an after-the-fact scan. By the time a nightly DLP job notices the Acme paragraph, the agent already said it.
A new way to categorize sensitive data
It helps to stop thinking of “sensitive data” as one bucket and split it into three, by the question each kind answers.
Identity-sensitive data answers “who is this?” PII, PHI, PCI. Names, records, card numbers. This is the regulated, pattern-friendly data we have always protected.
Business-sensitive data answers “how does this business operate?” Pricing, roadmap, M&A, compensation philosophy, security posture. No pattern, high value, mostly unprotected today.
Context-sensitive data, or relational context, answers “what does this reveal when combined?” Who approved the discount and why, which executives discussed the deal, how legal assessed the risk, what the account strategy is. This category barely existed before agents, because nothing routinely combined the pieces. It is the one agentic AI creates, and it is the hardest to detect, because the sensitivity lives in the links between facts, not in any single fact.
Most security programs cover the first category well, the second poorly, and the third not at all. Agentic AI inverts that priority, because it is best at producing exactly the category we protect least.
What engineers should build
Stop classifying only names, emails, and cards. Add pricing, compensation, roadmap, legal, and security content to what your detection layer recognizes. If your classifier has never been pointed at “is this a deal strategy?” it will not catch one.
Treat business-sensitive data as a first-class category, not an edge case. It deserves the same detection investment, policy coverage, and audit as PII, because for most enterprises it carries more downside.
Protect meaning, not just fields. The unit of protection is no longer “this 16-digit string.” It is “this paragraph reveals our acquisition plan.” That means semantic detection plus context-preserving transformation, so you reduce sensitivity without destroying the utility the agent needs.
Evaluate disclosure at runtime, per agent, task, and destination. The same retrieved context should produce different answers for different consumers. Decide that while the data is moving, not after.
Assume agents will combine information from multiple systems. Design as if every retrieval can be joined with every other one, because it can. The dangerous artifact is usually the combination, so the control has to see the assembled context, not just the individual sources.
Protecto is one implementation of this approach: semantic detection that extends past PII into business and context-sensitive content, context-preserving masking and tokenization, and runtime authorization and controlled reveal across the agent’s tool and MCP calls. The point is the shift in scope, not the product: protecting business context, not just identity.
The next generation is about context
The first generation of data protection focused on identity, because regulators named it and machines could find it. That work is necessary and it is not going away. But it was always half the problem.
In an agentic world, your most valuable secrets usually are not names, emails, or credit cards. They are the decisions, relationships, strategies, and plans that define how your business operates. Unlike PII, those secrets have no pattern. They do not announce themselves with a format or a checksum. They reveal themselves only through context, and agentic AI is a machine built to assemble exactly that context.
The next generation of AI data security has to move beyond compliance-driven protection of identity and learn to protect business context. That is a bigger problem than PII, and it is much closer to what actually keeps enterprise leaders up at night.
