Block Agent Data Exfiltration

To block AI agent data exfiltration, you have to watch what the agent does, not read how it was configured. Exfiltration by an agent rarely looks like an attack. It looks like a Tuesday. The agent uses its assigned credential, calls an approved API, retrieves records, and forwards them to a connected destination. Every step is authorized. The loss happens in the sum of those steps, which is why a prompt-level view alone never catches it.

The paths security teams have to cover share one property: the credential in use is legitimate.

• Over-scoped bearer tokens. The agent holds an OAuth token or service account with reach far beyond its stated job. It reads customer records, financial data, or source repositories because nothing tells it to stop. This is the common case, and it is why roughly 90% of agents sit over-permissioned.
• Maker-mode credential inheritance. A user with no direct access to Salesforce invokes an agent an admin built. The agent runs with the admin's authority, and the user pulls data they were never provisioned to see.
• Action chaining across apps. Agent A pulls from SharePoint, hands the payload to Agent B, which pushes it out through a connected tool. No single log captures the full chain.
• Prompt-based leakage to personal accounts. An employee pastes a customer list into a personal Claude account. The corporate log never sees it.

What data exfiltration means for a machine identity

Data exfiltration is the unauthorized movement of data out of a controlled environment. Agents cause it because they hold credentials, take multi-step actions, and connect to tools that most identity systems never audit as first-class identities. Three ingredients stack up: a machine identity holding a token or service account, effective authority inside an app that exceeds the invoker's own permissions, and an outbound path through a connector, webhook, or API destination. Traditional data-loss tooling looks for a human copying a file. It does not see a non-human identity making 400 bulk reads at machine speed and forwarding the results through an integration someone approved a year ago.

The patterns that turn access into loss

• The confused deputy. An agent with elevated permissions is steered by a low-privilege user into a high-privilege action.
• The orphaned agent. The creator's account is disabled, but the agent keeps running on inherited credentials. Nobody owns it, so nobody notices when it acts.
• The supervisor leak. A parent agent forwards its full context, sensitive fields included, to sub-agents that were never scoped for that data.

Detection tells you what happened. Blocking decides whether it happens at all. For agents, the gap between those two states is measured in seconds, and the volume that moves inside that gap is the whole problem. An agent that moves about 16x more data than a person does not give a SOC queue time to react.

Walk the timeline of a typical exfil event:

Detection produces expensive logging. It does not close the door.

Can an agent reach data without a human's permission

Yes, if you define permission strictly at the human layer. This is the machine insider problem. Human IAM is not agent IAM: you revoke a user's Salesforce access, and the agent they built still runs on the original credential. Session boundaries do not carry over either. A person's session times out; an agent's token often does not. The access was granted once, forgotten, and never scoped down.

The reachable exfil path is the intersection of who invoked the agent, what the agent can actually do inside each connected app, and which outbound destinations it can reach. That is not what the config file claims. It is what the runtime resolves after every entitlement is applied.

An example correlation makes the difference concrete:

• Invoker: an employee in the Sales org with no Finance access.
• Agent: built in maker mode by a Finance admin.
• Effective authority in NetSuite: read all GL accounts, export reports, under the maker's service account.
• Outbound path: a connected Google Drive folder shared with an external partner.
• Reachable exfil path: yes. A Sales user just pulled finance records through a Sales-facing agent to an external drive.

A vendor's configuration page shows the agent exists. It does not show that this specific invoker, riding this specific service account, can read those GL objects and land them in a partner-shared folder. Correlating the agent's activity to its effective access inside the third-party app, the account, the objects, and the actions, is the difference between a theoretical map and the runtime truth. Obsidian's Knowledge Graph joins those signals into one view so the reachable path is visible before anyone acts on it.

The block has to land at the moment the agent tries to act. Obsidian runs an "Intel Inside" decision engine: the AI platform consults it through native APIs and webhooks, and it returns a block-or-allow decision against deterministic rules inside a one-second window. Obsidian is not an inline proxy sitting in the traffic. The platform makes the call; the decision engine supplies the verdict.

The deterministic rules that matter for exfiltration:

• Block bulk reads above a threshold when the invoker lacks the underlying permission.
• Block outbound calls to unregistered domains.
• Block agent-to-agent context forwarding when the receiving agent has broader scope than the sender.
• Block maker-mode credential use when the invoker's identity falls outside the maker's authorization scope.
• Block tool calls from servers that are not in the sanctioned inventory.

Truth in labeling. Runtime block enforcement today covers Claude and Microsoft Copilot. Salesforce Agentforce, Amazon Bedrock, Google Vertex, n8n, ServiceNow Now Assist, and ChatGPT Enterprise are covered by discovery, effective-authority mapping, and governance workflows. Runtime enforcement for those platforms is on the roadmap, not shipping yet. State it plainly to your stakeholders so nobody assumes a block they do not have.

How to choose a tool to block AI agent data exfiltration

The category is new, and the products are not equivalent. Judge them on three questions. Does the tool map effective authority, or only list agents from a config read? Does it see tool calls at runtime, or stop at what a static review can enumerate? Does it demand a separate connector and a SaaS admin's sign-off per app, which slows every rollout and inflates total cost? Runtime visibility and identity correlation matter more than a long feature checklist, because the loss you are trying to stop only appears at runtime.

MCP servers are becoming the primary tool layer for agents, and they are the fastest-growing exfil vector because the tools inside a server are only visible at runtime. Every server exposes a set of tools, and each tool can reach any endpoint the server is configured to hit. A static review never sees them.

The pattern runs like this:

1. A developer installs an MCP server in Cursor or Claude Code.
2. The server exposes a tool that reads local files or hits an internal API.
3. The agent chains that read with an outbound HTTP call to a domain outside the sanctioned list.
4. Data leaves. No app log records the tool call.

The scale of connected-integration risk is not hypothetical. The UNC6395 campaign against Salesloft Drift moved through trusted OAuth integrations and reached around 700 organizations, and it did so with valid tokens rather than malware. An MCP tool talking to an unsanctioned endpoint is the same shape of problem one layer lower.

Closing it takes three layers in order: a server inventory that separates sanctioned from unsanctioned, runtime visibility into the tool calls themselves, and the ability to block an unauthorized call without becoming an inline chokepoint in the agent's traffic.

Report-only response sends a ticket to the SOC and waits. Autonomous response executes the block inside the agent's action window. For agents that finish an action chain in under ten seconds, only the second one closes the path.

Choose autonomous response when your agents operate at machine speed, when your ticket queue runs past 24-hour response times, or when regulated data covered by PCI, PHI, or financial rules is reachable by an agent. Choose report-only when you are still building the agent inventory, when the agents in question are internal read-only workflows, or when your compliance team has not yet approved autonomous decisions.

Most enterprises run both. Keep report-only on a new agent class for a two-week baseline, then flip to autonomous on the risk factors that matter most: maker-mode agents, over-scoped tokens, and any path that reaches regulated data.

The mistakes that keep the door open

• Treating agent security as a SaaS admin problem. It is a security team problem, and native platform logs are siloed and demand manual correlation.
• Buying detection without enforcement. Alerts pile up and data still leaves.
• Ignoring maker mode. It is the single highest-impact privilege-escalation vector in production today.
• Waiting for a full inventory before starting enforcement. Begin with the highest-risk agents now, and widen coverage as the inventory fills in.