Back to BlogPerspective

Microsoft just validated the Agent Passport thesis

Five months ago I proposed a pre-execution middleware pattern for agent authorization in Microsoft's Agent Framework. Last month, Microsoft shipped the exact architecture. Here's why that's good news for the open standard.

4 min read
by Uchi Uchibeke

TL;DR

  • On October 26, 2025, I opened discussion #1701 in microsoft/agent-framework proposing an Agent Run Middleware pattern for pre-execution authorization, backed by APort passports. Zero replies.
  • On March 25, 2026, Microsoft published microsoft/agent-governance-toolkit. Same architecture. Same hooks. Same primitives.
  • Microsoft validated the market. APort provides the standard.

The timeline

October 26, 2025. I filed a discussion in Microsoft's Agent Framework repo. The proposal: a middleware that runs before any agent action, checks a verifiable passport, and either authorizes or denies the call. Concrete pattern, working code, link to APort.

It got zero responses for five months.

March 25, 2026. Microsoft shipped agent-governance-toolkit. GovernancePolicyMiddleware as an AgentMiddleware. CapabilityGuardMiddleware as a FunctionMiddleware. AuditTrailMiddleware. Pre-execution hooks. Ed25519 credentials. DID-based identity. Capability-based authorization. Full OWASP Agentic Top 10 coverage across five language SDKs and nearly twenty framework adapters.

If you put the October proposal next to the March release, the architectural parallel is hard to miss. Both pin the enforcement point at the same place: before the tool runs, not after.


What was proposed vs. what shipped

Proposal (Oct 2025) Microsoft (Mar 2026)
Agent Run Middleware (pre-execution hook) GovernancePolicyMiddleware (AgentMiddleware)
Tool/function-level guard CapabilityGuardMiddleware (FunctionMiddleware)
Signed decision receipts AuditTrailMiddleware
Verifiable agent identity DID-based identity, Ed25519
Capability-scoped authorization Capability-based authorization
Pre-action deny-by-default Pre-execution policy enforcement

Same shape. Same primitives. Same threat model.


Why I'm not mad

Microsoft does not ship infrastructure for categories that don't exist yet. They ship for categories the market has already validated. When Microsoft drops eleven packages, five SDKs, and nearly twenty framework adapters into a single repo on day one, it means the internal review concluded this is real, this is needed, and the cost of being late is higher than the cost of being early.

That is the strongest possible signal that pre-action authorization for agents is a category, not a thesis.

I have been saying that for two years. Now Microsoft is saying it too, in code, with a brand behind it. That helps every founder, every framework, and every security team that has had to explain why "trust the model" is not a control. The evidence is public: 879 adversarial attempts against APort's Vault CTF, 0% bypass under restrictive policy.

Validation beats credit.


What Microsoft does not have

Impressive scope. Real engineering. But look at the seams:

  • No open spec. agent-governance-toolkit is a library. There is no wire format anyone else can implement. If you want governance, you adopt the library.
  • No hosted registry. Identities are DIDs you manage. There is no public, lookup-friendly directory of who an agent is and what it is allowed to do.
  • Opaque DIDs, not portable passports. A DID is a pointer. A passport is a signed JSON document any service can fetch, cache, and reason about in under 100ms without knowing about Microsoft.
  • No upstream framework integration. The toolkit lives in Microsoft's repo. APort ships as merged PRs in DeerFlow, OpenClaw, and others. The integration lives where the agents live.

The library is the on-ramp. The standard is the road.


Standards outlast libraries

OAuth was not the first token library. OIDC was not the first identity SDK. OpenTelemetry was not the first tracer. In each case, multiple vendors built strong implementations, and then a small open spec quietly became the thing everyone aligned on. The libraries kept shipping. The spec is what made them interoperable.

The Open Agent Passport (OAP) is that layer for agent authorization. A signed, portable, verifiable document that any framework, any guardrail, any registry, and yes, any Microsoft middleware can consume. You should not have to pick a vendor to get governance. You should pick a standard, then pick whoever implements it best for your stack.


What to do now

If you build a framework: add an OAP verification hook at the tool boundary. It is a few hundred lines.

If you ship agents in production: put a passport in front of every action that touches money, data, or people. Use Microsoft's toolkit, use APort's guardrails, use both. Just stop trusting the model.

If you run security for an enterprise rolling out agents: ask your vendors which open standard their governance layer speaks. If the answer is "ours," that is your answer.

Microsoft validated the market. APort provides the standard. Both are good for the ecosystem. Pick the implementation you like. Adopt the standard either way.