Maintainer survey · Updated September 29, 2026

The AI agent governance landscape.

Agent identity, runtime isolation and action authorization solve different problems. Compare representative approaches by control focus and evidence, then explore the wider catalog by institutional backing. Availability, early implementations and proposals are labeled separately.

Maintained by AgentAction, which is listed in the independent tier below. The capability map, NVIDIA entries and affected findings were reviewed September 29, 2026. Other catalog entries and figures retain their August 2026 baseline; they were not all reverified in this update. Inclusion is not endorsement and this is not a ranking. Source and revision history on GitHub

Status

Maturity is separate from capability coverage. A reference design or early implementation should not be read as a production guarantee.

Live: Generally available, in production use
Available: Published software; not a certification of production readiness
Reference design: Announced architecture; verify component availability separately
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

Start here / The mental model

Four jobs in agent governance.

Which jobs does your stack cover, and where are you relying on assumptions?

Read across from controlling what may happen to establishing what happened. Read up from the execution environment to the business task. Products can contribute in multiple areas; placement describes a capability’s focus, not a product-wide score.

Govern actions

“May this refund proceed?”

Verify outcomes

“Did the intended refund happen?”

Bound access

“What can this agent reach?”

Monitor runtime

“What did the agent do?”

Documented available capability
Early / draft implementation
Announced reference design

Representative capabilities, reviewed September 29, 2026. Names link to sources. AP2 is scoped to payments; AgentAction is an early, self-listed implementation. Sentry reflects an announced reference design.

Inspect the detailed evidence and limitations

Go deeper / Capability evidence

Inspect the evidence.

Eight representative approaches, not a leaderboard. Coverage and maturity are separate. Select any cell to inspect its evidence.

Sources reviewed September 29, 2026. Documentation review, not independent certification. A mark may cover only part of a column: read the qualification. “Not established” means the reviewed source does not demonstrate it, not that it is absent.

Built in
Integration
Announced
Not established

Control focusMaturityOffering

8 of 8 approaches shown. Focus includes built-in, integration and announced coverage.

On smaller screens, scroll the map horizontally to compare all six control areas.

