Protect Sensitive Data From AI Agents

To protect sensitive data from AI agents, start with an uncomfortable fact: an agent reaches data the same way a trusted employee does, by authenticating as an identity the target system already accepts. There is no exploit and no broken lock. The agent presents a valid token, and Salesforce, Snowflake, or SharePoint hands back decrypted records because the caller looks authorized. Every agent is a machine insider carrying a bearer credential.

The problem is that most of these credentials sit outside the review process that governs human accounts. An agent built by a line-of-business user does not go through joiner-mover-leaver workflows. It gets a grant and starts acting.

The four ways an agent gets credentials

When someone builds an agent in Copilot Studio, Agentforce, or n8n, that agent has to authenticate to downstream systems. It does so in one of four ways, and each one is a distinct exposure:

1. Maker mode credentials. The builder's own OAuth token is embedded in the agent, so every user who invokes it effectively acts as the builder. A junior analyst can trigger an action that runs with an admin's Salesforce authority.
2. Service accounts. A non-human identity with static, frequently over-scoped permissions and no owner watching it.
3. Connector-shared credentials. One connector reused across many agents, so a single grant propagates into workflows nobody mapped.
4. MCP server tool calls. The agent invokes tools inside an MCP server that hold their own credentials, adding a layer the identity team never sees.

None of these trigger MFA. Non-human identities already outnumber humans by a wide margin in most enterprises, and each new agent adds to the count.

Where the data actually goes

Access is only half of it. Agents also move and retain data. A supervisor agent that forwards its full conversation context to a sub-agent has just performed a data-movement event that no legacy tool will flag, because nothing left the perimeter and no human copied a file. Working context lands in vector databases, conversation memory, and knowledge bases, then gets passed downstream during action chaining. The question no configuration page answers: for any given sensitive record, which agents, invoked by which humans, could reach it right now?

Configuration-based review tells you what an agent is set up to do. It cannot tell you what the agent can actually do once entitlements resolve across every connected app, MCP server, and identity provider in the chain. That gap between theoretical configuration and effective access is where agentic breaches happen.

Reviewing static policy with no runtime evidence is ghost chasing. You are inspecting a vendor's config screen while the real authority lives inside the third-party app, expressed as which service account touched which tables and which actions it was permitted to run.

The three places config and reality diverge

• Maker mode inheritance. The config shows a lightweight chatbot. Runtime shows that bot executing with an admin's credentials.
• Connector chaining. The config shows an approved connector. Runtime shows that connector talking to an unregistered shadow app.
• Cross-agent handoffs. The config shows two separate agents. Runtime shows Agent A delegating to Agent B and inheriting a broader scope than either was approved for.

"Configuration is not reality" is the shift a security leader has to internalize before any tooling decision makes sense.

Mistakes that keep teams stuck

A few habits keep programs in the config-review trap. Treating agents as software rather than identities. Extending existing DLP, which watches users rather than machine identities acting with delegated credentials. Relying on native platform logs, which are siloed and demand manual correlation that does not scale. Reviewing agents only at build time, when connectors and entitlements keep drifting after launch.

Discovery is the first stage and the one teams skip. It starts with a complete inventory across every AI platform, then correlates each agent to the identities, connectors, MCP servers, and data stores it touches. Skip inventory and every later control is theater, because you cannot govern what you cannot see.

The baseline reality is sprawl. Enterprises routinely find hundreds or thousands of agents already created before any security team was tracking them, many through platforms nobody sanctioned. Shadow agents are more dangerous than shadow apps because agents take actions. Apps just receive prompts.

What a working inventory covers

The last row is the one that matters most. Effective data access means resolving an agent down to the specific service account it uses and the objects and actions that account can reach inside the third-party app, not the scope the config page advertises.

Who needs an agent data program

Any organization running agents that can read from or write to systems holding regulated, confidential, or business-critical data. That spans financial services, healthcare, insurance, retail, technology, and public sector. The trigger is not company size. It is whether agents in your environment can reach data that a compliance framework, a customer contract, or a board expectation says must be controlled.

Governance means writing and enforcing policy against what agents can actually reach, verified continuously. Reachability-based governance answers one question for every sensitive dataset: which agents, invoked by which humans, can touch this, and through which credential?

