Agent Authorization and Access Control Just Became a Runtime Standard

In one week, Microsoft, Databricks, and Google shipped the same thing into their enterprise agent platforms. Not a smarter model. A runtime layer for agent authorization and access control, the place where an allow-or-deny decision gets enforced while the agent is running, not reviewed in a meeting before it ships. When three of the largest platform vendors converge on the same control pattern in the same news cycle, that is not a coincidence. It is a standard forming in public.

I work with Fortune-level enterprise clients architecting and building agentic frameworks, and the question I get most often is some version of "how do we govern this safely?" For most of the last two years the honest answer was a policy document, a review board, and a hope that the agent behaved the way the slide deck promised. That era is ending. Governance is moving into the runtime path, and the architecture decision is no longer whether to govern, but where your enforcement points live and who owns them.

What actually shipped this week

Strip the launch language away and the announcements describe the same shape.

Microsoft Foundry introduced an open trust stack built on two open-source projects. ASSERT converts written policies into measurable evaluations that run before production. The Agent Control Specification (ACS) is the part that matters most here: a portable runtime standard that enforces deterministic allow/deny governance at five lifecycle checkpoints, namely input, LLM call, state, tool execution, and output. It is framework-agnostic, working across LangChain, CrewAI, LiteLLM, and OpenAI. Microsoft is explicitly positioning this as a cross-vendor control pattern, not a Foundry-only feature.

Databricks expanded its Unity AI Gateway at Data + AI Summit 2026 to enforce contextual policy at runtime over models, MCP services, agents, and skills, with hard spend caps and routing decisions made in the request path through Unity Catalog.

Google's Gemini Enterprise Agent Platform pushed its Agent Gateway to secure and govern all agentic connectivity, with AI security findings now generally available and agent-runtime threat monitoring in preview.

Three different stacks. One pattern: the decision about what an agent is allowed to do is being pulled out of design reviews and pushed into the runtime, where it can be enforced on every step and logged for every action.

Why governance-as-a-document was always going to fail

The policy-PDF model fails for a simple reason. An agent does not read your governance doc. It reads its context window, calls a tool, writes to state, and returns an output, dozens of times per task, in milliseconds. A control that lives in a Confluence page cannot intervene at any of those moments. It can only describe what should have happened after something already did.

This is the same lesson the industry keeps relearning. Deloitte's 2026 survey found only 21% of organizations have a mature governance model for agentic AI, even as the majority expect meaningful agent use within the year. The gap is not that teams do not care about governance. It is that the only governance they had was advisory, and advisory controls do not survive contact with an autonomous system that acts on its own.

There is a structural detail that makes runtime enforcement non-optional. MCP, now the de facto integration layer with 97M-plus monthly SDK downloads and 10,000-plus active servers, is moving to a stateless protocol layer and still does not define multi-tenant data isolation or tenant-specific policy enforcement. The protocol deliberately leaves that to the application. So the boundary between an agent and the tools, data, and systems it touches is yours to build. If you do not own that boundary, no one does.

The Five-Gate Model for agent authorization

Here is the framework I give clients to reason about this independent of any vendor. An agent's runtime has exactly five points where an allow-or-deny decision can be enforced. Name them, decide who owns each, and you have a governance architecture instead of a governance hope. These map directly to the checkpoints the new platforms are standardizing on, which is the point: the gates are vendor-neutral.

1. The Input Gate. What is allowed to reach the agent? This is where you screen prompts and retrieved content for injection and untrusted instructions. Most teams defend the final output and leave the input wide open, which is backwards.

2. The Reasoning Gate. What policy context wraps the model call itself, which model is allowed for this task, and what data-loss controls apply to what you send it? This is where runtime DLP and model routing belong.

3. The State Gate. What can the agent read from and write to memory? This is the tenant-isolation boundary MCP refuses to define for you. An agent that can recall or persist across tenant lines is a breach waiting for a trigger.

4. The Action Gate. What tools and side effects is the agent authorized to invoke, with what scope, and under what spend cap? This is the highest-stakes gate, because this is where an agent stops reasoning and starts changing the world. Scope every permission tightly and cap spend per run here, not in a runbook.

5. The Output Gate. What is allowed to leave the agent, and what gets redacted or blocked? Your last chance to catch a leaked secret or a non-compliant response before a customer sees it.

The discipline is to be able to point at each gate in your own system and say who owns it and what it enforces. If you cannot, you do not have agent authorization and access control. You have intentions.

How does this change a build-versus-buy decision?

The convergence is good news and a trap at the same time.

The good news: a portable control standard means you are no longer choosing between governing your agents and keeping framework flexibility. ACS-style enforcement that works across LangChain, CrewAI, and OpenAI lets you standardize the gates while teams pick their own frameworks underneath. That is the right separation of concerns.

The trap: a gateway you adopt for convenience quietly becomes the most security-critical component you run. Every model call, tool invocation, and state access flows through it. If you buy one, evaluate it the way you would evaluate an identity provider, not the way you would evaluate a dashboard. Ask where each of the five gates is enforced, whether enforcement is deterministic or advisory, and whether the decisions are logged in a way you can audit. You cannot enforce what you cannot see, which is why decision-level observability and auditability is the prerequisite that makes any of these gates trustworthy rather than theatrical.

What I'd actually do

If you own an agent platform or an AI P&L, three moves put you ahead of the standard instead of behind it.

First, draw your five gates this quarter, before you adopt anyone's gateway. Map every place an agent in your stack takes an input, calls a model, touches state, invokes a tool, or returns an output, and write down what enforces a decision there today. The honest version of that map is usually mostly empty, and that emptiness is your roadmap.

Second, make the Action Gate and the State Gate non-negotiable. Those two carry almost all the blast radius. Tightly scoped tool permissions and a hard tenant-isolation boundary on state will prevent more incidents than any amount of output filtering. The runtime is where these decisions have to live, which is the same argument for treating the control plane as real architecture rather than glue code.

Third, treat governance as a measured loop, not a deliverable. Convert your written policies into evaluations that run in CI, the way ASSERT does, so a policy violation fails a build instead of surfacing in an incident review. Governance that only describes is half a system. Pair it with enforcement that can say no in the request path.

The vendors just told you where the industry is going. Agent authorization and access control is becoming runtime infrastructure with a portable shape, the same way identity and networking did before it. The enterprises that win the next 18 months will not be the ones with the strictest policy document. They will be the ones who can point at five gates, name the owner of each, and show the log.

---

If you're working through the governance and runtime decisions that move enterprise agents from pilot to production, I write a weekly breakdown of the architecture choices that actually decide whether agents ship. Subscribe to the newsletter for the next one.

Primary source: Microsoft Foundry, "Build agents you can trust across any framework with open evals and a control standard". Additional sources: InfoQ (Foundry runtime), Databricks (Unity AI Gateway), Google Cloud (Agent Gateway), WorkOS and AAIF (MCP state of play), Deloitte Insights 2026 (governance maturity).

This post covers Scale 1, the individual agent. Part of the enterprise AI agent governance pillar guide, which maps the four scales at which agent governance fails independently.