Control coverage by project — select a marker for qualification and source
Project / maturity	Identity & delegationWho acts, for whom, with what authority?	Runtime containmentWhat can the agent reach or execute?	Action authorizationMay this operation proceed? Inspect the qualification for payload granularity.	State & approvalsDoes history or required approval constrain this action?	Provider verificationCan the receiving service verify action-specific authority?	Execution & outcomesIs authorization linked to execution or independently observed outcomes? Logs alone do not qualify.
OpenShellNVIDIAAvailableOpen sourceReviewed 2026-09-29 Scope & limits Available software; deployment requirements still apply. Permission expansion is distinct from approval of an exact business transaction.	Built in Sandbox credentials and controlled provider-credential injection; not a portable delegation-chain standard. Read source ↗	Built in Separate trusted supervisor, filesystem/process controls and a mediated network path. Read source ↗	Integration API policy is native. Application-specific payload decisions can be added through supervisor middleware. Read source ↗	Built in Risky policy expansion requires review; this does not establish business-transaction budgets or single-use approvals. Read source ↗	Not established Extension tokens authenticate the caller; the reviewed contract does not establish provider-verifiable authority bound to an exact business payload. Read source ↗	Not established Runtime logs do not by themselves establish that a business outcome satisfied its intended constraints. Read source ↗
SentryNVIDIAReference designHardware referenceReviewed 2026-09-29 Scope & limits Announced September 28. BlueField-4 reference design; vendor claims are not independently benchmarked here.	Announced The announcement describes agent identity verification through DOCA. Read source ↗	Announced Independent DPU monitoring and quarantine outside the agent runtime. Read source ↗	Announced Granular tool/API access enforcement is described; exact transaction-payload semantics are not established. Read source ↗	Not established This source does not establish this capability. This is not evidence that the product cannot provide it. Read source ↗	Not established Attested telemetry is described, but not a receiving-service contract for exact-action authorization receipts. Read source ↗	Not established Monitoring and attested telemetry are not proof of a verified business outcome. Read source ↗
AgentCore PolicyAWSAvailableManagedReviewed 2026-09-29 Scope & limits Managed policy service. Dogwood's open-source reference interpreter has a separate maturity. This row does not score all AgentCore services.	Built in Policy sessions bind to authenticated principals; supported multi-hop flows propagate caller identity. Read source ↗	Not established This policy-service source does not establish OS isolation. AgentCore Runtime is a separate service. Read source ↗	Built in Cedar evaluates tool invocations and input parameters, including refund amounts. Read source ↗	Built in Temporal policies constrain action sequences, invocation counts and sensitive-read follow-up. Multi-hop support is limited to one account and Region. Read source ↗	Not established This source does not establish this capability. This is not evidence that the product cannot provide it. Read source ↗	Not established Session history supports authorization; an independently verifiable business-outcome receipt is not established by this source. Read source ↗
Entra Agent IDMicrosoft / Agent 365AvailableManagedReviewed 2026-09-29 Scope & limits Identity and lifecycle coverage. Do not interpret scoped access tokens as exact-action authorization receipts.	Built in Agent identities, ownership, scoped tokens and user/agent context anchor access and lifecycle governance. Read source ↗	Not established This source does not establish this capability. This is not evidence that the product cannot provide it. Read source ↗	Integration Identity and permissions supply access context; the application must enforce its business-action constraints. Read source ↗	Not established Lifecycle and Conditional Access controls do not establish per-job transaction history or payload-bound approval in this overview. Read source ↗	Not established This source does not establish this capability. This is not evidence that the product cannot provide it. Read source ↗	Not established This source does not establish this capability. This is not evidence that the product cannot provide it. Read source ↗
agentgatewayOpen-source gatewayAvailableOpen sourceReviewed 2026-09-29 Scope & limits This row covers documented standalone MCP authorization, not every enterprise extension or custom integration.	Integration Configure MCP authentication to supply validated JWT claims to authorization rules. Read source ↗	Not established This source does not establish this capability. This is not evidence that the product cannot provide it. Read source ↗	Built in MCP tool-name/target authorization. Tool arguments are documented as post-request access-log fields, not request-time authorization inputs. Read source ↗	Not established This source does not establish this capability. This is not evidence that the product cannot provide it. Read source ↗	Not established This source does not establish this capability. This is not evidence that the product cannot provide it. Read source ↗	Not established Tool result logging is documented; linked authorization-to-outcome verification is not established. Read source ↗
Auth0 AI SDKsOkta / Auth0EarlyOpen source + managedReviewed 2026-09-29 Scope & limits Open-source SDKs backed by managed Auth0 services. SDK maturity and service maturity are separate.	Built in User authentication and Token Vault connect agents to user-authorized services. Read source ↗	Not established This source does not establish this capability. This is not evidence that the product cannot provide it. Read source ↗	Integration Application integrations connect authorization and approval flows to tool execution. Read source ↗	Built in Asynchronous authorization supports human approval; it is not a general temporal-policy engine. Read source ↗	Not established This source does not establish this capability. This is not evidence that the product cannot provide it. Read source ↗	Not established This source does not establish this capability. This is not evidence that the product cannot provide it. Read source ↗
AP2Google agentic commerceDraftOpen sourceReviewed 2026-09-29 Scope & limits Protocol and reference code for payments. Coverage does not imply adoption as a general-purpose action standard.	Integration Payment participants integrate credential and identity systems with the protocol. Read source ↗	Not established This source does not establish this capability. This is not evidence that the product cannot provide it. Read source ↗	Built in Mandates express payment-specific intent and purchase authorization. Read source ↗	Built in Mandates capture user consent for payment flows; not a generic session-budget engine. Read source ↗	Built in Verifiable mandates carry payment authority across participant boundaries. Read source ↗	Built in Payment receipts provide transaction evidence; arbitrary business-goal evaluation remains outside this scope. Read source ↗
AgentActionSelf-listed by the maintainerEarlyOpen sourceReviewed 2026-09-29 Scope & limits Reference implementations and demos. Production use requires trusted context, complete mediation and durable atomic stores; no universal exactly-once guarantee.	Integration Consumes enterprise identity and trusted caller context; does not replace the identity broker. Read source ↗	Not established An embedded guard is not OS isolation. Infrastructure must prevent bypass of the action boundary. Read source ↗	Built in Guard checks tool, resource, amount and declared data flow before a wrapped callback. Read source ↗	Built in Approvals, budgets and replay state exist. Local in-memory state alone does not survive crashes or resolve uncertain provider commits. Read source ↗	Built in Reference JWS/JWKS middleware verifies scoped receipts. Production replay/revocation stores must be durable and atomic; the Express package is private while its contract settles. Read source ↗	Built in Intent evaluation separates execution and trusted observations; missing evidence can yield indeterminate. Quality depends on the supplied contract and evidence. Read source ↗