This is the core shift. Instead of approving agent configurations one at a time, you approve or deny reachability paths. If a Copilot Studio agent can reach a Salesforce record labeled confidential through a maker mode connector, that path is the policy object. Not the agent. Not the connector. The path.

Reachability governance runs everywhere a platform exposes an API, which today means Copilot Studio, Agentforce, Bedrock, Vertex, Azure Foundry, n8n, ChatGPT Enterprise, Glean, Moveworks, and OpenAI. It needs no connector into your underlying app stack to do the mapping.

Sequence the work

1. Inventory every agent across every platform, shadow platforms included.
2. Map effective access, not theoretical configuration, for each agent.
3. Identify toxic combinations by name.
4. Scope down maker mode credentials and rotate embedded tokens.
5. Kill orphaned agents whose creator accounts are disabled.
6. Correlate invoker identity to agent authority on every sensitive action.

Encryption and masking sit below the access problem

Encryption alone will not protect sensitive data from AI agents, because the agent authenticates as an authorized identity and receives decrypted data by design. It still matters for storage and transit: AES-256 at rest for vector stores and knowledge bases, TLS 1.3 in transit, and envelope encryption with per-tenant keys on multi-tenant platforms. Masking is often the stronger control for agent contexts, because it replaces sensitive values with realistic substitutes before an agent ever sees them. Mask when the agent needs the shape of a value but not the real one. Encrypt when data must round-trip through the agent to an authorized human. The point stands either way: assume the agent will receive cleartext, and design controls above the encryption layer.

Governance is also your compliance evidence

Reachability data is what lets you honor a GDPR access or deletion request when data flows through agent memory and vector stores, and it feeds purpose-limitation and automated-decision obligations. If you cannot prove what an agent accessed on behalf of which subject, you cannot answer a data-subject request cleanly. Governed correctly, the evidence generates itself, which turns audits into a query rather than a fire drill.

Runtime enforcement means blocking or alerting on an agent action in the moment it happens, applying deterministic rules to a probabilistic system. Detection without prevention is expensive logging.

Truth in labeling matters here. Discovery and governance work across every supported platform. Autonomous runtime enforcement does not. Today it exists for Claude and Microsoft Copilot only. Agentforce, Snowflake Cortex, ServiceNow and Now Assist, Moveworks, Bedrock, Vertex, and n8n are discover-and-govern surfaces, with runtime blocking on the roadmap rather than shipping now. Any vendor claiming universal real-time blocking today is oversimplifying.

How the decision gets made

Obsidian is not a proxy and not an inline gateway. Enforcement uses an Intel Inside decision-engine model: the platform's own webhooks and native APIs call out to a decision engine that returns an allow-or-block verdict inside a roughly one-second window, so nothing has to sit inline in the data path. On Claude and Copilot targets, that verdict can stop an action. Elsewhere it produces governed evidence and alerts.

What deterministic guardrails handle well

• Blocking maker mode invocations by users who lack the underlying entitlement.
• Stopping org-wide agents from returning data carrying sensitivity labels.
• Cutting off action chains that would extend blast radius past policy.

What it costs

Agent security platforms typically price by number of agents, platforms covered, or seats, ranging from mid-five figures for smaller deployments to seven figures for global enterprises with multi-platform sprawl. Discovery and governance tiers generally cost less than tiers that add runtime enforcement, which is one more reason to start with the coverage you can get everywhere before paying for the enforcement you can only get on two platforms.

A toxic combination is several medium-severity factors stacking on a single agent to produce critical-priority risk. Individual signals rarely warrant a page. The stack does.

Prioritize alerts by combination, not by isolated signal. A single medium flag is noise. Four stacked on one over-permissioned agent is the thing that pages you at 2 a.m.

Speed is the difference

Agents cannot form intent, but they are readily used to move data through confused-deputy attacks, prompt manipulation, or malicious MCP tool calls. The UNC6395 campaign against Salesloft Drift reached roughly 700 organizations through a single agent path. When something does go wrong, the consequences track existing breach frameworks: regulatory penalties, contractual liability, reputational damage. What changes with agents is speed and forensics. They move data about 16x faster than humans, and native logs rarely capture the agent identity behind the action, so the runtime evidence you collected during governance is often the only record that ties the movement back to a service account and an invoking human.