Who makes the call decides what gets governed.
Most comparisons in this category turn on whether a vendor enforces anything at all. That is not the question here — Obsidian blocks executions inline and publishes the latency budget it does it in. The question is who initiates the decision, and what the decision is allowed to say.
What the product actually is
Obsidian began in SaaS security — posture management, identity threat detection and response, and shadow application discovery across the applications an enterprise already runs. The AI work is that platform pointed at a new kind of principal, and the lineage shows in the best way: the connector estate, the browser telemetry and the identity graph were all built before agents arrived, and agents inherited them.
- DiscoveryAgents are found without installing anything. Connectors read them from eight AI platforms, and a browser extension captures agent creation events directly in SaaS applications with no API integration at all. Nothing has to enroll and nothing has to register.
- OwnershipEach discovered agent is mapped to an owner, alongside its entitlements, connected apps, MCP servers and models, with the author of an agent resolved separately from whoever runs it.
- GovernanceWhat an agent is entitled to reach is compared against what it actually does, and the difference becomes a permission recommendation backed by behavioural evidence.
- Runtime enforcementFive deterministic rule categories — bulk-read thresholds, unregistered domains, agent-to-agent context, maker-mode credentials and server inventory — evaluated when an AI platform calls out, returning block or allow before the execution completes.
Where Obsidian Security is strongest
Four things, and two of them are rows we do not win.
- The browserTheir extension is generally available, analyses activity locally on the device so nothing sensitive leaves it, and blocks sensitive data in real time before it reaches a third-party AI tool. It is also how they see what connectors cannot: by their own measure, roughly a third of shadow SaaS never touches an API integration. BrowserShield is our equivalent and it is still early access, so this row goes to Obsidian and stays there until ours ships.
- The ecosystemHundreds of pre-built connectors, plus a community SDK that lets customers and partners build their own on the same platform. We are a focused platform rather than a marketplace, and score ourselves that way on every comparison we publish — this is the row where that choice costs us.
- Discovery, level with usTheir model is API connectors plus browser capture, with no SDK and no self-registration. That is the same standard we hold ourselves to, and the table prints it as a tie at the top of the scale rather than filtering it out.
- Commercial entry, level with usNeither product requires a prerequisite platform licence, and theirs starts free up to a thousand users. A team can be looking at real findings before anybody signs anything.
Their per-execution enforcement deserves credit too. When a policy fires, it stops the single execution rather than disabling the agent, which is the behaviour that makes enforcement survivable in production — the difference between a blocked action and a team whose assistant went dark mid-afternoon.
The verdict arrives by invitation
Obsidian's own architecture note is the clearest statement of the boundary, and it is not a criticism: the platform makes the call, and the decision engine supplies the verdict. They are not sitting in the traffic. The AI platform reaches out over a native API or a webhook, describes what is about to happen, and gets an answer back inside a one-second window.
That design buys real things. There is no proxy to deploy, no certificate to manage, nothing in the path to fall over, and no latency added to traffic that was never going to be blocked. It is a sound engineering choice and it explains why deployment is fast.
It also fixes what can be governed. A verdict that has to be requested only exists where something requests it — where the platform exposes a hook, and where that hook has been wired up. Today that is Claude and Microsoft Copilot. Agentforce, Bedrock, Vertex, n8n, ServiceNow and ChatGPT Enterprise are discovered and governed, with enforcement on the roadmap. An agent someone wrote in Python against a raw API has nobody to make the call on its behalf at all.
Monitor or block is two answers
The second half is what the verdict is permitted to say. Obsidian's policies are documented as monitoring or blocking an action, and the engine returns a block-or-allow decision. Both of those are useful, and having a monitor mode to run a policy in before you turn it on is genuinely good practice.
But most of the interesting cases in agent governance are not obviously allowed or obviously forbidden. An agent exporting a customer list is fine for the account team and not fine at 2am. A support assistant reading a ticket that happens to contain a card number should get the ticket, without the number. A bulk deletion is legitimate roughly once a quarter, and the person who can tell you which time this is has a phone in their pocket.
Agen answers those with five verdict types rather than two: allow, deny, step-up authentication, human approval, and a masked response that lets the action complete without the data it should not carry. The approval reaches the accountable person in seconds and the action waits. Nothing has to be pre-classified as forbidden to be handled safely, which is what keeps a policy from being loosened the first week it blocks something a team needed.
What the table does not claim
Twenty-six of the forty-one scored capabilities are not published, and the reasons matter as much as the scores. Masking and step-up authentication were dropped because they are the same single finding as the human-approval row — the runtime outcome set is block-or-allow — and counting one fact three times is how a table stops being believable. Delegated on-behalf-of access was dropped because brokering credentials is not something Obsidian claims to do, and scoring a vendor on a capability outside their stated scope is not a fair row. Gateway and network enforcement went for the same reason: their architecture page states the choice explicitly, and its consequence is already scored once. Connector breadth and the new-integration SLA were dropped on comparability — their connectors read posture from SaaS applications, ours are tools an agent calls, and those are not the same thing being counted. Shadow-agent discovery went because it is the same agentless architecture the discovery row already publishes as a tie.
Obsidian Security