Built in describes the reviewed implementation, including early reference code. Announced describes a vendor claim in a reference design. Integration requires additional application or infrastructure work. Logs, identity tokens and action-bound receipts are evaluated separately. AgentAction is self-listed under the same criteria.

01 / What the survey found

Six findings.

01
Access control and action authorization are different problems
Identity and scoped access establish who can connect. Tool authorization must also decide whether this operation is allowed. Inspect granularity: agentgateway documents tool-name checks, while AgentCore Policy can evaluate input parameters. Neither the word governance nor an OAuth token establishes exact-payload authorization by itself.
Source for this finding ↗
02
Stateful authorization is already part of the landscape
AWS AgentCore temporal policies evaluate prior actions within a session, including sequence and invocation limits. Dogwood extends Cedar with temporal conditions. Keep the managed service separate from the open-source reference interpreter, and inspect session boundaries: supported multi-hop propagation is currently limited to one AWS account and Region.
Source for this finding ↗
03
Runtime isolation and provider verification protect different boundaries
OpenShell places enforcement in a trusted supervisor outside the agent workload. NVIDIA also describes Sentry as a watchdog in a separate hardware trust domain. These strengthen containment; they do not by themselves establish a receipt that a downstream business service verifies against the exact authorized transaction. An embedded SDK guard still needs infrastructure that prevents bypass.
Source for this finding ↗
04
Authorization, execution and outcome remain separate claims
An allowed action may fail, and a completed operation may violate the task's constraints. AP2 addresses payment evidence; AgentAction's early intent evaluator distinguishes execution from trusted observations and can return indeterminate. The useful comparison is what evidence each system binds and who verifies it, not whether a product has an audit log.
Source for this finding ↗
05
Identity propagation is not recursive delegation verification
AgentCore documents identity propagation for supported multi-hop flows, with account and Region limits. That is useful but does not establish a portable, recursively narrowing authority chain across organizations. Evaluate the trust boundary and supported deployment, rather than treating a delegation claim as universal interoperability.
Source for this finding ↗
06
Approval exists; its binding and durability need inspection
Auth0 offers asynchronous authorization, and OpenShell reviews risky permission expansion. A permission change is different from approval of one exact refund or deployment. Check approver identity, payload binding, expiry, atomic consumption and crash recovery before relying on a workflow's approval guarantee. A blanket claim that production approval does not exist is too broad.
Source for this finding ↗

02 / The projects

Ordered by backing, not by preference.

Wider catalog baseline: August 2026. NVIDIA entries reviewed September 29; the map above has its own dated evidence. Inclusion illustrates an approach, not a ranking.

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.

ProjectEnforcesStatusWhy it matters

OpenShellNVIDIA · reviewed September 29, 2026Contain, Gate, IdentityAvailableRuntime isolation, API/network policy and credential protection with a separate supervisor. Risky permission expansion receives review; custom business-action checks can use middleware. Part of Open Agent Safety Platform. Software availability is separate from Sentry hardware.Architecture Extension boundaries

