What Is Embedded AI Governance

Embedded AI governance is the discipline of securing AI capabilities that a SaaS vendor ships inside a platform you already pay for. You did not train the model. You did not write the agent logic. And you usually cannot disable the feature without breaking a workflow the business depends on. That is the whole problem in one sentence: embedded AI governance covers the agents you inherited, not the ones you designed.

It helps to separate three categories, because confusing them is where most gaps start.

Embedded AI governance focuses on the first two rows. That is exactly the layer where security teams have the least tooling and the most exposure, because the model came pre-secured by the vendor and everything risky happens in how the agent connects to your data.

Teams often file AI risk under model risk: hallucination, bias, prompt injection. For embedded AI, that framing points at the wrong layer. The vendor already hardened the model. Your exposure is what the agent is allowed to do inside your apps once it runs.

Here is the mechanism, concretely. A business user spins up an agent in a vendor builder and wires it to a connector. That connector holds credentials, and those credentials frequently belong to the maker, not the person invoking the agent. Anyone who talks to the agent inherits the maker's authority inside Salesforce, SharePoint, or wherever the connector points. The industry name for this is maker mode, and it walks straight past the identity controls you spent years tuning for humans.

So the risk is not that the model misbehaves. The risk is that an agent acts as a machine insider, carrying credentials no insider-risk program was built to watch. Roughly 90% of agents run over-permissioned relative to the task they actually perform, and agents move on the order of 16x more data than a typical human user. Over-permission plus volume is what turns a convenience feature into blast radius.

Every embedded AI governance program reduces to three jobs done in order. Skip one and the program leaks.

Discover. Build a live inventory of every embedded agent across every platform. That means sanctioned agents, shadow agents built by business users, orphaned agents whose creators left the company, and the tool connections (including MCP servers) each agent reaches through. You cannot govern what you have never counted.

Govern. For each agent, correlate its activity to effective access inside the third-party app. Not the connector scope the console prints, but the real answer: which service account or token it runs under, which tables and objects it can read or write, and which actions it can trigger. Then flag the toxic combinations, for example maker mode plus org-wide reach plus sensitive data.

Enforce. Apply deterministic guardrails while the agent is running, because a probabilistic agent needs fixed rules around it. This is where truth-in-labeling matters. Runtime autonomous enforcement is available today for Claude and Microsoft Copilot only. For Agentforce, Snowflake Cortex, ServiceNow Now Assist, Moveworks, Bedrock, Vertex, and n8n, the job today is discover and govern, with runtime enforcement on the roadmap.

One design point that shapes the whole model: enforcement here does not mean sitting inline and proxying every request. Obsidian is not an inline gateway. It runs as a decision engine the platform consults, an Intel Inside pattern, so you get a runtime verdict without routing all agent traffic through a choke point.

Every vendor ships some governance surface for its own platform. Each one covers a single island, and none of them correlate across the seams where agents actually operate.

Picture a realistic chain. An agent in one vendor's builder calls a Salesforce connector, which fires a function in a cloud AI service, which writes a file to a shared drive. Four vendors, four consoles, four log formats, and no single view of what the agent did, on whose behalf, or which entitlements it exercised along the way. The action that matters lives in the gaps between apps, and per-platform consoles cannot see across a gap.

There is a deeper limit than fragmentation. A console reports theoretical configuration, the settings an admin typed in. It does not report effective access at runtime. That distinction is the entire reason embedded AI governance exists as its own category.

Theoretical configuration is what the console claims an agent should be able to do. Effective access is what it can actually do once every entitlement, connector, and inherited credential resolves inside the target app. The distance between those two is where machine insider risk lives.

Take a worked example. An agent shows a connector scope of "Read Contacts." On the config page, that looks tame. But the connector runs in maker mode against an admin's token. At runtime, the agent can query custom objects, financial records, and case history the admin can reach, and any lower-privileged user who invokes it inherits that authority. The console tool sees "Read Contacts." A runtime view sees an admin's full reach being exercised on behalf of someone who was never granted it.

That is the operational payoff of getting this right. Instead of chasing configuration signals with no evidence behind them, you correlate each agent's real activity to a specific service account and a specific set of objects and actions inside the app. One authority map, fewer fire drills, and evidence that generates itself rather than being reconstructed after an incident.

Regulators have moved faster on this than most enterprises planned for. The specifics differ by framework, so treat the details below as a prompt to verify against the current text of each, not as legal advice.

• The EU AI Act pushes enterprises toward maintaining an inventory of the higher-risk AI systems they use, and embedded features inside third-party SaaS fall inside that scope. Obligations phase in over time, so the practical move is to have the inventory ready.
• The NIST AI Risk Management Framework is voluntary in the United States but increasingly shows up in procurement and audit questionnaires. It expects documented risk management across the AI lifecycle, deployed embedded systems included.
• ISO/IEC 42001 is a management-system standard for AI, and certification asks for evidence of governance over the AI systems an organization operates.

The common thread is simple. An auditor asks which embedded AI is running, who owns it, and what data it can reach. Without discovery already in place, that question has no answer, which is why an inventory is now the first deliverable, not the last.