The entire market of tools built to govern AI agents shares the same architectural flaw: they're designed to catch a security event after the fact.
The reason is structural. Agents become dangerous not when they misbehave, but when two conditions are simultaneously true: they carry more permissions than their workflow requires, and they're reachable by someone who shouldn't have access to that data. No attack required. No anomalous behavior. No policy violation. We call this a toxic combination, and stopping one requires a control that fires at the moment of execution, before the action completes. That's runtime enforcement. Almost nothing on the market is built to do both.
This post covers what's broken, why your traditional security stack, including tools built specifically for agents, can't detect a toxic combination or stop one at runtime, and what it actually requires to do both.
To understand why the market is missing this, it helps to be precise about what a toxic combination, in the context of AI security, actually is. It forms when an agent:
Either condition alone is manageable. Both together is how a misconfigured agent becomes a breach.
Some of the most security-mature enterprises are already building governance models around this. Meta calls it a "rule of two": an agent can process untrusted inputs, access sensitive systems, or change state and communicate externally, but only two of those three can be true simultaneously. The presence of all three is a violation.
The fact that large enterprises are building this framework themselves tells you something: the vendor market isn't providing it. Detecting a toxic combination requires seeing both the agent's configurations, entitlements and the data labels it holds across every connected application, simultaneously. No current tool is built to do that and detection alone isn't enough anyway. The moment an agent is invoked, it acts. The only control that matters fires at execution, before the action completes aka runtime enforcement.
Obsidian research shows the average enterprise is running hundreds of agents, a number that has grown nearly 100x in the past year across our customer base. When teams actually look, 38% carry medium, high, or critical risk factors, most with no documented owner, several built by accounts that no longer exist, with live connectors to production systems and zero execution history. Every one of them a potential toxic combination, with nothing in place to stop one from completing.
None of the tools in your existing stack were built to detect a toxic combination or enforce against it at runtime. Here's why, one by one.
Identity security
Agents bypass your IdP altogether. Agents authenticate through OAuth tokens tied to service accounts, not through your SSO layer. No MFA challenge. No session context. No user identity to evaluate. The IdP reports clean because it never saw the activity. Service account credentials are issued once and persist indefinitely, outside normal session boundaries and review cycles. This isn't an attack path. It's how the system is designed. There's nothing here that fires at execution. For the security team trying to answer who authorized this agent and what it can access, the IdP has no record. That question goes unanswered every day, not just when something goes wrong.
And that’s before accounting for the apps your IdP has never seen. Okta’s Businesses at Work report says the average customer now uses more than 100 apps. Obsidian sees thousands in a typical enterprise environment. Every app outside the IdP’s federation is a blind spot. Agents operate freely inside all of them.
Network security
Your Zero Trust architecture governs user-to-application access. Agents operate on a different path: application-to-application, API-to-API, over trusted OAuth flows that never traverse the control points your network security stack monitors. The traffic looks legitimate because it is legitimate. An organization can be fully Zero Trust compliant and still have no visibility into what its agents are doing, let alone the ability to stop them mid-execution.
The Salesforce Drift breach made this concrete: customer data was accessed through a third-party AI application operating over trusted connections, inside organizations whose network security stacks never flagged it. Among those affected were Palo Alto Networks and Zscaler, two of the companies whose products are supposed to catch exactly this kind of exposure. The controls didn't fail. They just weren't watching the right layer.
EDR
EDR monitors process execution on managed endpoints, and some agents do run there. But the data they access and exfiltrate moves through SaaS platforms and cloud environments that endpoint controls never reach. EDR can see the process. It can't see what the agent did with the data once it left the device. For organizations with significant contractor populations on unmanaged endpoints, the starting point is already partial. And for agents running entirely inside third party enterprise applications and cloud infrastructure, there's no endpoint telemetry at all. EDR gives you one piece of the picture. The layer where agents actually cause damage is outside its view.
DSPM
Your DSPM maps where sensitive data lives. What it can't do is watch an agent moving that data in real time, attribute that movement to a specific agent or invoker, or tell you what a workflow did thirty seconds ago. When an agent touches sensitive data in your third party enterprise application, the action logs as a service account. DSPM sees the access. It has no way to know whether a human or an agent triggered it, which workflow ran, or on whose behalf. Attribution is gone before the investigation starts. For the analyst trying to answer a basic question about what touched this data and why, DSPM doesn't have an answer. That's not a breach scenario. That's a Tuesday.
None of these tools are failing. They do exactly what they were designed to do. Nobody designed them with agents in mind. And none of them can stop a toxic combination at the moment it becomes one.
So you turn to tools built specifically for AI agent security. A handful of niche vendors -- Zenity and Noma among them -- have emerged to fill this space, but their scope is narrow by design. They focus primarily on agent inventory, prompt monitoring, and alerting on suspicious tool calls: useful capabilities at the surface, but ones that only scratch at the edges of the problem. Some of them pitch runtime protection as a named capability, though in practice, it amounts to behavioral alerting with a different label.
But both are built on the same assumption: that governing agents means watching what agents do. Risk often doesn’t live at the agent layer alone, it lives inside the application the agent is connected to. The agent isn’t misbehaving, it’s authenticating exactly as designed, using OAuth tokens and service account credentials to act inside your third party applications. Those credentials are the attack surface. An adversary, or a misconfiguration, doesn’t need to compromise the agent; they just need to reach it. Once they do, the agent’s own credentials do the rest, moving through enterprise applications with legitimate, trusted access that no behavioral monitor is positioned to question.
That’s why visibility into third party applications isn’t a nice-to-have – it’s the entire gap. You cannot evaluate if a toxic combination exists without going inside those systems and mapping what each agent’s credentials can actually reach: which records, which datasets, which actions, in each application, for each potential invoker.
Obsidian research shows agents receive 10x more access than their workflows require, and nearly 2 in 5 carry medium, high, or critical risk factors from the moment they deploy, before taking a single action. None of that shows up in an issue queue built to catch what agents do. It only becomes visible when you look at what agents can reach.
Purpose-built tools watch the agent layer. The toxic combination lives underneath it.
Closing this gap requires two things working together: the ability to see both sides (agent side and the enterprise application side) of a toxic combination simultaneously, and the ability to act on that at the moment of execution. Both depend on the same foundation – deep visibility into the enterprise applications agents are embedded in.
The credentials agents run under carry entitlements across Salesforce, ServiceNow, Workday, Slack, and dozens of other applications. You can't evaluate whether a toxic combination exists by watching the agent. You have to go inside the applications themselves and understand what those credentials can actually do, in each system, against each dataset, for each potential invoker. Without that, you have half the picture. And a control built on half the picture can't stop a toxic combination before it completes.
That requires four things:
If you're evaluating agent security tools, these are the questions that matter:
If the answer to any of them is no, it's solving at the wrong layer.
Obsidian is built to answer all four.
Get answers to all four. Talk to Obsidian.
In the wake of the Salesloft breach, we’re offering a free risk assessment of your Salesforce environment to help identify potential exposure. Click here to request yours.
Take a breather! In under 6 minutes, our demo breaks down the risks AI agents bring to your SaaS environment and how you can get ahead of them.
We're offering a free AI agent risk assessment—check it out.
The biggest SaaS breach of 2025 started with a compromised third-party app. Attackers then exploited Salesloft-Drift OAuth tokens, which granted them access to hundreds of downstream environments. Obsidian researchers found the blast radius of this supply chain attack was 10x greater than previous incidents, where attackers infiltrated Salesforce directly.
Start in minutes and secure your critical SaaS applications with continuous monitoring and data-driven insights.