SentryNVIDIA · reviewed September 29, 2026Contain, MonitorReference designAnnounced September 28 as an independent watchdog on BlueField-4 DPUs. Describes identity checks, access policy and attested telemetry. Availability and performance claims require deployment-specific verification; not scored as generally available software or proof of business outcomes.NVIDIA announcement

Agent Governance ToolkitMicrosoftGatePreviewIntercepts every tool call, message and delegation pre-execution. Policy in YAML, Rego or Cedar; SDKs in five languages. The only at-scale implementation of monotonic delegation narrowing, on a proprietary did:mesh scheme. Approvals default to an in-memory queue.

ContextForgeIBMRoute, GateLiveThe largest open-source gateway, GA since May 2026. A tool_pre_invoke plugin can block a call outright, so enforcement is real but plugin-authored: there is no built-in decision point yet.

AP2Google + FIDOReceiptDraft spec, working codeThe counterexample to findings 3 and 4. SD-JWT mandates verified by merchant, PSP and credentials provider against actual cart parameters before settlement, with receipts binding authorization to execution to outcome. Payments only.

Docker MCP GatewayDockerRoute, GateLiveShips inside Docker Desktop. Real pre-execution blocking via a before-exec interceptor where a non-zero exit blocks the call, but you write the policy as a script.

CedarAWS, CNCF SandboxEngineLiveFormally verified authorization language with Lean-proven semantics. The substrate under AgentCore Policy, Microsoft AGT, ToolHive and cMCP. Deliberately stateless.

InvariantSnykGate, ValidateLiveIntercepting proxy evaluating contextual rules on tool calls both before and after execution. The clearest example of semantic, content-aware gating rather than identity or RBAC gating.

DogwoodAWSEngineEarly as OSS, Live in AgentCoreThe most important recent development here, and the sharpest live-versus-theory case. Extends Cedar with temporal logic over prior events. The reference interpreter says it is not for production; the language ships in a GA AWS service.

Tier 2

Foundation-governed

Vendor-neutral governance, which matters when the thing you are adopting sits on the critical path of every agent action.

ProjectEnforcesStatusWhy it matters

agentgatewayLinux Foundation / AAIFGate, RouteLiveRust data plane for MCP, A2A and LLM traffic. CEL policy over MCP method invocations plus ext_authz delegation. Contributed by Solo.io to the Linux Foundation, not CNCF. 300+ contributors.

Envoy AI GatewayCNCF / EnvoyGate, RouteLivev1.0.0 in June 2026. Per-tool authorization policies matched on backend and tool name, filtered by JWT scopes with CEL. Under proposal to move to AAIF as Agent Router.

Open Policy AgentCNCF, GraduatedEngineLiveThe reference general-purpose engine, used for agent authorization by embedding it as the decision point. Has no agent-native primitives.

AuthZEN Authorization API 1.0OpenID FoundationSpecLive, Final Jan 2026The only mature open standard on the action-authorization side. It standardizes the question, not the risk model. Newer drafts targeting MCP tool authorization remain drafts.

Tier 3

Funded private companies

Where most of the practical, deployable per-tool enforcement lives today.

ProjectEnforcesStatusWhy it matters

ToolHiveStacklokGateLiveThe strongest per-tool authorization in open source. Cedar policies evaluate the call before it reaches the server, using tool arguments, JWT claims and MCP annotations such as readOnlyHint and destructiveHint as attributes. No approvals, no receipts.

TeleportTeleportGate, IdentityLiveAllow and deny lists on MCP tools with globs and regex, enforced pre-execution. Mints a signed JWT the upstream verifies via JWKS, carrying identity claims only. AGPL-3.0 core.

PomeriumPomeriumGate, IdentityLiveAn mcp_tool policy criterion matching tool names by exact, prefix, suffix or list, tied to user identity. Same signed-assertion pattern as Teleport, same identity-only limitation.

