Introducing app-native AI discovery and governance

The apps security approved last year are shipping their own agents this year. AI features arrive switched on with a product update, vendors add agents of their own, and users build agents directly inside the app. These agents sit right next to the data the app holds: customer records in Agentforce, source code in GitHub, email and files in Microsoft 365, people data in Workday.

When security approved those apps, the review covered the app’s permissions, data, and integrations. An agent that appears later usually doesn’t get that review. It may run on a person’s credentials or on a service account with broad access, and each app has its own admin console, so seven apps means seven places to look and no shared view of what the agents across them can reach. Obsidian brings those agents into one place: find them, map what they can reach, and govern them like the rest of the app.

Obsidian for app-native agents: find, map, and govern

Obsidian covers app-native agents with three capabilities that work together:

• Discovery: identifies the agents inside each app, including agents the vendor added, agents that arrived switched on, and agents users built, and adds them to the same inventory as the agents employees run on platforms like Codex, Claude Code, Cowork, Cursor, Microsoft Copilot, Amazon Bedrock, Google Vertex, and n8n.
• Access mapping: connects each agent to the identities it runs as and the tools and data those identities can reach.
• Governance: flags agent configurations that fall outside your standards and checks each app’s AI settings, then puts those findings next to the app’s other control failures in Continuous Governance.

Discovery: every agent, in every app, in one inventory

Obsidian reads each app through the connector it already uses for the app’s settings, identities, and activity. In GitHub, it finds GitHub Copilot agents, using the GitHub connector with updated permissions. In Salesforce, it finds Agentforce agents through the existing connector, with no permission changes. In Microsoft 365, it reads Microsoft 365 Copilot agents through Microsoft Graph and Entra ID, under the Graph consent customers already gave. Databricks, Snowflake, ServiceNow, and Workday agents come in through each app’s existing connector.

Every agent lands in one inventory, tied to its owner. If the same employee built agents in Salesforce and Microsoft 365, you see both in one place instead of in two consoles.

Access mapping: see how far each agent can reach

An agent’s risk depends on the identity it runs as and what that identity can do, and that is rarely visible from the agent’s own settings. An app’s console will list an agent, but not how far its identity reaches.

Obsidian’s foundation has always been third-party apps. Through connectors into more than 200 of them, it understands how each app’s data is structured and accessed, who can access what, and what they can do with that access. That lets Obsidian connect an app-native agent to its identities, tools, and data. An agent in Snowflake that runs as an identity able to read every schema becomes a finding for more access than its work needs.

Governance: fix agent findings the way you fix everything else

In Continuous Governance, an agent finding shows up next to the app’s other control failures, checked continuously rather than at the next review. Each finding carries the context to route the fix to its owner in Jira, ServiceNow, or another supported tool. Security teams use one process for an app’s settings and for the agents inside it.

Discovery and governance are one layer of protection, not the whole stack. They tell you which agents exist, what they can reach, and which configurations carry risk, but they don’t intercept an agent’s actions. The Obsidian Runtime Policy Decision Engine decides individual actions at supported enforcement points: a sidecar beside Claude Code, Cowork, and Codex, a webhook in Copilot Studio, the MCP Security Proxy for supported apps, and customer gateways through the Policy Decision API. An agent that works entirely inside an app may never pass through one of those points, so for these agents, finding them and narrowing their access is the control that applies. It’s also what keeps runtime decisions accurate, since a policy can only account for the agents and access security knows about.