Companies are increasingly building custom AI agents by renting an LLM from their cloud provider, adding data retrieval, letting it act, and orchestrating the whole thing. You can steer the rented model with prompts, but you cannot stop it from acting; only the orchestration around it can do that.

That orchestration is where the risk lives. What changes the risk profile from traditional software is not the agent's answer text, but its actions through tools: it retrieves data, commands external systems and moves data out. The risk surface is the tool call.

One agent's tool calls you can govern by hand. The problem, though, is that you never have but one agent. 100 agents, 100 chances for a gap in the policy, 100 chances for an attack.

On Governance Document and Standards

At that scale, a policy document is wishful infrastructure. It relies on every engineer, every team, reading it and applying it correctly and consistently on every tool call of their agents.

One attack vector looks like this: an agent reads an internal document, searches online and lands on poisoned data, then exfiltrates the internal document to an attacker's server.

This is no longer hypothetical. Microsoft 365 Copilot's "EchoLeak" (CVE-2025-32711) was a zero-click exfiltration, where a planted document made the assistant leak data on its own. The Mini Shai-Hulud worm (May 2026) pushed it further, into the supply chain, hijacking AI coding agents at scale to steal secrets off developer machines.

These incidents didn't happen for lack of an AI governance policy, but because nothing enforced it. Indeed, there's no shortage of AI governance standards to guide you on what to govern. NIST's AI RMF, ISO/IEC 42001, the EU AI Act, and OWASP's "Excessive Agency" all agree that agent autonomy needs least-privilege limits. The how at execution time is left to you, which is the whole point: governance has to sit where the action happens.

Governance at the Tool Call

Let's see what that looks like in practice. A minimal setup has four components:

1. a rented LLM from Microsoft Foundry,

2. an agent orchestrated by the Microsoft Agent Framework,

3. three tools: i. get_internal_document: retrieves internal documents, carrying their Microsoft Purview sensitivity labels, ii. send_email: sends email, iii. search_web: queries the public web.

4. and a policy engine reading a policy corpus, which we'll come to shortly. We built the example on the Microsoft Agent Governance Toolkit.

Each tool carries a capability tag. get_internal_document is tagged data_load. send_email and search_web are both tagged data_egress, meaning they can move data out of the agent's context.

When the agent loads a document that is public, nothing trips:

The document is labeled for public consumption, so the egress tools stay enabled and the email goes out.

Now we change one thing: the same campaign, still unreleased, now labeled "Highly Confidential."

The moment the agent loads the confidential document, the policy engine disables every tool tagged data_egress, so send_email and search_web both go dark. The agent still reads, summarizes, and answers; it just has no channel left to leak the document through, even if a user asks, or an instruction a poisoning attack slipped in earlier. This closes the attack from earlier: with egress revoked, the exfiltration step has no tool to call. And unlike the model it wraps, the policy engine is plain code, and you can’t prompt your way past code.

That revocation is blunt on purpose. One confidential document locks down all egress for the rest of the session, including sending information that would have been harmless. That is the trade we want: fail closed, so a leak needs a deliberate exception, not a default. Clearing the revocation means clearing the context back to the confidential load, so nothing from that document, original or derived, survives to leak.

Two things make this scale across a hundred agents. First, the policy engine is a shared service, not something each team rebuilds. Second, the rule never named send_email. It named a capability, data_egress, and acted on the tag. Every tool that can move data out carries that tag, so one rule covers all of them, the ones running today and the ones nobody has built yet. Governing a new egress tool is one line: tag it data_egress. From that moment it carries every rule the others do, without anyone reading the policy.

Under the Hood: the Gate and the Policy

That coverage runs through one real component. The policy engine in our example is thin middleware that does two jobs on every tool call. Before the call, it gates: it checks the request against the active policy and returns one of three verdicts:

Allow: The call proceeds.  
Deny: The call short-circuits with a message the agent can read back, the soft block you saw above.  
Require approval: The call pauses for a human to sign off before it goes through.  

After the call, it inspects the returned payload and updates the policy state, so a document's sensitivity label can tighten what the agent is allowed to do next.

The policy the gate reads is data, not code. It lives in signed, versioned YAML that the security team owns, separate from any application:

when_data_label_at_least: confidential 
revoke_capabilities:
  - data_egress 

‍

That is the whole rule behind the confidential-document demo. It is reviewable, diffable, and readable by a non-engineer, and it outlives the code it governs. New tools declare their capabilities in the same place, so the policy never has to learn their names.

There's a small caveat with policy as data: the policy corpus is still part of the policy engine software. It needs tests, owners, and version discipline, or it sprawls into an undocumented silo of its own. Treat it like code and the cost stays small: one corpus, reviewed and tested, that no application can quietly override. That is what makes it inheritable.

Complete the platform you already own

An inheritable layer is only worth building if there's a platform to inherit it from. In a Microsoft-heavy estate, most of that platform is already there. Entra Agent ID and RBAC set the baseline for what each agent can do. Purview labels the data and the information. What ties them together is a policy engine that reads both signals and enforces a decision for every agent in the company.

Owning that one layer is what turns it company-wide. A central platform team ships the policy engine, the policy registry, and the shared baseline once, and every AI team builds on it instead of rolling its own.

The way you make every team adopt it is to stop asking. You enforce adoption via build pipelines, where a missing policy engine integration fails the deploy the same way a failing test does: no integration, no ship. This way governance stops being a mandate teams can quietly skip and instead becomes a precondition for shipping at all. So the only agents that reach production are the ones already inheriting the governance controls.

How to start

You don't need the full platform at once, but can start in smaller pieces:

1. Start by integrating a policy engine in the agent's execution paths.

2. Move the policy into a shared registry and govern by capability, so one reviewed rule covers every team.

3. Enforce it in CI/CD pipelines and monitor the use in production.

This is the how beneath the what of governance standards.

An AI governance document was never going to govern anything. Move the control onto agents' tool calls, and the policy no agent reads becomes a control every agent carries.