LiteLLMBerriAIRoute, GateLiveDB-backed budgets per key, user, team and customer with session-level caps, so it is one of the few places durable state actually lives. Two caveats: budgets fail open without a DB connection, and an open issue reports guardrail hooks never firing on the MCP path.

ObotObot AIGate, RouteLiveFilters are the real hook: an MCP filter server or HTTP webhook returns accept, reject or mutate per tool call before execution. The closest thing to a do-it-yourself approval queue.

Auth0 AI SDKsOkta / Auth0Identity, GateLive, SDKs pre-1.0Asynchronous authorization via CIBA plus push notification is the most production-ready human-in-the-loop approval in the landscape.

Clerk AgentPassClerkIdentityDraftShort-lived, single-use, holder-bound passes scoped per task. Included for one sentence in its spec: ongoing action-level control remains the service's responsibility. Not security-audited, not for production. Unrelated to this project despite the name.

Tier 4

Small companies

Smaller teams, and where several of the more interesting ideas are being tried first.

ProjectEnforcesStatusWhy it matters

nonoalways-furtherGateEarlyCapability-based agent runtime with fine-grained policies, Rust, 88 contributors. The largest project in this tier by a wide margin and under-covered relative to its size.

open-edisonEdison WatchGateEarlyDeny by default: unknown tools are rejected outright. Tracks the lethal trifecta of private data access, untrusted content and external comms across a session and blocks once all three are live. One of the few genuinely stateful risk models outside AWS. GPL-3.0.

mcp-context-protectorTrail of BitsGateEarlyTrust-on-first-use pinning of server config, blocking calls when tool descriptions change without approval. This is integrity enforcement, a distinct problem: it answers whether the tool changed, not whether this user may call it.

MCP GuardianEQTY LabGateDormantThe clearest per-call human approve and deny implementation, and the evidence for finding 6: six releases, all between February and April 2025, nothing since.

cMCPAgentTrust.ioGate, ReceiptEarlyEvaluates Cedar policies inside a hardware TEE and emits attested claims, genuinely removing operator trust from the signing path. But the MCP server verifies nothing, and they say so. Well-engineered, essentially unadopted.

Tier 5

Independent and solo-maintained

Everything in this tier is early. Read the source before depending on any of it, including ours.

ProjectEnforcesStatusWhy it matters

PipelockIndependentGate, ReceiptEarlyCapability separation: the agent holds secrets but no network, Pipelock has network but no secrets. Emits mediator-signed receipts verifiable offline with no account or server. Also the most honest artifact in this survey.

AegisIndependentGate, ReceiptEarlyThe most complete single-project feature match to gating plus approvals plus receipts: SDK auto-patching across nine Python frameworks, HTTP and MCP stdio proxies, hash-chained audit with optional Ed25519 signing, kill switch. Backed by an academic paper. Single maintainer.

permit0IndependentGate, ReceiptEarlyNot Permit.io; different org, no affiliation. Its whole thesis is pre-execution adjudication: risk scoring across nine dimensions, session-aware cross-call pattern detection, tier-based routing to human approval, ed25519 audit. Human reviewers can only narrow a decision, never widen it.

agent-passport-systemIndependentIdentity, Gate, ReceiptEarlyNarrowing-only delegation per hop, Ed25519 three-signature chains, cascade revocation, and the only project found putting idempotency at the authorization boundary. Conceptually the most complete design in this tier; its academic framing is self-published, not peer-reviewed.

AgentActionSelf-listed by the maintainerGate, Receipt, IdentityEarly, demos liveGates the exact tool call against policy, approvals, budgets, idempotency and data-flow rules, then issues a JWS authorization receipt with a public JWKS endpoint, plus Express and FastAPI middleware so a receiving service can verify authority before it mutates. Records the provider result and replays it on an identical retry instead of executing twice. Runs as a local TypeScript guard or a hosted runtime with approval queues and scoped single-use grants, and integrates behind Envoy ext_authz and agentgateway ExtMCP rather than replacing them. Solo-maintained and thinly adopted; the enterprise gateway direction on this site is product direction, not shipped.Refund and approval demo Production deploy demo npm: @dinpd/ai-agent-guard

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.

