Obsidian vs Native Agent Controls: Cross-Platform Governance

AI agent access control is the practice of governing what an autonomous agent can do, on whose behalf, and inside which systems. Native tooling handles the first hop well. Microsoft Copilot's native governance covers agents built inside a Microsoft tenant. Anthropic Claude's native tooling governs its own agents and their tool calls. Within their walls, both do their job.

The problem starts at the wall. Every native control has a boundary, and it sits exactly where the vendor's platform ends. Copilot's audit trail stops where Copilot stops. Claude's tool-call visibility ends where the Claude session ends. When an agent leaves the platform to reach an API, a database, or a SaaS app, the native tool records the outbound call but not the downstream effect. That effect is where most of the risk lives.

This matters because agents do not behave like the users these controls were built for. A human logs in, gets provisioned, and inherits a role. An agent inherits a token, runs continuously, and acts across apps in sequence. Standard identity and access management assumes a person on the keyboard. Agent governance has to assume a non-human identity holding credentials and moving at machine speed. Native platform controls cover the platform. The vendor boundary is where oversight has to pick up.

Almost no enterprise runs a single agent platform. The typical footprint is four or five. One security team is responsible for Copilot in Microsoft 365, Agentforce in Salesforce, Bedrock in AWS, Vertex in Google Cloud, and either Claude or ChatGPT Enterprise for general-purpose work. Add n8n, Glean, or Moveworks and the count keeps climbing.

That produces four dashboards, five identity models, and six audit-log formats, with no single person who can say how many agents exist or what each one can reach. Assessments routinely surface hundreds, sometimes thousands, of agents that no one had inventoried, spun up by business teams who never filed a ticket. Each native tool shows its own slice. None of them shows the whole picture, and the whole picture is the only view that answers a board-level question about exposure.

The operational cost is not abstract. Every extra platform is another console to check, another log format to normalize, another place a shadow agent can hide. One control plane exists to collapse that sprawl into a single inventory and a single policy layer, so the team spends its time on decisions instead of stitching consoles together.

The hardest question in agent security is what an agent can actually do inside an app it connects to. Native controls see the agent's own configuration and its outbound calls. They do not see how the receiving app resolves those calls against its own entitlement model. That resolved reality is the effective access, and it is frequently broader than the configuration suggests.

Consider a Copilot agent built by a Salesforce administrator. The agent authenticates into Salesforce with the administrator's fixed credentials. A user who holds no Salesforce license invokes the agent, asks for a customer list, and receives it. Copilot's logs show the agent ran. Salesforce's logs show the administrator account made an API call. Neither log shows that a person with no right to Salesforce data just extracted it through an agent. The correlation nobody had, tying the invoker's identity to the credential the agent inherited and to the Salesforce entitlement that resolved, is the whole point. That is the difference between reading a theoretical configuration and reading runtime truth.

This is not hypothetical risk. The UNC6395 campaign against Salesloft Drift reached roughly 700 organizations by abusing the access a connected integration already held. The lesson generalizes: when an identity carries broad downstream access, its blast radius is the sum of everything that access touches, and a machine insider inherits that reach automatically. Native tooling sees its own agent act. It cannot see the effective access that agent inherits inside a downstream third-party app, which is where the damage lands.

Once you can see agents across vendors, you can write policy once and apply it everywhere. Rules like "no agent holding admin-level fixed credentials may be invoked by users below a set role" or "any agent whose creator has been disabled is quarantined" should not be re-implemented in four consoles. They should live in one place and reach across the whole agent surface.

Enforcement is where truth-in-labeling matters. Autonomous, runtime enforcement runs today on Microsoft Copilot and Anthropic Claude, the two platforms Obsidian acts on at runtime. For every other agent builder, including Agentforce, Bedrock, Vertex, Snowflake Cortex, ServiceNow, and n8n, Obsidian provides discovery, posture assessment, and risk scoring today, and the security team remediates through each platform's own controls with far better context than the native dashboard gives them. Autonomous enforcement on those platforms is on the roadmap, not a present-tense claim.

Obsidian does this without sitting inline. It is not a network proxy between your agents and your apps. It runs an "Intel Inside" decision-engine model: it reads configuration and runtime signals from each platform, correlates them with identity and entitlement context, and returns a decision, rather than routing traffic through a chokepoint. The result is that policy definition, risk scoring, and remediation workflow live in one plane, so a rule written once applies across whatever agent surface it can reach.

Precision matters more than ambition here. The table below states what native controls and a control plane each do today, not aspirational coverage.

When you evaluate any vendor in this space, ask the one question that separates marketing from reality: which platforms do you enforce at runtime today, versus which do you only inventory? The honest answer for Obsidian is that runtime enforcement is Copilot and Claude, and everything else is discover-and-govern for now.

The deciding factor is not company size. It is agent topology.

Native controls can be enough when all three of these hold:

• You run agents on exactly one platform.
• Those agents do not authenticate into third-party SaaS apps.
• Your agent count is small enough for genuine manual review.

You need a control plane when any one of these is true:

• You run agents on two or more platforms.
• Any agent authenticates into a downstream SaaS app on behalf of users.
• You cannot produce a single list of every agent, its owner, and the data it has touched.

A small team running Copilot agents that pull from Salesforce already has the effective-access problem, even with one platform, because the agent reaches across the vendor boundary. A larger team running one platform in true isolation may not. Match the tool to the topology: keep native controls where they cover the ground, and add a plane the moment your agents start crossing vendors or acting inside apps on behalf of people who could not reach those apps directly.