Independent survey · Verified August 2026
The AI agent governance landscape.
Roughly fifty projects claim to control what AI agents may do, using the same three words for very different problems. This survey orders them by institutional backing, tags what each one actually enforces, and separates what ships today from what is still one person's expiring draft.
Maintained by AgentAction, which is listed in the independent tier below. Verified against each project's own repository, license file, and package registry. Inclusion is not endorsement and this is not a ranking. Source and revision history on GitHub
Status
Much of what gets cited in this space has never run. Every entry below carries one of these.
- Live
- Generally available, in production use
- Preview
- Vendor-labeled preview or beta. Usable, expect breaking changes
- Early
- Pre-1.0 or thin adoption. Read the source before depending on it
- Draft
- A specification with no adopted standing
- Concept
- A published architecture with no implementation
- Dormant
- Real code, no meaningful activity in a year or more
01 / What the survey found
Six findings.
- 01
Access control and action authorization are different problems
The MCP authorization spec is OAuth 2.1 at the transport layer. It authorizes a client to reach a server at scope granularity, it is OPTIONAL, and STDIO transports are told not to use it. Nothing in it evaluates whether a particular call with particular arguments should proceed. ID-JAG, Entra Agent ID, Token Vault, Composio, Arcade, SPIFFE and Clerk AgentPass all answer who the agent is and how it gets a token. Clerk's own spec says the quiet part plainly: ongoing action-level control remains the service's responsibility.
- 02
History-dependent constraints had no home in policy engines, and AWS just changed that
Cedar, OPA/Rego, CEL and Cerbos have no operators for counts, sums, or time-windowed aggregates over prior events, by design. In August 2026 AWS open-sourced Dogwood, extending Cedar with metric first-order temporal logic. Its reference interpreter says outright it is not for production; the language ships inside Bedrock AgentCore Policy. So the capability is live if you are an AWS customer and a research artifact if you are not.
- 03
The enforcement point sits where the constrained party controls it
In almost every project, the gate runs inside the agent runtime, SDK, sidecar, or the operator's own gateway. Pomerium and Teleport do hand upstreams a signed JWT verified via JWKS, but the claims are subject, email, groups, roles. They prove who is calling, never what they were authorized to do. DPoP looks like it closes this and does not: it covers HTTP method and URI only, so a transfer of ten dollars and ten million dollars produce identical proofs. Payments is the real exception, and it ships.
- 04
Authorization is not proof of execution, and almost nothing links the two
Three claims that need to stay distinct get collapsed: that an action was authorized, that it executed, and that the intended outcome occurred within constraints. Pipelock is the honest illustration, carrying verdict, side-effect class and policy hash but no outcome field, and stating in its own spec that the receipt does not prove the action's effects were as described. Outside payments, authorized and happened live in separate systems nobody joins.
- 05
Delegation chains have no adopted standard
RFC 8693 defines nested act claims as the standard representation of a delegation chain, then directs that prior actors are informational only and are not to be considered in access control decisions. The standard way to represent a chain forbids using it for authorization. MCP's roadmap names sub-agent narrowing as open with its working group still forming. Microsoft AGT does implement monotonic narrowing at scale, but on a proprietary mesh scheme that does not cross organizational boundaries.
- 06
Human approval has no production-grade home at the gateway layer
Every project doing genuine per-call approve and deny is a desktop or local tool, and several are dormant. MCP Guardian has shipped nothing since April 2025. Microsoft AGT ships an in-memory approval queue by default. Auth0's asynchronous authorization via CIBA is the most production-ready path in the landscape, and it lives in an identity product rather than an agent gateway.
02 / The projects
Ordered by backing, not by preference.
Around fifty projects could appear here. These are the ones that change what you should conclude, one per distinct approach.
Tier 1
Hyperscalers and major public companies
The center of gravity. Between them these set the default policy languages and integration seams for the whole category.
Tier 2
Foundation-governed
Vendor-neutral governance, which matters when the thing you are adopting sits on the critical path of every agent action.
Tier 3
Funded private companies
Where most of the practical, deployable per-tool enforcement lives today.
Tier 4
Small companies
Smaller teams, and where several of the more interesting ideas are being tried first.
Tier 5
Independent and solo-maintained
Everything in this tier is early. Read the source before depending on any of it, including ours.
Model and conversation validation is a distinct, well-served category this survey does not try to cover. Guardrails AI is the most adopted, with NeMo Guardrails and Meta Purple Llama as the major vendor entries. They validate content. They do not authorize actions, have no identity model, and no receipt primitive. Comparing them head-to-head with anything above is a category error.
03 / Standards
What is adopted, and what is one person's draft.
IETF individual submissions are frequently quoted as though they were adopted work. Anyone can publish one, they expire after six months, and several of the most-cited here are written by parties selling an implementation.
The pattern is hard to miss: everything settled is about identity and transport, everything about action-bound authority is an individual draft or a concept.
04 / Conclusion
Gating became table stakes. Evidence did not.
At the start of 2026, a policy check in front of the tool call was a differentiator. It is now a feature of Microsoft's toolkit, of every serious MCP gateway, of two identity-aware proxies, and of a managed AWS service.
Cedar and CEL have emerged as the default policy languages, ext_authz as the default integration seam, and per-tool authorization tied to JWT claims as the default shape. Anyone building here should assume the enforcement layer is commoditizing and plan accordingly. The stateful layer moved this month, and the underlying temporal-logic research is fifteen years old and well understood. Expect it to spread.
What has not moved is the evidence layer. Every mature project stops at OpenTelemetry spans and structured logs, which the operator can rewrite. The gateways that do hand a downstream service something signed are attesting identity, not authority. Nothing outside payments links the authorization decision to what actually executed, and nothing constrains authority across a delegation chain in a way a relying party in another organization can verify. Three separate standards efforts have written down some version of this gap in the last six months. All three are individual drafts.
The industry has largely solved “may this agent connect,” is rapidly solving “may this call proceed,” and has barely started on “can anyone else prove what was authorized and what actually happened.”
Choosing something today
- Per-tool policy in front of MCP servers, in production now
- ToolHive for Cedar with tool arguments as attributes, or agentgateway for CEL under foundation governance
- Policy across a mixed estate with SDKs in several languages
- Microsoft Agent Governance Toolkit, accepting preview status
- Constraints over sequences, budgets, or session history
- Bedrock AgentCore Policy if you are on AWS. Otherwise you are assembling durable state yourself
- Content validation of model input and output
- Guardrails AI, or NeMo Guardrails for conversational rails. Different layer from everything above
- Isolation and credential brokering more than policy
- Docker MCP Gateway
- Protection against tool descriptions changing under you
- mcp-context-protector from Trail of Bits
- Human approval on individual calls
- Nothing production-grade ships this. Auth0 CIBA if you are identity-centric, Obot filters if you are building it yourself
- A receiving service that must verify authority itself
- AP2 if the domain is payments. Otherwise this is an open problem and every project attempting it is early
The useful question is rarely which tool is best, it is which layer you are missing. Several of these compose cleanly, and the most common mistake in this category is buying a second thing that does what the first thing already did.
What would close the gaps
- An interoperable, action-bound authorization receipt a receiving service can verify without a callback and without trusting the caller's infrastructure. AP2 demonstrates the shape; payments assumptions are baked into it.
- Execution closure, treating authorized, executed and outcome-achieved as three distinct claims linked by evidence rather than one log line.
- Cross-organizational delegation a relying party can verify recursively, which RFC 8693 currently instructs implementers not to attempt.
- A server-side approval queue with durable state, expiry and payload binding, as ordinary infrastructure rather than a desktop utility.
- Temporal policy outside a single cloud provider, given that the research is settled and only one production implementation exists.
None of these are blocked on invention. They are blocked on someone building the boring, interoperable version and enough parties agreeing to verify it.
Corrections welcome