DocumentBodyStatusWhat it actually is

RFC 8693 Token ExchangeIETFRFCDefines nested act delegation chains, and forbids using prior actors for access control

RFC 9449 DPoPIETFRFCProof of key possession. Covers HTTP method and URI only, not the request body

RFC 9943 SCITTIETFRFCAppend-only transparency over already-signed statements. Notarization, not a pre-execution gate

AuthZEN Authorization API 1.0OpenID FoundationFinalThe enforcement-point to decision-point envelope. The only settled standard on the action side

MCP authorizationAAIFLive specOAuth 2.1 profile at the transport layer. OPTIONAL, HTTP-only

A2A 1.0Linux FoundationLive specAgent interop. No identity primitive, no delegation semantics

OAuth Identity Chaining (ID-JAG)IETFWG adopted, IESG approvedCross-trust-domain token exchange. Identity, not action

Transaction TokensIETFWG consensus, awaiting write-upScoped to a single trust domain by design

COSE ReceiptsIETFWG draftMerkle inclusion proofs. Proves this was logged, not this was authorized

WIMSE workload identityIETFWG drafts, no RFC yetArchitecture stabilizing, nothing normative shipped

AP2Google + FIDODraft, code worksPayment mandates as verifiable credentials. The one place provider-side verification ships

draft-chen agent authz use casesIETFIndividual draftThe grant-layer versus execution-layer gap analysis. Well argued, no standing

draft-schrock EP authorization receiptsIETFIndividual draftProvider-verified action receipts with declared enforcement classes

draft-niyikiza attenuating agent tokensIETFIndividual draft, expires Sept 2026Capability narrowing across delegation hops

draft-reece WIMSE cross-org delegationIETFIndividual draftExplicitly a problem statement. States it does not specify a solution

MCP Agent Identity WGAAIFFormingChartered to address sub-agent authority narrowing

Cloudflare Agent Access ModelCloudflareConceptReference architecture. No implementation, no repository

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 in August 2026, and the underlying temporal-logic research is fifteen years old and well understood. Expect it to spread.

Evidence requires a more specific comparison than the presence of logs. NVIDIA describes attested telemetry; AP2 carries payment mandates and receipts; early projects including AgentAction connect scoped authority to execution and outcome evidence. These are different guarantees. Check payload binding, trusted issuers, independent observations and failure recovery before treating any one of them as proof that an authorized task succeeded.

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
Runtime isolation and credential brokering: OpenShell for the agent runtime; Docker MCP Gateway for containerized MCP servers. Verify each deployment boundary
Protection against tool descriptions changing under you: mcp-context-protector from Trail of Bits
Human approval on individual calls: Auth0 asynchronous authorization for application approval; OpenShell for permission expansion. Exact-action approval still needs explicit payload, expiry and replay semantics
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.
Consistent approval semantics across runtimes: trusted approvers, durable state, expiry, payload binding and atomic consumption.
Portable temporal policy and shared session semantics across independent infrastructure and providers.

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

If your project is missing or mischaracterized, tell us.

Open an issue Read the source document

The AI agent governance landscape.

Status

Four jobs in agent governance.

Govern actions

Verify outcomes

Bound access

Monitor runtime

Inspect the evidence.

Six findings.

Access control and action authorization are different problems

Stateful authorization is already part of the landscape

Runtime isolation and provider verification protect different boundaries

Authorization, execution and outcome remain separate claims

Identity propagation is not recursive delegation verification

Approval exists; its binding and durability need inspection

Ordered by backing, not by preference.

Hyperscalers and major public companies

Foundation-governed

Funded private companies

Small companies

Independent and solo-maintained

What is adopted, and what is one person's draft.

Gating became table stakes. Evidence did not.

Choosing something today

What would close the gaps

If your project is missing or mischaracterized, tell us.