Intelligence
Intelligence RecordsJoin the waitlist

Agent authority protocols

The evidence layer behind the reporting. Compare how systems establish, delegate, constrain, revoke and prove authority for AI agents, based on published evidence rather than vendor claims.

15Architectures assessed
265Graded properties
101Sources inspected

Last updated 29 August 2026

Evidence coverage across all protocols

  • Documented design39%
  • Verified in artifacts28%
  • Unknown20%
  • Vendor claim only7%
  • Not supported6%

265 properties graded across 15 architectures, from 101 sources. Verified and Documented design are grounded in a public artifact; Vendor claim only and Unknown are not, and Not supported means the claim was checked and did not hold up.

Authority landscape

15 architectures

How the 15 architectures perform across key authority capabilities. Select a row to compare it, or open a cell to read the evidence behind it.

Runtime enforcement is read directly from each record's own enforcement evidence grade. The other columns are derived by matching each record's graded properties to the dimension; see the methodology below.
ArchitectureRuntime enforcementDelegated authorityHuman approvalRevocation & expiryAudit & attestationBypass resistance
A hollow marker means no evidence was collected for that dimension. Select up to 4 architectures to compare.

Explore architectures

Deep evidence for each authority architecture
15 architectures

ERC-8354, Confidential Agent Policy Verdicts

Muhammad Zidan Fatonie, Faisal Firdani and Maulana Asykari Muhammad, an individual proposal to Ethereum's ERCs repository · Specification · Open license
Updated 29 August 2026

Formally tracked Draft ERC, merged into the canonical ethereum/ERCs repository on 25 August 2026 at commit 9ddae72d666c22a923e78fb923844d1e0494bf1, created 16 July 2026 by the draft's own record and opened for public discussion on Ethereum Magicians on 24 July 2026.

Evidence at a glance
  • Verified in artifacts10
  • Documented design1
  • Unknown1
Runtime enforcement: Documented designDelegated authority: No evidenceHuman approval: No evidenceRevocation & expiry: Verified in artifactsAudit & attestation: No evidenceBypass resistance: No evidence
Moona Intelligence reading

ERC-8354 lets a Guard verify a committed policy evaluated one exact action and returned allow, without disclosing the policy itself. The specification states plainly that this proves the interpreter ran faithfully, not that the underlying ruleset was ever legitimately constituted.

View evidence (12 properties, 3 sources)
Vendor
Muhammad Zidan Fatonie, Faisal Firdani and Maulana Asykari Muhammad, an individual proposal to Ethereum's ERCs repository
Artifact
Specification
License
Open
Announced
25 August 2026
Maturity
Formally tracked Draft ERC, merged into the canonical ethereum/ERCs repository on 25 August 2026 at commit 9ddae72d666c22a923e78fb923844d1e0494bf1, created 16 July 2026 by the draft's own record and opened for public discussion on Ethereum Magicians on 24 July 2026. Status remains Draft, read directly from the frontmatter of the posted text at that exact commit. A public reference implementation and an author written test suite exist alongside the specification. Production adoption, independent implementation and independent security audit were each searched for and not found.
Enforcement point
A Guard contract, ConfidentialPolicyVerdict.sol in the reference implementation, positioned in front of whatever downstream contract a guarded action would otherwise reach directly. The Guard recomputes the action commitment from the action it is about to execute, checks the presented verdict against a proof verifier behind a proving system agnostic interface, and consumes a domain scoped nullifier before allowing the call through, rather than trusting any value the caller supplies about what was decided.
  • Verified in artifacts
    ERC-8354 is a formally tracked Draft ERC with no Final, adopted standard or industry consensus status, and no production adoption was found. Read directly from the frontmatter of the posted specification text at the exact merge commit: status Draft, created 16 July 2026. This record does not describe ERC-8354 as a finalized Ethereum standard, an adopted protocol or production infrastructure, and represents production adoption, independent implementation and independent security audit as searched for and not established.
  • Verified in artifacts
    The Verdict struct carries exactly nine fields, agentId, domainId, policyRoot, actionCommitment, executor, expiry, nullifier, decision and policyKind, each required as a public input to the proving program. Read directly from the posted specification text. Requiring every field as a public input, rather than a value checked only after the fact on chain, is what lets the Guard bind its own on chain checks to exactly what the proof itself committed to, not to a value substituted afterward.
  • Verified in artifacts
    A Policy Domain is defined narrowly as an entity that maintains a ruleset and operates a policy engine, identified by a domainId, not as the ultimate legitimate authority over the resource it governs. Read directly from the posted specification text. This record represents a Policy Domain as the immediate technical authority a verdict is bound to. Nothing in the specification documents who is entitled to stand up a Policy Domain, register it or claim jurisdiction over the resource its policy governs, the same gap this dataset has found in every delegated or approval authority claim it evaluates.
  • Verified in artifacts
    The specification states the Guard MUST recompute actionCommitment from the action it is about to execute and MUST NOT accept one supplied by the caller. Read directly from the posted specification text, quoted without alteration. actionCommitment is the keccak256 of block.chainid, domainId, agentId, target, value, keccak256 of the call data and a strictly increasing actionNonce. This proves the exact chain, domain, agent, target, value and call data a policy evaluated. It does not prove those encoded fields faithfully represent whatever a human or an organization actually meant by the underlying task, a distinction this record keeps separate.
  • Verified in artifacts
    policyKind and decision are paired on a fixed table distinguishing ALLOWED, DENIED, NOT_PERMITTED and COULD_NOT_EVALUATE, and a mismatch between the two fields is rejected before any other check runs. Read directly from the posted specification text. DENIED is a rule that explicitly examined and refused the action. NOT_PERMITTED is the absence of any rule that authorized it. COULD_NOT_EVALUATE is the policy engine failing to reach a verdict. This record does not collapse those three into one generic deny state, since a rule that refused an action and the absence of any granted authority are different facts about Authority Provenance.
  • Verified in artifacts
    The nullifier is derived inside the proving circuit from domainId, agentId, actionCommitment and actionNonce, and the specification states directly that a supplied nullifier would let a domain mint many for one action, defeating single use. Read directly from the posted specification text. Consumed once, a nullifier burns permanently for that domain. This record reads single use verdict consumption inside the guarded call as distinct from an exactly once external effect: what a downstream system does with the effect an action produces, including its own retry or failure semantics, sits outside what this design claims.
  • Verified in artifacts
    A verdict is consumed either directly by v.executor or by any relayer carrying an EIP-712 signature by v.executor over the verdict digest, and the specification forbids using tx.origin for executor validation. Read directly from the posted specification text. executor itself is a required public input to the proving program, not only a value checked on chain, because the specification states a verdict transits a public mempool before it lands and an observer could otherwise lift and front run its consumption. This record keeps the executor distinct from whoever actually constituted the underlying policy; the specification does not claim they are the same party.
  • Verified in artifacts
    A superseded policy root stays acceptable for maxRootAge seconds, and the specification states the tradeoff directly: a low setting risks liveness gaps during cross chain synchronization, a high setting extends how long a removed rule keeps authorizing actions. Read directly from the posted specification text. DomainRevoked provides immediate, universal revocation outside that aging schedule. A separate, named risk is silent verifier or program key rotation, DomainProgramUpdated, which the specification advises treating as a revocation when unannounced rather than assuming continuity.
  • Verified in artifacts
    The specification distinguishes action level integrity, that the committed interpreter was evaluated over this action and returned ALLOW, from interpreter level fidelity, that the interpreter actually implements the policy the domain claims, and states plainly that this ERC does not prove the second. Read directly from the posted specification text, quoted without alteration. A consistently wrong or malicious interpreter can produce valid proofs against its own committed policy root. The specification's own remedy is out of band, provenance disclosure or review attestations, not zero knowledge verification. This is the clearest limitation this record found in the entire design, stated by the specification itself rather than inferred.
  • Verified in artifacts
    The specification states directly that a rejected agent cannot see why it was rejected, and cannot distinguish a correct application of a harsh rule from an incorrect application of a fair one, naming this an inherent cost of the design. Read directly from the posted specification text. The commitment is deliberately not blinded so a domain retains an optional, off protocol path to disclose the actual ruleset to an auditor or regulator, checked against the same committed hash a verdict already proves was used. Nothing requires a domain to exercise that path, and this record does not assume any given domain does.
  • Documented design
    The reference implementation's Solidity test suite runs against MockVerifier.sol rather than a live proof, while a separate Noir circuit is proven with Barretenberg and UltraHonk and the specification states it passes nargo test. Verified directly against the merge commit's own eighteen file, 2173 line change set. This record reads circuit level zero knowledge proving as real and demonstrated by the specification's own account, and the Solidity Guard's own unit tests as run against a mock verifier standing in for a live proof. No test combining real proof generation with on chain verification in one run was found, and this record does not claim one exists. The full suite is author run and not independently reproduced.
  • Unknown
    Whether whoever operates a Policy Domain was entitled to govern the resource its policy protects, as distinct from technically operating a policy engine, is not established by the specification. Nothing this session read in the specification documents an organizational entitlement, a resource ownership rule, a contract or a governance basis for who may stand up and operate a Policy Domain. A valid policyRoot proves a ruleset existed at a specific committed state. It does not prove that ruleset was legitimately constituted, the same gap this dataset has found in Nuggets' Authority Control Plane, Britive's on behalf of binding and the EP Authorization Receipts draft's enrolled approver key.
Sources (3)

AC2, the Agentic Communication and Control Protocol

Algorand Foundation, with Pera Wallet building the reference AC2 Wallet on Rocca infrastructure · Specification and client SDK · Open license
Updated 29 August 2026

The specification's own status line reads Draft, its own creation date field reads 1 April 2026, it was committed to the repository on 23 April 2026 and has carried exactly one commit since, and its conformance section is marked TBD.

Evidence at a glance
  • Verified in artifacts13
  • Vendor claim only3
  • Unknown4
Runtime enforcement: Documented designDelegated authority: Vendor claim onlyHuman approval: Verified in artifactsRevocation & expiry: UnknownAudit & attestation: UnknownBypass resistance: No evidence
Moona Intelligence reading

AC2 keeps a controller's signing key off the agent and requires explicit approval for every signing operation, verified directly against its own Draft specification. Normative fields are narrower than the launch material suggests, and nothing establishes that the signing controller was entitled to authorize what was signed.

View evidence (20 properties, 9 sources)
Vendor
Algorand Foundation, with Pera Wallet building the reference AC2 Wallet on Rocca infrastructure
Artifact
Specification and client SDK
License
Open
Announced
25 August 2026
Maturity
The specification's own status line reads Draft, its own creation date field reads 1 April 2026, it was committed to the repository on 23 April 2026 and has carried exactly one commit since, and its conformance section is marked TBD. Algorand Foundation's launch material separately calls AC2 an open protocol and, in places, an open standard. This record grades the specification by its own status line rather than by that launch framing: an openly licensed, publicly developed draft is not the same fact as an adopted standard, and nothing found here shows the Draft status has changed since verification.
Enforcement point
The Controller, meaning the human's own wallet or app, decides whether to produce a signature for one specific requested payload, after a WebAuthn user verification ceremony. The specification states the Agent cannot sign autonomously and never receives the underlying signing key, so the point where authorization over an AC2 gated operation is actually decided is the Controller's own signing interface, a component the Agent cannot run or influence directly.
  • Verified in artifacts
    AC2 is a public Draft with its own conformance section marked TBD. Fetched directly this session from algorandfoundation/ac2's ac2.md. The specification's own header states its status as Draft, and its conformance section reads TBD. This is the specification describing itself, not this record's characterization of it.
  • Verified in artifacts
    The specification's internal creation date and its commit history are two different dates, and the text is unchanged since April. The specification's own creation date field reads 1 April 2026. The commit history for ac2.md, fetched directly this session, shows exactly one commit touching that file, dated 23 April 2026, authored by ehanoc, with the message "docs: init ac2 spec". No later commit touches this file, so the normative text verified in this record is the same text committed that day, three weeks after the date the document itself claims as its creation date.
  • Verified in artifacts
    AC2, its reference implementation, an AC2 Wallet proof of concept and an OpenClaw plugin all went public on 25 August 2026. Repository commit history fetched directly this session shows commits dated 25 August 2026 on the master branch, including release commits and a commit adding a single line install script for OpenClaw plus the AC2 plugin, corroborating an active public launch that day. Algorand Foundation's own blog post announcing the launch could not be fetched directly, algorand.co is blocked domain wide at this session's network egress proxy, so the launch date and the specific claim that a wallet proof of concept and an OpenClaw plugin launched alongside the specification are additionally corroborated through multiple independently phrased search passes returning consistent detail across separate outlets (DailyCoin, Crypto Reporter, Enterprise Talk). Graded verified on the strength of the directly fetched commit history; the surrounding launch narrative rests on manual review sourcing recorded on the sources below.
  • Verified in artifacts
    The specification defines a Controller that holds the signing key and an Agent that can only request a signature. Fetched directly this session. The Controller is defined as the user's wallet or identity manager, carrying a FIDO2 and WebAuthn compatible signing interface, a WebSocket signaling client, a WebRTC DataChannel handler and an AC2 message processor. The Agent is defined as holding a signaling server, a request builder for signing operations, a delegation handler that receives approved signatures, and its own AC2 message processor. The Agent's own defined role has no signing capability of its own.
  • Verified in artifacts
    Every signing operation currently requires explicit, uncached human approval. Fetched directly this session, quoted in substance from the specification: agents cannot sign transactions autonomously, and users must explicitly approve all signing operations, with each signature request treated independently rather than any approval being cached or reused across requests. This is stated as the current requirement, not a future goal.
  • Vendor claim only
    Standing bounded delegation is described in launch material as a future direction, not a shipped mechanism. Direct fetch of algorand.co blocked this session. Search corroborated launch material describes AC2 use cases extending toward agents acting within signed limits without approving every action, framed alongside the AP2 IntentMandate example as where the protocol is headed. The specification's own normative text, read directly, defines only per signature approval today and no standing session or delegation object with enforced bounds. Graded as a vendor claim about future direction, not as a shipped capability.
  • Verified in artifacts
    Messages must be DIDComm 2.0 compliant and travel peer to peer over WebRTC via Liquid Auth, with no relay server. Fetched directly this session. AC2 messages must be DIDComm version 2.0 compliant, travel over a WebRTC DataChannel labeled ac2-v1 with ordered, DTLS encrypted delivery, and require no central relay server. Liquid Auth, Algorand's existing passkey based authentication protocol built on FIDO2, WebAuthn and WebRTC, is named as a required transport layer, with its reference extension binding a Passkey to an Algorand address.
  • Verified in artifacts
    WebAuthn user verification is required for a signing operation, which is not the same claim as biometrics being mandatory. Fetched directly this session. The specification requires WebAuthn conformance per W3C standards and states user verification is required for signing operations. WebAuthn user verification can be satisfied by a PIN or another authenticator mechanism depending on the device, so this record does not narrow the requirement to biometric approval where the specification's own text does not.
  • Verified in artifacts
    A SigningRequest's normative fields are description, payload, encoding and schema, not amount, recipient or purpose. Fetched directly this session. The normative SigningRequest schema carries a human readable description, a base64 encoded payload, an encoding scheme and a schema reference, and requires the description be shown to the user in both raw and human readable form. An amount, a recipient and a purpose appear only inside the specification's own illustrative x402 payment example, not as fields the schema itself requires.
  • Verified in artifacts
    A SigningResponse carries only a signature, and a SigningRejected message carries only a reason. Fetched directly this session. SigningResponse's normative content is a base64 encoded signature. SigningRejected carries a reason field. Neither message type defines an expiry, a scope or a single use consumption flag as part of its own normative content.
  • Verified in artifacts
    A scope field appears once, in one illustrative delegation example, with no enforcement semantics defined. Fetched directly this session. The word scope appears exactly once in the specification, inside one illustrative signing delegation example, with no definition of what it constrains or how a downstream system would check it. Reading scope as a normative, enforced constraint on every AC2 delegation would promote one example past what the text supports.
  • Vendor claim only
    AP2's IntentMandate is described in launch material as an example flow, and is never mentioned in the specification itself. Direct fetch of algorand.co and dailycoin.com blocked this session. Search corroborated launch and press material describes a shopping agent constructing and submitting a Google AP2 IntentMandate for a controller's sign off, then acting within its constraints afterward. This session searched the AC2 specification's own text directly and found no mention of AP2 or IntentMandate anywhere in it. AC2 being usable to sign a mandate another protocol defines is not the same claim as AC2 enforcing what that mandate constrains once signed, and this record does not attribute AP2's own enforcement properties to AC2.
  • Verified in artifacts
    The signing key used for AC2 gated operations stays with the Controller, a claim this record does not broaden past what the specification isolates. Fetched directly this session. The Agent's defined role never includes possession of a signing key; it constructs requests and receives signatures. The specification says nothing about API tokens, DIDs, session credentials or WebRTC signaling credentials the Agent may hold for anything outside an AC2 gated signing operation, so this record narrows the claim to the specific signing key AC2 isolates rather than generalizing to every credential an agent runtime might hold.
  • Unknown
    Nothing ties a signed request to a verified organizational mandate behind the Controller. A SigningRequest's description field is human readable and can carry a stated purpose, fetched directly this session, but nothing in the specification's own text checks that description against a corporate office, an account ownership right or any other organizational entitlement. Whether the Controller who signed was actually authorized under whatever policy governs the resource at stake is not addressed by anything this session read, and is recorded as unknown rather than assumed.
  • Unknown
    No dedicated security considerations section, revocation mechanism or replay protection was found in the normative schema. Read directly this session. The specification contains a message level expires_time field governing how long a message stays valid, but no dedicated security considerations section, no stated rule for invalidating an already issued signature, and no nonce based replay protection in the normative message schema. A requestId exists only inside the Liquid Auth extension, used for WebAuthn challenge correlation rather than stated as a replay defense. Recorded as unknown rather than assumed either way.
  • Verified in artifacts
    The canonical specification and a separate Controller reference implementation are both real, Apache licensed code on GitHub. Fetched directly this session. algorandfoundation/ac2 carried 207 commits, 18 stars, 4 forks and 2 open pull requests at verification, with a workspace package.json declaring an Apache-2.0 license and a packages directory holding an SDK, a command line client, and both a reference and a server package for OpenClaw. The specification text itself carries the separate W3C Software and Document License. A distinct repository, algorandfoundation/ac2-controller, licensed Apache License Version 2.0, holds a demonstration Controller onboarding application built on Algorand's own wallet provider library, covering key generation, backup and device native secure storage.
  • Verified in artifacts
    The OpenClaw integration is implemented code in the repository, not only an announced plan. Fetched directly this session. The canonical repository's packages include ac2-open-claw-reference and ac2-open-claw-server, and its commit history shows a commit dated 25 August 2026, the launch day, titled "feat: single line install script for OpenClaw plus AC2 plugin", confirming a working installer exists in the repository rather than only being described in launch material.
  • Vendor claim only
    AC2 Wallet is a published Pera app, and its link to Rocca wallet infrastructure rests on corroborated secondary reporting. Direct fetch of play.google.com and algorand.co blocked this session. Search corroborated results confirm AC2 Wallet is published on Google Play under Pera Wallet's own app.perawallet.ac2 package as a self custodial Algorand wallet demonstrating AC2. Algorand's 27 August 2026 follow up material, reported secondhand through Blockchain.News because this session could not locate or fetch a matching primary algorand.co URL, describes AC2 Wallet as built on Rocca, the wallet infrastructure also used to rebuild Pera Wallet 7.0 the same month. This record treats the specific product to infrastructure link as corroborated rather than independently read from Algorand's own primary text.
  • Unknown
    No independent security audit or formal verification of AC2 was found. This session found no third party security audit, penetration test report or formal verification result for AC2, in the specification, the repositories, or independent coverage searched. Recorded as unknown rather than assumed safe or unsafe.
  • Unknown
    No adopter beyond Algorand Foundation and Pera Wallet was independently confirmed. Search passes for named organizations building on or adopting AC2 beyond Algorand Foundation itself and Pera Wallet's reference AC2 Wallet returned no independently confirmed result. A repository fork is not a separate implementation and specification publication is not evidence of production adoption. Recorded as unknown; independent adoption is not established.
Sources (9)

ARC, Agentic Runtime Control

Britive · Implementation · Proprietary license
Updated 24 August 2026

Britive states ARC is available today on the Britive platform.

Evidence at a glance
  • Verified in artifacts1
  • Documented design6
  • Vendor claim only2
  • Unknown8
Runtime enforcement: Documented designDelegated authority: UnknownHuman approval: No evidenceRevocation & expiry: UnknownAudit & attestation: No evidenceBypass resistance: Unknown
Moona Intelligence reading

ARC mostly bundles and brands capability Britive built, gateway interception, ephemeral privilege, continuous authorization, now arriving from a PAM vendor rather than a cloud platform. Its on behalf of delegation is a policy input, not a cryptographic mandate, and it leaves unaddressed whether the delegator was organizationally entitled to delegate.

View evidence (17 properties, 8 sources)
Vendor
Britive
Artifact
Implementation
License
Proprietary
Announced
24 August 2026
Maturity
Britive states ARC is available today on the Britive platform. This record could not fetch prnewswire.com or britive.com directly in this session, a policy level denial at this session's network egress proxy rather than a missing page, and repeated, independently phrased web searches did not surface the specific 24 August 2026 release by URL, unlike the blocked domain condition elsewhere in this corpus where search consistently converged on the live page's own wording. What this record can establish is that ARC reads as a named bundling of capabilities Britive had already shipped and separately announced rather than a wholly new architecture disclosed for the first time: an MCP Gateway use case page, a Just in Time ephemeral permissioning platform page, and a 23 April 2026 press release naming Britive the first complete PAM platform to natively support the OpenID Shared Signals Framework each independently describe, under their own titles and dates, pieces of what the 24 August 2026 material bundles under the Agentic Runtime Control name. This record treats the ARC brand and its 24 August 2026 date as sourced to the commissioning brief for this record, not independently fetched, and treats each constituent capability below at the evidence level its own, independently locatable source supports.
Enforcement point
Where Britive sits in the connection path. Documented architecture is an MCP Gateway that intercepts, authorizes and credentials a downstream tool call before it runs, positioned between an MCP client and an internal or internet hosted MCP server. For SSH and SQL targets, Britive's own material frames enforcement the same way, as reaching wherever Britive brokers the connection rather than as a universal guarantee over every target system. Nothing reviewed for this record documents command level SSH parsing or statement level SQL parsing specifically; the concrete example this record could independently locate is session level, a broker minting time bound access to an EC2 instance through AWS Systems Manager, not a claim that individual commands inside that session are each parsed and authorized.
  • Documented design
    Britive announced ARC, Agentic Runtime Control, on 24 August 2026 as bringing Zero Standing Access to AI agents. Sourced to the commissioning brief for this record rather than to a direct fetch of the release, since prnewswire.com and britive.com were both blocked at this session's network egress proxy on every attempt, and independently phrased web searches consistently returned other Britive press releases without surfacing this specific one by URL. This record does not treat that absence as evidence the release does not exist, only as a limit on what this session could independently confirm about its exact wording, and represents the launch itself, and its 24 August 2026 date, at documented rather than verified grade.
  • Vendor claim only
    ARC is stated to be available today on the Britive platform, with no independent confirmation found of packaging, pricing or named customer adoption specific to ARC. This record found a Marqeta customer relationship and quote associated with an earlier, separately dated Britive AI identity security announcement (18 September 2025), and could not confirm whether the same or a different Marqeta quote appears in the 24 August 2026 material, or whether any customer beyond Marqeta is named in it. Either way, a vendor published customer quote inside a vendor's own release remains vendor published evidence, not independent reproduction, absent a Marqeta primary artifact this record could locate and read directly.
  • Documented design
    Britive's MCP Gateway is documented as intercepting, authorizing and credentialing each downstream MCP tool call before it runs. Britive's own MCP Gateway use case page, corroborated across independently phrased web searches whose result snippets closely paraphrase the live page, describes the Gateway sitting between an MCP client and an internal or internet hosted MCP server, modeling tools as resources with their own policy, and evaluating every tool invocation at the Gateway against that policy before anything runs. This record could not fetch britive.com directly to confirm the exact wording, and grades the claim documented rather than verified for that reason.
  • Verified in artifacts
    Britive's public GitHub MCP server is a separate administrative integration exposing Britive's own management API as agent tools, not the MCP Gateway that authorizes other agents' tool calls. Fetched directly from github.com in this session. The britive/mcp-server repository documents a client that lets an AI agent or user call Britive's own platform, checking access, querying configuration, running reports and reading activity, authenticated either through a cached PyBritive command line login or a static token, with an on behalf of mode that activates when a BRITIVE_EMAIL environment variable is set, currently supported for one tool, my_access. Nothing in this repository's documentation describes it proxying, intercepting or authorizing a third party MCP server's tool calls, mentions SSH, SQL or ephemeral credential issuance to a target system, or names the Shared Signals Framework, CAEP or RISC. This record treats it as a distinct, narrower product from the MCP Gateway described in the property above, and does not credit the Gateway's documented behavior to this repository or vice versa.
  • Documented design
    On behalf of requests are stated to bind an agent's authority to the delegating person's own privileges so the agent cannot exceed them. Corroborated across independently phrased web searches describing Britive's on behalf of model as tying an agent's request back to the human privilege boundary it is acting under, with authority stated to remain at or below the delegating person's level and narrowed further for the agent, the task, the resource or the content in question. This record could not fetch britive.com directly to read the exact mechanism, and grades the claim documented rather than verified.
  • Unknown
    Whether the at or below guarantee holds as an intersection enforced across every policy layer, with no configuration or bypass path that could widen it, is not independently confirmed. Available material states the outcome, that delegated authority remains at or below the delegating person's own level, without this record being able to read the underlying policy evaluation, credential issuance and target system permission logic side by side the way this record could for, say, GitLab's composite identity narrowing. This record does not describe the guarantee as a proven invariant, and represents it as the intended, documented architecture rather than as independently tested behavior.
  • Unknown
    Task and stated intent function as contextual inputs to a policy decision, not as a documented cryptographic or durably bound mandate attached to the resulting privilege. Britive's own language describes evaluating each access grant using context including the identity behind it, the task and the scope required. Nothing this record could read specifies how a task is represented, whether as a structured object, a free text description or a client asserted label, how that representation reaches Britive's policy engine, or whether it is cryptographically or durably bound to the privilege subsequently created and to the specific action later authorized, as opposed to being read once at grant time and then discarded. This record does not infer a formal task mandate from the word task in marketing language, and represents the binding between stated task or intent and the resulting privilege as unconfirmed.
  • Documented design
    Elevated privilege is documented as minted directly in a target system through its own native API and revoked automatically when a task ends, with credential brokering as a separate path for systems that require one. Corroborated across independently phrased web searches describing Britive calling a cloud provider's native API to mint a time bound permission scoped to what a task requires, with no account created ahead of time and no credential sitting in a vault, alongside a separate documented case of transparent credential injection for pipeline and CLI use through mechanisms such as OIDC rather than static secrets. This record keeps privilege created directly inside a target system distinct from a credential issued and injected for systems that require one, consistent with how this record has separated those two layers for every other vendor it has examined, and did not find material specifying whether an agent process itself can access an injected credential directly or only through a broker that holds it on the agent's behalf.
  • Vendor claim only
    Command and statement level enforcement for SSH and SQL is qualified to where Britive sits in the connection path, and this record found no confirmation of command level SSH parsing or statement level SQL parsing specifically. Britive's own material states that where it sits in the connection path, enforcement can extend to individual SSH commands and SQL statements. The most concrete independently locatable example this record found is session level, Britive brokering time bound access to an EC2 instance through AWS Systems Manager rather than direct SSH, which establishes ephemeral session access, not that commands typed inside that session are individually parsed and authorized. No material available to this record specifies which SSH or SQL protocol implementations are proxied, whether a session is fully proxied end to end, or whether SQL statements are parsed before reaching the database rather than the connection itself being brokered. This record does not generalize the connection path qualifier into universal action level enforcement for every target system, and grades the specific command and statement level claim as claimed rather than documented.
  • Documented design
    The example of an agent authorized for read access being stopped from a destructive database action is a documented architecture illustration, not a customer incident, public demo or independent test. Corroborated across independently phrased web searches describing a worked example in which an agent requesting Snowflake data checks out a read only access profile, Britive verifies the requesting identity is authorized for that profile, and grants temporary read only access rather than standing broader permission, with a companion statement that just in time, least privilege access with automatic removal is offered as protection against a wrongly issued destructive action. This record treats this as Britive's own architecture illustration, consistent with how the commissioning brief for this record described it, and not as a reported production incident, a public demonstration this record could inspect, or an independently run test.
  • Documented design
    Britive states native support for the OpenID Shared Signals Framework, consuming CAEP and RISC events to trigger automated session termination, forced logout, step up authentication or account disable, and separately emitting its own CAEP and RISC events. Sourced to Britive's own 23 April 2026 press release naming itself the first complete PAM platform to natively support the Shared Signals Framework, corroborated across independently phrased web searches describing bidirectional signal exchange, a worked example of a trusted transmitter reporting a laptop out of compliance and Britive automatically terminating an active cloud session or forcing a logout in response, and every signal, response and emitted event logged with a timestamp. This capability is dated four months before the 24 August 2026 ARC material this record was commissioned to verify, and this record treats it as continuing infrastructure the ARC brand draws on rather than a new capability introduced with ARC specifically.
  • Unknown
    Which of a downstream ephemeral credential, an active session or a specific pending tool call already dispatched is affected by a given inbound CAEP or RISC signal is not itemized in material available to this record. Available material describes session termination and forced logout as outcomes of an inbound signal. It does not specify, for an agent mid task, whether a credential already brokered to a downstream tool call in flight is itself revoked, whether only the session that would issue the next credential is affected, or how quickly that propagates relative to a call already dispatched to its target. This record does not describe continuous authorization as an instantaneous or mathematically complete guarantee on the strength of what is available, and represents the precise scope of an in flight revocation as unknown.
  • Unknown
    Which fields of a recorded transaction are guaranteed, independently derived by Britive, client or agent supplied, or cryptographically signed and tamper evident is not established in material available to this record. Britive's own language states that it records evidence throughout a transaction including identities, requests, authorization decisions, privileges, actions and outcomes, and that for agent tool calls this can include the prompt, the tool, its arguments and, when supplied, stated intent. This record treats an agent's own stated intent as one input the record can carry, not as independent proof that a legitimate task mandate existed, consistent with how this record treats stated intent throughout. Nothing available specifies whether records are cryptographically signed, whether they are tamper evident, whether an authorization decision is bound to the execution that actually followed it, or whether execution outcome is independently observed by Britive rather than reported back by the agent or the downstream tool.
  • Unknown
    Britive's on behalf of binding documents who an agent nominally acts for, not whether that person was organizationally entitled to delegate the underlying capability to an autonomous agent. Identity of the delegating person is one fact. Legitimacy of that person's own standing to delegate autonomous use of their privilege to an agent, under a corporate role, a contract, a board mandate or another governance basis, is a separate fact this record has not found addressed in material available to it. This record does not infer legitimate mandate merely because a person technically holds the access being delegated, the same caution this record has applied to Nuggets' Authority Control Plane and to Google's Agent Identity, and represents mandate legitimacy for Britive as undocumented rather than assumed.
  • Unknown
    A governance or resource ownership requirement, beyond technical policy authoring ability, for who may configure an ARC policy is not documented in material available to this record. Nothing reviewed for this record describes an organizational entitlement, resource ownership rule or approval workflow that must be satisfied before a technically permitted administrator may author or attach an ARC policy, the same gap this record has already found in GitLab's composite identity, Google's Agent Identity and Nuggets' Authority Control Plane.
  • Unknown
    A generic human challenge path for one proposed action, and a rollback or compensation path for a consequential action already completed under a since revoked authority, are not documented for ARC in material available to this record. Available material documents policy authored in advance and signals that can terminate a session or force a logout. It does not document a channel by which an auditor, a resource owner or someone other than the original administrator can challenge one proposed action before it executes, nor a restoration path for an effect a target system has already produced by the time a session is revoked. This record does not invent an approval or recovery mechanism from Britive's broader capability set where ARC's own material does not describe one, and represents both as undocumented.
  • Unknown
    Whether an agent holding an independent credential or a direct network path to a target system can reach that system without passing through ARC's policy evaluation is not addressed in material available to this record. ARC's documented reach is stated as where Britive sits in the connection path. Nothing available to this record addresses what happens outside that path, an agent with a standing credential issued before ARC was deployed, a direct database connection that never passes through a Britive brokered session, or an MCP server reachable by a route ARC's Gateway does not intercept. This record does not describe ARC's enforcement as non bypassable on the strength of what is available, and preserves the connection path qualifier as a boundary on the guarantee rather than a detail that can be dropped.
Sources (8)

Slack Code, code channels and expert sign off for high stakes actions

Slack, a Salesforce company · Implementation · Proprietary license
Updated 21 August 2026

Generally available product, live on every Slack plan from the day of launch, with the underlying code channel API restricted to founding launch partners.

Evidence at a glance
  • Verified in artifacts2
  • Documented design4
  • Vendor claim only2
  • Not supported2
  • Unknown4
Runtime enforcement: Vendor claim onlyDelegated authority: No evidenceHuman approval: UnknownRevocation & expiry: No evidenceAudit & attestation: Documented designBypass resistance: Unknown
Moona Intelligence reading

Slack Code lets an agent carry a change to the edge of production, and Slack's material says an expert signs off before it ships. Slack does not run the agent or perform the deployment, and no artifact defines who may approve, what it binds to, or what happens without one.

View evidence (14 properties, 3 sources)
Vendor
Slack, a Salesforce company
Artifact
Implementation
License
Proprietary
Announced
20 August 2026
Maturity
Generally available product, live on every Slack plan from the day of launch, with the underlying code channel API restricted to founding launch partners. No public specification, no public API documentation and no published enforcement mechanism were found on the day after launch.
Enforcement point
Not established. Slack states that Slack Code is not a coding model, a harness or an agent runtime, so the agent executes and the deployment happens in the partner agent's own infrastructure and the customer's own pipeline. The sign off is a message on a surface that does not perform the deployment, and no artifact describes what on the far side requires it.
  • Verified in artifacts
    Slack Code launched on 20 August 2026 and is available on every Slack plan. The Slack announcement dated 20 August 2026 states that Slack Code is available on any Slack plan from launch, with no additional Slack fee for creating or operating code channels. Customers supply their own access to whichever partner agent they use. Reported consistently across independent coverage the same day.
  • Verified in artifacts
    The founding partner coding agents are named. Four names appear consistently across the launch material and independent coverage: Claude Code from Anthropic, Devin from Cognition, GitHub Copilot and the Vercel agent. Some accounts additionally list OpenAI's ChatGPT and others do not. The four consistent names are recorded as verified and the fifth is left open rather than resolved from inconsistent reporting.
  • Documented design
    A code channel is a distinct channel type created by a partner agent. Tagging a supported agent causes it to open a channel scoped to that task, created and managed through a Slack API rather than by an ordinary user flow. The channel presents dedicated tabs for Conversation, Plan, Code Diffs and Live Preview, and carries the repository and branch the agent is working in together with pull request information. Described by the vendor and by independent coverage. Moona did not operate a code channel.
  • Documented design
    Anyone in the channel can pause, redirect or stop the agent mid task. Stated in Slack's own launch material, and unusually broad in scope: not the person who assigned the task and not an administrator, but anyone in the channel. What is not documented is whether stopping the channel side interaction halts work already in flight inside the partner agent's own runtime, which is a different system.
  • Documented design
    Agents in code channels inherit Slack's permissions and admin controls. Slack states that agents in code channels inherit Slack's built in security model, permissions and admin controls, and that IT provisions no new identities. This is a meaningful default. Nothing published describes the identity the agent presents to the repository or the deployment system, which are outside Slack.
  • Documented design
    The channel archives itself into a searchable audit record. Slack states that when the task ends the channel archives itself and the record survives as an audit log, with the plan, diffs and conversation staying searchable. This is evidence of what happened. It is not a control over what happens.
  • Vendor claim only
    A human sign off is described for high stakes actions such as pushing to production. Slack's wording is that for high stakes moves, like pushing code to production, the agent packages its work for an expert to sign off on, right in the channel, and that this keeps people in control without slowing things down with separate IT approvals. Packages is a preparation verb. Slack's wording and word order are reproduced exactly, with hyphens dropped from high-stakes and sign-off for this dataset's dash free prose rule. The sentence appears in launch marketing and is the entire published description of the behaviour.
  • Unknown
    The sign off is enforced by the product rather than expected as workflow. No published artifact states that an agent is prevented from proceeding without a sign off, describes a hold, a block or a gate, or names any mechanism that would produce one. Absence of a published mechanism is not proof that none exists, so this is recorded as unknown rather than rejected.
  • Unknown
    Who is permitted to give the sign off is defined. Expert is used as an ordinary English word. No role, permission, group or designation is defined for it. Slack separately ships a prebuilt AI agent named Channel Expert, which is a different product and is not what this sentence refers to. Whether eligibility is limited to the task assigner, a repository owner or anyone present in a channel where anyone can already pause the agent is unstated.
  • Unknown
    A sign off is bound to a specific diff, commit or deployment. Nothing published states whether an approval attaches to the diff reviewed, to a commit, to a single deployment, or to everything the agent does afterwards in that channel, nor whether a later change to the same branch requires a fresh decision. This is the difference between an authorization and a gesture, and it is unanswered.
  • Unknown
    Whether an agent can reach production without passing through the sign off. Nothing published states what an agent does when no one responds, whether it waits, times out or proceeds, or whether any path to production exists that does not pass through the channel at all.
  • Not supported
    Slack itself is the point at which the production decision is enforced. Slack states that Slack Code is not a coding model, a harness or an agent runtime, and that what it built is an API letting partner agents create and manage the channel type. The code executes elsewhere and the deployment is performed by the partner agent's systems or the customer's pipeline. Slack is the surface where the work is shown and discussed, which is not a position from which a deployment can be refused.
  • Not supported
    The code channel API is publicly documented and openly available. Access to the code channel APIs is limited to the launch partners at release, with Slack saying it intends to open them more widely later. No public technical documentation of the API was found, so there is nothing published for an outside engineer to read or evaluate.
  • Vendor claim only
    Independently established production adoption. Slack's account is that its launch partners run code channels internally, alongside a launch day characterisation that some of them do most of their coding in Slack. That is the vendor describing its own partners on the day the product shipped. No independent adoption evidence exists one day after launch, and one day is not a track record.
Sources (3)

AI Agency Protocol (AIAP)

Causum with Kanjani AI Research · Specification and client SDK · Proprietary license
Updated 20 August 2026

Working draft v0.1, stated in the specification itself

Evidence at a glance
  • Verified in artifacts1
  • Documented design10
  • Not supported2
  • Unknown2
Runtime enforcement: UnknownDelegated authority: Documented designHuman approval: No evidenceRevocation & expiry: Documented designAudit & attestation: Documented designBypass resistance: No evidence
Moona Intelligence reading

AIAP writes into a grant format a familiar idea: an agent can keep its identity and technical capability while holding only temporary, purpose bound authority to use them. The public artifacts show a documented design rather than a demonstrated enforcement path, and the protocol itself is proprietary, not open.

View evidence (15 properties, 7 sources)
Vendor
Causum with Kanjani AI Research
Artifact
Specification and client SDK
License
Proprietary
Announced
20 August 2026
Maturity
Working draft v0.1, stated in the specification itself
Enforcement point
An agency broker that decides on the grant request and, at the mediated level, executes the action itself so the agent never holds credentials
  • Verified in artifacts
    Protocol artifact exists. A public GitLab project holds RFC 001, two concept papers and a Python client SDK. The project was created on 19 August 2026 and announced on 20 August 2026.
  • Not supported
    Open protocol. The press release calls it the first open protocol. The repository README and LICENSE.md state that AIAP is proprietary and not open source, that production use requires a paid operating license, and that all patent rights are reserved. The published SDK on PyPI carries the license classifier Proprietary.
  • Not supported
    First protocol of its kind. Prior public work already treats agent authority as a bounded, expiring grant, including the Human Agency Protocol v0.4 from April 2026, the Agentic Power of Attorney draft under Apache 2.0 from February 2026, and an IETF individual draft for a Principal Agent Protocol updated in June 2026.
  • Documented design
    Authority represented as a bounded grant. The specification models a grant as an agency envelope carrying principal, identity, goal, purpose, authorized actions, resources, context, temporal boundary, delegation constraints and obligations.
  • Documented design
    Purpose binding. A request states the intended purpose and use case, and the effective session policy is the intersection of the role policy, the use case template and the request.
  • Documented design
    Context binding. The request message carries a context object that the governance pipeline evaluates before a grant is issued.
  • Documented design
    Expiration. Grants carry an explicit expiry timestamp and the specification describes credentials that end when the temporal boundary is reached.
  • Documented design
    Immediate revocation. A revoke message removes the session from tracking and writes the revocation to audit. The specification states that issued cloud credentials stay valid until they expire, so revocation is not instantaneous at the credential level.
  • Documented design
    Short lived credential issuance. The first agency level issues scoped, time limited credentials to the agent. The second level withholds credentials entirely and has the broker execute the action.
  • Documented design
    Broker mediated execution. Mediated execution is defined by request and result messages between the agent and the broker, so execution happens under broker control rather than agent control.
  • Documented design
    Delegated authority can only narrow. The concept documents state that downstream agency stays equal to or narrower than the authority it derives from and that provenance is preserved along the chain. The specification marks delegated agency as a future level, so no public artifact demonstrates it running.
  • Documented design
    Audit and evidence semantics. Every decision is described as recorded with the governance checks that produced it, an expiry, a policy template identifier and a signature, written to immutable storage shared with a companion governance protocol.
  • Documented design
    Failure behavior. The governance pipeline denies the request when identity, lifecycle state, use case, safety tier, revocation status, agency level or template checks fail, including a denial when no template scopes the request.
  • Unknown
    Enforcement demonstrated publicly. Only a client SDK is published. The broker that makes and enforces the decision is not public, so no independent party can observe an enforced decision or reproduce one.
  • Unknown
    Adoption. No named deployment, conformance report or independent implementation is public. The repository shows no stars or forks and a single day of activity at the time of verification.
Sources (7)

Earned Autonomy Framework

NeuBird AI · Published principles, announcement only · Unknown license
Updated 20 August 2026

A set of architectural principles stated inside a company announcement.

Evidence at a glance
  • Verified in artifacts1
  • Documented design5
  • Vendor claim only2
  • Not supported4
  • Unknown5
Runtime enforcement: Vendor claim onlyDelegated authority: No evidenceHuman approval: No evidenceRevocation & expiry: UnknownAudit & attestation: No evidenceBypass resistance: Documented design
Moona Intelligence reading

NeuBird's earned autonomy idea, trust widening or narrowing with an agent's track record, would be a real departure from install time permission. But the artifact is a four sentence press release, with no document, license, or version, and never says whether a level attaches to the agent or one action.

View evidence (17 properties, 5 sources)
Vendor
NeuBird AI
Artifact
Published principles, announcement only
License
Unknown
Announced
20 August 2026
Maturity
A set of architectural principles stated inside a company announcement. No standalone document, version number, repository or machine readable artifact was found on the day of publication.
Enforcement point
The vendor's own production operations agent, running inside the customer environment, with approval gates, blast radius limits, circuit breakers and rollback described by the vendor rather than by any public artifact
  • Verified in artifacts
    The framework was published on 20 August 2026. The Business Wire release, dated 20 August 2026 and carried in full by Morningstar under source identifier 20260820067565, announces the Earned Autonomy Framework as a set of open architectural principles for how autonomous agents should earn, scope and operate within write access in production. Independent trade coverage the same day reports the same four level model.
  • Not supported
    The framework exists as a standalone document, specification or repository. Searched on the day of publication. The company sitemap holds no framework page, the newsroom index lists no such entry, likely paths return 404, and the company GitHub organization holds eight repositories, none of them the framework. The complete text of the principles found anywhere is the four level list and four implementation commitments inside the announcement itself.
  • Not supported
    Open source. The announcement says the framework is open for adoption, revision and co signature. It names no license, no copyright grant, no version and no repository. Open for adoption is not an open source license, and nothing published establishes what an adopter is permitted to do with the text.
  • Documented design
    Co signature mechanism. The announcement states that the company is gathering named co signers from operators, security leaders and independent engineers, and directs anyone wishing to co sign or comment to its contact page. That page loads. No signatory list, no revision history and no governance or maintainer process is published, and no co signer outside the company is named.
  • Documented design
    A four level trust model is defined. L0 Read and Recommend is strict read only, with root cause diagnosis and drafted recommendations. L1 Human Gated requires explicit human sign off before high stakes or novel state changes execute. L2 Policy Bounded lets low risk routine remediation execute automatically inside pre cleared policy parameters and blast radius limits. L3 Earned Autonomy runs high confidence operations autonomously inside virtual private cloud containment with real time circuit breakers and instant automatic rollback. Each level is one sentence long. The announcement is the whole definition.
  • Unknown
    The terms that decide a level are defined. High stakes, novel, low risk, routine, high confidence and pre cleared policy carry the whole weight of the model, and none of them is defined anywhere public. Nothing states who classifies an action, against what criteria, or how a classification is reviewed.
  • Documented design
    Promotion between levels. The announcement states that agents progress based on verified performance and that promotion to L3 requires demonstrated root cause analysis accuracy. How accuracy is measured, over what sample, against what threshold, who authorizes the promotion and whether promotion is per agent, per action, per tool, per resource or per environment is not stated anywhere public.
  • Documented design
    The agent cannot raise its own authority. The announcement states plainly that the agent cannot self escalate. No public artifact shows what prevents it, so the statement is a design commitment rather than an observed control.
  • Unknown
    Demotion and revocation. The chief technology officer says write access must be revocable the moment confidence drops, and trade coverage reports that permissions should be revoked if confidence falls. What measures confidence, what threshold triggers a demotion, whether demotion is automatic or manual, and what happens to work already in flight are all unstated.
  • Unknown
    Authority is scoped to particular actions, resources or environments rather than to the agent as a whole. The model reads as a level held by an agent. L2 references pre cleared policy and blast radius limits and L3 references containment, which imply scoping, and a vendor security page mentions configurable autonomy levels per environment. Nothing published states whether a promotion applies to one remediation, one tool, one resource class or every production action the agent can reach. This is the distinction that decides whether the model actually constrains authority, and it is not answered.
  • Documented design
    The product controls behind the framework appear in vendor technical documentation. The public product documentation describes zero data storage with in memory processing purged at session end, least privilege scoping per connection, short lived credentials such as AWS Security Token Service with no long term credentials stored, customer controlled external identifiers and trust policies with instant revocation, an audit trail covering every observation, inference and action, approval gates for high risk actions, blast radius limits, and three deployment models including a private virtual private cloud install. It also states SOC 2 Type II certification. This is the vendor describing its own system, not an independent test.
  • Not supported
    Vendor documentation matches the framework's write access claims. The public product documentation states that every connection to customer infrastructure uses strictly read only permissions, that this is architecturally enforced rather than policy, and that it is technically impossible for the platform to modify customer systems, configurations or data. It also states that the team decides what to do with recommended actions. The framework describes automatic remediation at L2 and autonomous operation at L3. Both are published by the same vendor and they do not agree, and nothing public reconciles them or dates one after the other.
  • Vendor claim only
    Circuit breakers and automatic rollback. Real time circuit breakers and instant automatic rollback appear in the announcement, and automatic rollback on metric degradation appears on the vendor marketing security page. Neither the product documentation nor any public artifact describes the trigger, the scope or the behavior of either control.
  • Unknown
    Enforcement demonstrated publicly. No public artifact, test, demonstration, conformance report or independent review shows any of these controls making or refusing a decision. Every enforcement statement traces back to the vendor.
  • Unknown
    Adoption by anyone other than the publisher. No named co signer, no adopting organization and no independent implementation is public. Verification took place on the day of the announcement.
  • Vendor claim only
    The stated shift in enterprise buyer questions. The claim that buyers have moved past whether AI belongs in production and now ask what the agent is allowed to do is a quotation from the company's own chief technology officer, repeated by trade coverage of the same release. It rests on no published survey, sample or methodology, and it is recorded here as a vendor observation rather than as measured buyer demand.
  • Not supported
    The earned autonomy idea originates here. Earned autonomy is already in public circulation from unrelated parties, including a Principles of Earned Autonomy framework published in April 2026 under a Creative Commons Attribution ShareAlike license with a registered digital object identifier, and a January 2026 research essay on earned autonomy in network defense. The announcement does not claim to be first, and this record does not treat the term as new.
Sources (5)

Agent Action Decision Protocol (AADP)

Shamik Saha, individual submission to the IETF · Specification · Mixed license
Updated 22 August 2026

Individual Internet Draft, revision 01, published 20 August 2026, expiring 21 February 2027.

Evidence at a glance
  • Verified in artifacts2
  • Documented design14
  • Vendor claim only1
  • Not supported1
  • Unknown1
Runtime enforcement: Documented designDelegated authority: No evidenceHuman approval: Documented designRevocation & expiry: Documented designAudit & attestation: No evidenceBypass resistance: No evidence
Moona Intelligence reading

AADP proposes a wire contract for action level authorization: a decide and report exchange between Policy Decision and Enforcement Points that treats live budgets and approvals as inputs. Its real, Apache-2.0 reference implementation is unusually candid about its own gaps, which is engineering seriousness, not independent adoption or a standard.

View evidence (19 properties, 8 sources)
Vendor
Shamik Saha, individual submission to the IETF
Artifact
Specification
License
Mixed
Announced
20 August 2026
Maturity
Individual Internet Draft, revision 01, published 20 August 2026, expiring 21 February 2027. A description supplied to this session states the intended status as Standards Track, a designation this session could not independently confirm by reading the Datatracker record. Revision 00 was published 17 August 2026 and is superseded by revision 01, the same underlying proposal rather than a second, independent piece of evidence.
Enforcement point
A Policy Enforcement Point sitting at the point a governed action would actually run, with examples described as an agent framework tool wrapper, a protocol proxy, an API gateway filter, a container or micro VM supervisor, and a workflow engine. A conformant PEP must hold a permit from a Policy Decision Point before performing the action. The draft names no single reference PEP; the author's own separate onedoor project, verified independently this session, implements several PEP surfaces, an in process executor, an MCP proxy, an HTTP gateway service and a LiteLLM adapter, in front of one PDP.
  • Documented design
    Draft exists as an Internet Draft distributed through IETF infrastructure. This session's direct fetch attempts against datatracker.ietf.org and www.ietf.org were both blocked by network egress policy, and repeated, independently phrased web searches for draft-saha-aadp, for Shamik Saha and for the exact title returned no corroborating result naming this draft. What this session verified directly instead is a real, separately hosted software package, onedoor on PyPI and GitHub, published under the same author name, whose own README, CONFORMANCE.md and CHANGELOG.md cite draft-saha-aadp-00 and draft-saha-aadp-01 by identifier, quote specific section numbers such as a transport section at 12.1, and describe a per requirement conformance status against it. That is real, independently inspected circumstantial evidence that the draft exists, not a substitute for reading the Datatracker record itself. Graded documented on that basis, and an editor with unblocked network access should confirm the Datatracker page directly before this is promoted further.
  • Not supported
    Adopted by the IETF, assigned to a working group, or published as an RFC. A description supplied to this session is explicit that this is an individual Internet Draft, not an RFC and not an IETF standard, and that it does not by itself establish IETF working group consensus, adoption or industry adoption. Nothing this session could independently read contradicts that, and nothing supports a stronger status. It carries no RFC number and no named working group in any material available to this session.
  • Documented design
    The draft separates agent identity and standing access from authorization of one concrete action. As described in material supplied to this session summarizing the draft's contents, AADP argues that identity and token layers answer who is acting and what the principal may reach, while AADP itself addresses whether a specific proposed action, with specific argument values, may proceed now. This session has not read the draft's own text making that argument. It is the same separation the AIC certificate draft and the AAE envelope above each state in their own vocabulary, and the same separation this dataset's article corpus has independently observed in vendor architectures from AWS and Google; AADP's distinct contribution, if the supplied description is accurate, is proposing a wire contract for the decision itself rather than only naming the distinction.
  • Documented design
    A Policy Decision Point owns authorization state and evidence; PEPs enforce it. The PDP is described as evaluating proposed actions and owning the relevant authorization state and evidence; PEPs are described as living where governed actions actually happen, and a conformant PEP must not perform a governed action without a permit. The onedoor implementation independently corroborates this split in its own architecture section: a decide_and_reserve function performs the complete ordered check pipeline and reserves budgets, and separate enforcement points, an in process executor, an MCP proxy, an HTTP gateway and a LiteLLM adapter, compose around it rather than making their own authorization decisions.
  • Documented design
    Authorization runs as a two phase decide then report exchange. The sequence described is: a PEP sends decide(request); the PDP evaluates and records the decision and any required reservation; the PDP returns a permit or other verdict; the PEP performs the action only when permitted; the PEP sends report(permit_id, outcome); the PDP records the linked result. The onedoor implementation independently corroborates the same two phase shape under different names, decide_and_reserve as transaction A and report_result as transaction B, with the connector call itself executed outside any lock between them under a hard timeout, so a hung downstream call cannot hold the decision engine hostage.
  • Documented design
    A PEP that receives a permit must send exactly one report, even on failure. The requirement described is that a PEP holding a permit sends exactly one report even when execution fails, times out, or is refused, and that authorization evidence is kept distinct from proof that the external action produced its intended real world result. The onedoor changelog independently shows this being hardened in practice: version 0.3.6 fixes a case where one enforcement point, its LiteLLM example, reported success prematurely, and unreleased 0.4.0 replaces a boolean outcome with a four value outcome of success, failure, timeout or not_attempted specifically so a timeout is not silently treated as evidence the action did not happen.
  • Documented design
    Four autonomy tiers gate whether an action executes automatically or waits for a person. The tiers described are tier 0, observe, read only with no external effect; tier 1, auto, automatic execution only when reversible; tier 2, auto_capped, automatic execution within budgets; and tier 3, confirm, requiring human approval before execution. The onedoor implementation independently corroborates the same four tiers under matching semantics: tier 0 reads are exempt from its kill switch, tier 1 cannot auto execute without a declared compensating command and its policy loader refuses to start if a tier 1 entry lacks one, tier 2 carries cumulative rate, daily and monthly budgets enforced race free, and tier 3 is the stated default for unlisted action types, irreversible operations and budget overages. This session has not read the draft's own normative language for the irreversible action invariant directly; what is reported here is the implementation's enforced behavior, which is consistent with the tier semantics as described, not a verified quotation of the draft's own MUST level text.
  • Documented design
    Verdicts include permit, deny and propose, and a propose verdict requires approval first. A propose verdict is described as requiring approval before the action can proceed, distinct from an outright permit or deny. The onedoor implementation independently corroborates an equivalent flow: a tier 3 proposal generates an approval request carrying a time to live, an admin role key approves or denies it separately from the role that requested the decision, and the resulting decision branches to either permit or deny before any obligation reaches the enforcement point. This session has not read the draft's own verdict vocabulary directly to confirm the exact term propose is used rather than a synonym.
  • Documented design
    Approvals carry an expiry and the draft addresses re-evaluation behavior. Material supplied to this session describes an approval lifecycle including expiry and re-evaluation, without this session independently reading the draft's own text for the exact re-evaluation rule. The onedoor implementation shows one concrete instance of the shape: approval requests are time to live bound, and the changelog separately documents a reservation reclamation mechanism with expiry, described as implementing a requirement it labels AADP section 6. That labeled citation is the implementation's own claim about which section it satisfies, not something this session confirmed against the draft text itself.
  • Documented design
    Concurrent requests must not independently consume the same remaining budget. The requirement described is that cumulative budgets be reserved atomically so concurrent requests cannot each believe they consumed the last unit of an authorization budget. This session has not read the draft's own text stating the exact linearizability guarantee required. The onedoor implementation independently corroborates the design goal, stating that cap accounting is race free because budget reservation occurs inside a single BEGIN IMMEDIATE database transaction that completes before the connector call executes, which serializes concurrent reservations against one budget rather than checking and decrementing it in two separate steps. That is one implementation's chosen mechanism for one storage backend, SQLite, not a demonstration that the draft mandates that specific mechanism, and this dataset does not equate the two.
  • Documented design
    Request IDs and permit IDs bind repeated requests and reports to one decision. Material supplied to this session describes idempotency and replay semantics binding request IDs, permit IDs, repeated requests and reports, without this session independently reading the draft's exact guarantees. The onedoor implementation corroborates an idempotent reporting mechanism in substance: its two phase model is described as supporting idempotent re-reporting, so a duplicate result submission for the same intent does not double charge a budget, and version 0.4.0 is documented as adding downstream idempotency key propagation as a still open gap, listed in its own conformance document as item A3, not yet implemented as of the version this session verified.
  • Documented design
    The draft claims evidence sufficient to re-derive every verdict, not cryptographic signing. Material supplied to this session states the draft claims its evidence is sufficient to re-derive every verdict, without specifying cryptographic signing as a current requirement, and this session did not read the draft's own evidence section directly. The onedoor implementation is consistent with that boundary: its own documentation describes a rederivable manifest and policy content hash stamping so a stored decision can be checked against the policy that produced it, while its conformance document separately and explicitly lists the absence of transport security, of sender constrained permits and of a hash chained audit log as unresolved gaps rather than implemented guarantees. Nothing independently available to this session shows either the draft or its reference implementation currently requiring cryptographic signatures on individual permits.
  • Documented design
    Guarantees assume a trusted governed domain and do not defend against a compromised PEP. Material supplied to this session states plainly that the draft's guarantees assume a trusted governed domain in which the PDP and PEP trust each other, and that it explicitly does not defend against a malicious or compromised PEP that requests authorization for one action and performs another. This session did not read that limitation in the draft's own text directly. It is consistent with what the reference implementation's own conformance document discloses unprompted: no transport security guaranteeing confidentiality, integrity or mutual authentication between PDP and PEP, and bearer only permits rather than permits bound to a specific requesting PEP. This is an important limitation, stated by the source material itself rather than found through outside scrutiny, and this record preserves it rather than rounding the protocol's guarantees up to cover a boundary it does not yet claim to cross.
  • Documented design
    Signed, action bound permits are named as future work for cross trust boundary use. Material supplied to this session states the draft identifies signed, action bound permits carrying a digest of the exact action, an expiry and a PEP binding as future work for use across an untrusted enforcement boundary, and is explicit that AADP does not currently solve authorization provenance across such a boundary. This session did not read that future work language directly. The reference implementation's own documented gaps point the same direction without duplicating the claim: sender constrained permits and signed, hash chained audit records are both listed there as not yet implemented, which is consistent with a design that has not yet closed this gap rather than evidence that it has.
  • Documented design
    The draft distinguishes itself from a separate Internet Draft on agent operation authorization. Material supplied to this session states that AADP itself describes a separate Internet Draft on agent operation authorization as addressing consent and delegation lineage, while AADP focuses on mutable state including cumulative budgets, reservations and approval lifecycle. This session has not read AADP's own text drawing that comparison. Separately, this dataset already carries an independent citation to that other document, draft-liu-agent-operation-authorization, describing it as proposing a structured authorization token an authorization server issues only after a person confirms a specific proposed operation; that citation was made without reference to AADP and is not treated here as confirming AADP's characterization of it. The two drafts are recorded as distinct proposals with an author reported relationship between them, not as a coordinated standard.
  • Verified in artifacts
    onedoor is a real, independently inspectable reference implementation of the PDP. Fetched directly this session: the PyPI project page lists onedoor at version 0.3.6, Apache-2.0 licensed, authored by Shamik Saha, describing itself as a tiered guardrail and policy engine for agentic systems, with its homepage and repository both pointing to github.com/shamiksaharcciit-oss/onedoor. The GitHub repository's README, CONFORMANCE.md and CHANGELOG.md were each fetched directly and describe a working PDP or PEP split, decide_and_reserve and report_result functions, declarative YAML policy files, an HTTP decision service, an MCP proxy, a LiteLLM adapter and a LangChain integration. The repository's own tests directory was listed directly and contains subdirectories including protocol, guardrail, service, store, mcp and integrations, alongside a conftest.py, consistent with an automated test suite rather than a documentation only claim. This session read the directory listing, not the contents of the test files themselves, so what those tests specifically assert was not independently confirmed, and no test was executed by this session. At the time of this session's verification the repository showed zero stars, zero forks and zero external issues or pull requests, consistent with a single author project rather than one with outside contributors.
  • Verified in artifacts
    The reference implementation discloses its own gaps against the draft rather than claiming full conformance. Fetched directly this session: onedoor's own CONFORMANCE.md, current as of version 0.3.6, states 23 requirements as implemented with test coverage and separately lists eight named gaps, including absent transport security, bearer only rather than sender constrained permits, and no isolated obligation enforcement, plus a further set of implementation level defects it labels N1 through N7, including the explicit statement that AADP obligations attached to a permit are currently silently ignored rather than causing the system to fail closed. The CHANGELOG.md independently confirms the same posture in its own words, stating that a report_result call in the shipped 0.3.6 line lacks a distinct outcome parameter and conflates a timeout with an outright failure, a defect the document says is fixed only in an unreleased 0.4.0. Moona Intelligence reads a project that discloses its own non conformance in detail as stronger evidence of honest engineering than a project that claims completeness, and grades the underlying facts verified precisely because the gaps, not only the successes, were independently readable in the source.
  • Unknown
    Intellectual property rights disclosure status. No IPR disclosure was found or ruled out for this draft. The Datatracker's IPR tab was not independently inspected because direct fetch of datatracker.ietf.org was blocked on every attempt this session, and no independent search result surfaced IPR information for this specific draft. This remains unconfirmed, not confirmed absent.
  • Vendor claim only
    Adoption by anyone other than the author. The only documented use of either the draft or its reference implementation is the author's own onedoor project, whose README describes it as extracted from the author's personal production use, a home, energy and money control plane with an LLM layer, running since July 2026. That is one person's account of one person's own system, the same structure this dataset already grades as an author reported deployment claim for the AAE record's MolTrust deployment above. No named third party implementer, adopter, working group discussion or interoperability report independent of the author was found for this draft in any material available to this session.
Sources (8)

AI Agent Identity Certificate (AIC) extension for X.509 v3

Jijie Wei, individual submission to the IETF · Specification · Mixed license
Updated 20 August 2026

Individual Internet Draft, revision 00, intended status Experimental, expires 20 February 2027

Evidence at a glance
  • Verified in artifacts4
  • Documented design9
  • Not supported3
  • Unknown5
Runtime enforcement: UnknownDelegated authority: Documented designHuman approval: No evidenceRevocation & expiry: Documented designAudit & attestation: Documented designBypass resistance: No evidence
Moona Intelligence reading

This individual IETF draft cleanly separates agent identity from authorization: a certificate proves who to hold accountable, not that an action was permitted. Its default mode freezes authority at issuance, so a narrowed grant does nothing until reissuance, and no public implementation yet lets anyone verify it running.

View evidence (21 properties, 5 sources)
Vendor
Jijie Wei, individual submission to the IETF
Artifact
Specification
License
Mixed
Announced
19 August 2026
Maturity
Individual Internet Draft, revision 00, intended status Experimental, expires 20 February 2027
Enforcement point
A relying party gateway that validates the certificate and then decides the operation, with capability meaning supplied by external plugins rather than by the certificate
  • Verified in artifacts
    Draft exists on the IETF Datatracker. The Datatracker holds draft wei aic identity cert 00, titled AI Agent Identity Certificate (AIC) Extension for X.509 v3, by Jijie Wei, submitted and posted on 19 August 2026, revision 00, 42 pages, expiring 20 February 2027.
  • Not supported
    Adopted by the IETF or published as an RFC. The Datatracker record shows no working group, no stream, no RFC number and no standards level. The document header reads Internet Draft, Individual, intended status Experimental. It is an individual submission, not an adopted work item, not an RFC and not a standard.
  • Verified in artifacts
    Identity is explicitly separated from authorization semantics. The abstract states that the specification intentionally separates cryptographic delegation from authorization semantics: AIC defines the cryptographic binding between agent and principal, while capability and policy semantics are defined externally by vendors, industries or regulators. The scope section repeats that it does not define a universal authorization language and that whether an operation is permitted is decided by the capability scheme and the deployment policy, not by the extension itself.
  • Documented design
    Agent identity is bound to a named principal. The extension carries an agent identifier, a delegation mode and a principal identifier that links the agent to the authorizing principal, with a principal key hash binding and delegation authorization evidence protected against replay by a nonce.
  • Not supported
    Binding proves that a particular action was authorized. The draft describes the binding as cryptographic evidence that can support attribution of autonomous actions to a principal. Attribution says which principal stands behind the actor. It does not establish that any particular operation was permitted, which the draft leaves to the capability scheme and the deployment policy.
  • Documented design
    The certificate carries authorization related fields. Alongside identity, the extension declares a capability container, an authorization constraints container with offline verifiable boundaries such as IP range and time window, and a companion PrincipalAuthorization extension that anchors principal side grants and delegation policy.
  • Documented design
    Effective permission is an intersection, not a certificate claim. The permission model is the intersection of the principal grants and the agent capabilities. In authorized mode the intersection is resolved once by the issuing authority and locked into the certificate. In representative mode it is recomputed at the gateway for each operation.
  • Documented design
    Authority can go stale after issuance. The draft states plainly that authorized mode provides snapshot authorization semantics, so changes to the principal grants after issuance do not affect the capability set of a certificate already issued. Only representative mode checks the principal grants at runtime.
  • Documented design
    Delegation depth is bounded. Single level delegation from principal to agent is the default, a chain of depth one may be supported, and a sub agent at depth one must not delegate further. The stated reason is that deeper chains complicate attribution and accountability, which the draft anchors to the natural person at the top of the chain.
  • Documented design
    Actor and executor are recorded separately in audit. In authorized mode the agent identifier is recorded as the actor and the principal identifier as the authorizing principal. In representative mode the principal is recorded as the actor and the agent as the executor.
  • Documented design
    Enforcement stays outside the certificate. The draft states that trust remains in the public key infrastructure, transport remains in TLS and enforcement remains in the gateway. Capability meaning is routed to scheme specific plugins, and gateway local controls such as rate limits and quotas are explicitly outside the permission model.
  • Verified in artifacts
    The draft states its own limitations. The limitations section lists delegation depth capped at one, no distributed state across gateways, static capability evaluation with dynamic context aware policy out of scope, non TLS transport deferred, post quantum signature exchange not yet specified, and no published validation at enterprise scale.
  • Documented design
    Offline validation carries a revocation gap. The security considerations acknowledge that in offline deployments a revoked certificate can be accepted until the next cache refresh, mitigated by short validity windows and tighter constraints rather than eliminated.
  • Unknown
    Reference implementation available for inspection. The implementation status section describes a reference implementation in Go covering issuance, parsing, admission decisions, revocation and offline authorization, and states that it is not yet publicly available and that repository links will be added when it is published. No independent party can inspect or reproduce the behavior today.
  • Unknown
    Freely implementable. The document is published under the usual Internet Draft terms, but the intellectual property section records two Chinese patent applications filed by the author covering the described technology, with a formal disclosure still to be filed. The licensing terms that would apply to an implementer are not established.
  • Unknown
    Adoption. No working group, no interoperability report and no named deployment is recorded. Revision 00 was posted one day before verification.
  • Not supported
    A certified principal grant proves the principal's underlying mandate was legitimate. The draft states directly that it does not constrain the authority of a certificate authority to issue a PrincipalAuthorization extension. The chain a relying party can verify is that a certificate authority certified the principal as holding a grant set, that the principal signed a delegation, and that the agent's capabilities sit inside that grant set. It does not establish that the certificate authority's own organizational, contractual, statutory, fiduciary or governance determination behind that certification was correct. Mandate legitimacy remains dependent on certificate authority issuance policy and trust anchor configuration rather than being cryptographically solved by the extension.
  • Verified in artifacts
    The principal's signature covers a specific, named set of fields. The DelegationAuthTBS structure the principal signs covers agentId, principalUid, a stated reason, capabilities, delegationMode, authorizationConstraints when present, a requestedLifetime, a timestamp and a nonce, with the nonce specified as 32 random bytes for replay protection alongside issuance time uniqueness checking. This is protocol design verified from the specification text, not demonstrated replay resistance in a public implementation, since no public implementation exists to test.
  • Documented design
    Certificate lifetime is requested by the principal and set by the certificate authority. The principal requests a certificate lifetime as part of the signed delegation structure, and the issuing certificate authority determines the actual lifetime subject to its own policy. Certificate expiry and mandate revocation are kept as distinct events in the draft's own account, not treated as interchangeable.
  • Unknown
    A relying party, resource owner or governance authority can formally challenge an issued PrincipalAuthorization. No mechanism was found in the draft text by which an actor other than the certificate authority or the principal itself can dispute the legitimacy of an already issued PrincipalAuthorization. Certificate rejection or revocation is an outcome the draft documents, not a formal challenge process, and this record does not treat the two as equivalent.
  • Unknown
    A rollback, compensation or reversal mechanism exists for actions already executed. No dispute resolution, rollback, compensation or reversal language was found in the draft. Revocation stops future admission decisions. It does not restore a resource, reverse a payment, or undo any other action already completed before the revocation took effect.
Sources (5)

EP Authorization Receipts (EMILIA Protocol)

Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF · Specification · Open license
Updated 25 August 2026

Individual Internet Draft, revision 12, dated 16 August 2026 and expiring 17 February 2027, read directly by this session from the posted draft text.

Evidence at a glance
  • Verified in artifacts13
  • Documented design3
  • Unknown2
Runtime enforcement: Documented designDelegated authority: Documented designHuman approval: UnknownRevocation & expiry: Documented designAudit & attestation: No evidenceBypass resistance: No evidence
Moona Intelligence reading

This draft's strongest, verified claim is narrow: a signature commits to one hashed action under one identified policy version, rendered to a human from that covered object. It states plainly that a receipt is evidence, not authorization, and nothing in it establishes the approver's organizational entitlement or current revocation status.

View evidence (18 properties, 3 sources)
Vendor
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Artifact
Specification
License
Open
Announced
16 August 2026
Maturity
Individual Internet Draft, revision 12, dated 16 August 2026 and expiring 17 February 2027, read directly by this session from the posted draft text. The document's own boilerplate states it is submitted under BCP 78 and BCP 79 as work in progress without IETF consensus, and names Standards Track only as its intended status, a designation this session could not independently confirm by reading the Datatracker record directly, since datatracker.ietf.org was blocked at this session's network egress proxy on every attempt. The vendor's own public repository states plainly, in its own words, that a published Internet Draft is not an RFC, an adopted working group item, or IETF endorsement, and that no working group adoption, RFC status or IETF consensus is claimed for any document in its inventory. Revisions 05, 06, 09, 10 and 11 are earlier versions of the same underlying draft lineage rather than independent pieces of evidence, and this record evaluates revision 12 alone. The vendor's own reference implementation and formal models are, by the draft's own account, incomplete against the draft text on named points, detailed below rather than smoothed over.
Enforcement point
Nowhere in the receipt format itself. The draft is explicit that a signed Authorization Context is action bound confirmation evidence an authorization server MAY validate and bind to the grant it issues, and that the resulting Trust Receipt records terminal consumption and remains evidence, with neither object making the authorization decision. That decision is stated to remain with the authorization server, a system external to and undefined by this draft, not with the local human interaction that produced the signature and not with the receipt object a relying party later verifies.
  • Verified in artifacts
    Revision 12 is an individual Internet Draft with no working group adoption, no IETF consensus and no RFC status. Read directly from the posted revision 12 text and corroborated in the vendor's own GitHub repository, which states without qualification that a published Internet Draft is not an RFC, an adopted working group item or IETF endorsement, and that no working group adoption, RFC status or IETF consensus is claimed. This record preserves that maturity precisely and does not describe the draft as a standard, an adopted specification or a document carrying broad industry adoption.
  • Verified in artifacts
    Revisions 05, 06, 09, 10, 11 and 12 are versions of one underlying draft, not independent market signals. The vendor's own repository inventory names revision 12 as the current posted receipt revision and retains 10 and 11 as archived prior versions of the same document. This record cites revision 12 only, dated 16 August 2026, and does not count an earlier revision, a mirror copy, an announcement email or a website restatement as separate evidence of the same underlying draft.
  • Verified in artifacts
    The Action Object in revision 12 names ep_version, action_type, target, parameters, initiator, policy_id and requested_at as its required fields, canonicalized under RFC 8785 and hashed with SHA 256. Read directly from the posted revision 12 text. The draft states the Action Object MUST be serialized using the JSON Canonicalization Scheme and that the action hash is the SHA 256 digest of that canonical serialization. This record represents revision 12's own field list rather than inferring fields from an earlier revision this record did not itself read.
  • Verified in artifacts
    Implementations MUST reject an approval request whose action hash does not match a locally recomputed hash of the presented Action Object. Read directly from the posted revision 12 text. This establishes that the signed Authorization Context commits to one canonical action representation. It does not, on the draft's own account, establish that an external system later executed that same action. This record keeps approval evidence binding, the fact that a signature commits to a canonical action, separate from authorization decision binding, the fact that some system granted permission for it, and separate again from execution binding, the fact that the action actually ran.
  • Verified in artifacts
    A conforming signing client MUST render the human readable presentation from the exact Action Object covered by the action hash rather than from a separately supplied description. Read directly from the posted revision 12 text. An optional display_hash commits to profile defined disclosure bytes, and the draft states directly that a successful result establishes only that trusted evidence binds those bytes to the exact action, not that the human comprehended or legally consented to the action, that the claimed bytes became physical pixels, or that the operating system, display path or signing client was uncompromised. The draft adds separately that base receipt verification alone does not prove that a faithful rendering reached a human. This record preserves that qualification rather than reading exact action binding as proof of human comprehension.
  • Verified in artifacts
    The Authorization Context carries action_hash, policy_id, policy_hash, authorization_instance, audience, approver, approver_index, required_approvals, nonce, issued_at, expires_at, an optional display_hash and a previous receipt hash. Read directly from the posted revision 12 text. authorization_instance is specified as at least 128 bits from a cryptographically secure generator, durably registered per approval ceremony and byte identical across every context belonging to that attempt. nonce is specified separately as at least 128 bits, unique per approver within the issuer's domain. This record names revision 12's own field set rather than a field list drawn from an earlier revision or a companion draft.
  • Verified in artifacts
    A signature over an Authorization Context under one policy hash does not satisfy a requirement evaluated under a different policy hash, even under the same policy identifier. Read directly from the posted revision 12 text, which states this requirement without qualification. This is real evidence that a signed context can carry both what action and under what governing policy version a human confirmed. It is not evidence that the policy itself was legitimately constituted. Who authored, approved or was entitled to issue a given policy identifier and policy hash is a separate question the draft does not address, and this record marks that question undocumented rather than assuming a policy hash implies a legitimate policy owner.
  • Verified in artifacts
    A per approver nonce supports freshness, but the draft states directly that offline verification does not establish global non replay. Read directly from the posted revision 12 text, which lists global non replay among the properties offline verification does not establish. This record reads the nonce as evidence a given signature has not been reused against the verifier's own online, atomic consumption record, not as a standalone guarantee that the same evidence could not be replayed against a second, independent relying party that never checks the first party's consumption state.
  • Verified in artifacts
    A closed pre execution EP-AUTHORIZATION-BUNDLE-v1 profile carries the Action Object, signed Authorization Contexts, signoffs, key proofs and presentation evidence, and states directly that it carries no consumption, log proof, execution outcome or success assertion. Read directly from the posted revision 12 text, which states that constructing or validating the bundle does not reserve capacity, issue a grant, authorize the action, consume the action, prove that an effect occurred, or make an uncertain action safe to retry. This record keeps that pre execution bundle distinct from the terminal Trust Receipt described below rather than treating either as a substitute for the other.
  • Verified in artifacts
    The Trust Receipt records a terminal consumption state after an authorization instance is spent, and the draft states directly that neither the bundle nor the receipt makes the authorization decision, which remains with the authorization server. Read directly from the posted revision 12 text: the resulting Trust Receipt records terminal consumption and remains evidence, neither object makes the authorization decision, and that decision remains with the authorization server. A separate sentence in the same text states plainly that admission is not execution, and execution is not effect. This record represents consumption, the authorization decision, execution and external effect as four events the draft is careful to keep distinct rather than as one event described four ways.
  • Verified in artifacts
    The draft states directly that a receipt is evidence, not authorization, and that it does not treat a local human interaction as an authorization decision. Read directly from the posted revision 12 text, quoted without alteration: a receipt is evidence, not authorization, and this document does not treat a local user interaction as an authorization decision. This is the load bearing sentence for this record's entry in the dataset. It is a specification explicitly refusing to promote a signed human confirmation into the authorization decision itself, a distinction this dataset has found genuinely useful and genuinely rare.
  • Verified in artifacts
    The mapping from an enrolled approver identifier to a natural person is asserted by the Approver Directory trust root, not proven by the receipt format itself. Read directly from the posted revision 12 text: the document binds an approval to an approver identifier whose key is enrolled in the Approver Directory, and this does not, by itself, prove that the holder of that identifier is a particular natural person. A separate sentence states the mapping from an enrolled approver identifier to a natural person is asserted by the directory authority. This record keeps the approver key, the Approver Directory, the natural person, the authorization server, the organizational principal and the policy owner as six distinct actors rather than treating possession of a signing key as complete proof of identity.
  • Unknown
    Whether the person holding an enrolled approver key was organizationally entitled to approve the action, as distinct from technically holding the key, is not established by the draft. Nothing this session read in revision 12 documents an organizational entitlement, resource ownership rule, contract or governance basis for who may hold an enrolled approver key. The draft's own account of what offline verification does not establish names legality among the missing guarantees. This record does not infer legitimate mandate from the fact that a person technically holds an enrolled key, the same caution this dataset applies to Nuggets' Authority Control Plane, Britive's on behalf of binding, Google's Agent Identity and the Agent Action Decision Protocol's policy authorship. The distinction this record preserves is that a person cryptographically approving one action is not the same fact as an organization having legitimately empowered that person to do so.
  • Documented design
    The receipt is scoped to one canonical action under one policy, one audience and one validity window, and this record does not read it as a general delegation token. The bound dimensions this record could confirm from revision 12 are the action itself, its target and parameters, the policy identifier and policy hash, the audience, the issued and expiry timestamps, and the authorization instance the signature belongs to. That is one action's worth of confirmation evidence, not a standing grant a holder could point at to justify a second, different action.
  • Verified in artifacts
    Offline verification does not establish current revocation status, and the draft requires a relying party to apply current policy and current status inputs before any new reliance decision. Read directly from the posted revision 12 text: historical acceptance and current policy acceptance are separate results, offline verification establishes authenticity and log inclusion as of commit time rather than current revocation status, and a historical acceptance MUST NOT be used by itself to authorize a new effect, establish current non revocation, or prove that the same evidence remains acceptable under a later policy epoch. This record keeps historical validity, that a signature existed and verified at time T, separate from current validity, whether that same evidence still stands today.
  • Unknown
    The draft documents no normative recovery or reversal mechanism for an effect an authorization already permitted, naming a future companion remedy receipt only as an informative, non exhaustive possibility. Read directly from the posted revision 12 text, which describes such companion artifacts as informative, non exhaustive consumers and states that base receipt verification does not validate any such chain, program, lifecycle or settlement artifact. This record does not treat receipt revocation, consumption or verification as a stand in for undoing an external effect the underlying action already produced, and represents recovery as undocumented within this draft's own scope.
  • Documented design
    The draft names three normative mechanisms its own reference implementation and conformance vectors do not yet exercise, and states its formal models do not yet cover several other named mechanisms. Read directly from the posted revision 12 text: the operator signed directory assurance downgrade, delegation records together with the DelegateCannotExceedPrincipal check, and enforcement_class emission are each named as specified ahead of the reference implementation, with the text stating implementers MUST treat the specification text as normative and the reference implementation as incomplete on these points, not the reverse. The same section states the formal models do not yet cover WebAuthn challenge binding, the Approver Directory, log checkpoints or Initiator Attestation, describing those sections as specified, not proven. Separately, this session verified directly that the vendor's public repository carries three cross language reference verifiers, a conformance suite the repository states covers 332 vectors across 21 suites, and TLA+, Alloy and Tamarin models, none of which this record independently reproduced beyond reading the repository itself, and none of which this record treats as independent, third party or production verification.
  • Documented design
    EMILIA Protocol, Inc. maintains roughly two dozen separate Datatracker records, and this record evaluates the authorization receipts draft alone rather than importing capability from its companion drafts. The vendor's own repository names a broader portfolio including a canonical action identifier draft, an action evidence graph draft, a human authorization binding draft, an authority introduction draft and an authorization evidence chain draft, among others. This record treats each as a separate artifact with its own maturity and its own evidence, and does not read a quorum mechanism, a bounded capability receipt or an action evidence graph capability into this entry merely because the same vendor names it elsewhere in its portfolio.
Sources (3)

Agent Identity and Agent Identity Auth Manager

Google · Implementation · Proprietary license
Updated 24 August 2026

Google Cloud's own IAM documentation dates Agent Identity's general availability, custom Organization Policy constraints for Auth Manager and VPC Service Controls integration for Agent Identity to 14 August 2026, with Auth Manager itself still in preview that day.

Evidence at a glance
  • Documented design11
  • Unknown6
Runtime enforcement: Documented designDelegated authority: Documented designHuman approval: UnknownRevocation & expiry: UnknownAudit & attestation: Documented designBypass resistance: No evidence
Moona Intelligence reading

Google Cloud has put a strongly attested, non impersonable per agent identity into general availability, with a stolen token unreplayable by default. It does not document a configuring administrator was entitled to grant it, and only Agent Gateway, not the direct Auth Manager path, keeps the credential encrypted until use.

View evidence (17 properties, 7 sources)
Vendor
Google
Artifact
Implementation
License
Proprietary
Announced
14 August 2026
Maturity
Google Cloud's own IAM documentation dates Agent Identity's general availability, custom Organization Policy constraints for Auth Manager and VPC Service Controls integration for Agent Identity to 14 August 2026, with Auth Manager itself still in preview that day. Auth Manager and its two supporting APIs, agentidentity.googleapis.com and agentidentitycredentials.googleapis.com, reached general availability on 22 August 2026. Agent Identity itself was first previewed publicly at Google Cloud Next 26, held 22 to 24 April 2026. This record's own maturity read is uneven across platforms: search corroboration consistently describes Agent Identity for Agent Runtime as generally available, while some material describes Agent Identity for Gemini Enterprise Agent Platform as still in preview, and this record's own blocked access to docs.cloud.google.com prevented reading the current, authoritative label for each platform side by side.
Enforcement point
Split across several distinct systems rather than one. IAM enforces what the Agent Identity principal may do against Google Cloud resources. Organization Policy custom constraints enforce what an AuthProvider may be configured to look like at creation or update time. Context Aware Access enforces that a bound access token cannot be replayed outside its issuing runtime. Auth Manager enforces which stored third party credential a retrieval request may receive. Agent Gateway, where it sits in front of Agent Identity and Gemini Enterprise together, additionally keeps the raw credential from ever reaching the agent. Nothing reviewed for this record documents any of these evaluating the specific consequential action an agent takes once it already holds a valid credential.
  • Documented design
    Agent Identity reached general availability on 14 August 2026. Direct fetch of docs.cloud.google.com, the host serving Google's own IAM release notes, was blocked by this session's network egress proxy on every attempt. The 14 August 2026 general availability date, alongside Auth Manager still in preview, custom Organization Policy constraints for Auth Manager already generally available and VPC Service Controls integration for Agent Identity already generally available that same day, is corroborated across repeated, independently phrased search passes returning consistent detail. An editor with direct browser access should confirm the exact release note wording.
  • Documented design
    Auth Manager, agentidentity.googleapis.com and agentidentitycredentials.googleapis.com reached general availability on 22 August 2026. Direct fetch of docs.cloud.google.com was blocked by this session's network egress proxy on every attempt. The 22 August 2026 general availability date for Auth Manager and its two supporting APIs is corroborated across repeated, independently phrased search passes. This record does not treat 22 August as Agent Identity's own general availability date, which it dates separately to 14 August 2026.
  • Documented design
    Agent Identity is a first class principal type built on SPIFFE, with tokens bound to the agent's own X.509 certificate. Search corroboration consistently reproduces Google's own description of Agent Identity as a new, first class principal type distinct from a human identity or a generic service account, built on the Secure Production Identity Framework For Everyone standard, cryptographically protected, strongly attested and automatically provisioned, tied to the lifecycle of the resource hosting the agent, with access tokens cryptographically bound to the agent's own unique X.509 certificate. This record could not read the underlying attestation mechanism at a lower level than these statements, because docs.cloud.google.com was blocked throughout this session.
  • Documented design
    Agent identities are not shared by multiple workloads by default, cannot be impersonated, and do not allow long lived keys. Search corroboration consistently reproduces this exact three part comparison against service accounts from Google's own documentation. This record does not extend cannot be impersonated or no long lived keys into a claim that an agent identity cannot be compromised, which nothing reviewed states.
  • Unknown
    Agent Identity's documented maturity differs by platform, Agent Runtime against Gemini Enterprise Agent Platform. Search corroboration consistently describes Agent Identity for Agent Runtime, the runtime underlying Vertex AI Agent Engine and Agent Development Kit deployments, as generally available. Some search corroborated material separately describes Agent Identity for Gemini Enterprise Agent Platform as still in preview. This record could not resolve that inconsistency because docs.cloud.google.com, where the current, authoritative maturity label for each platform could be read side by side, was blocked throughout this session.
  • Documented design
    Google's own audit logs can carry both the agent's identity and a represented user's identity. Search corroboration consistently reproduces Google's own claim that Agent Identity integrates with audit logging to show both the agent's own identity and, when it acts on a user's behalf, the represented user's identity. This record scopes that claim to Google's own Cloud Audit Logs for actions against Google Cloud resources, and does not extend it to what a third party API or SaaS system the agent subsequently calls receives, logs or retains, which nothing reviewed for this record documents.
  • Documented design
    Auth Manager is a centralized credentials vault and authentication broker for API keys, two legged OAuth and three legged OAuth. Search corroboration consistently reproduces Google's own description of Auth Manager storing API keys, OAuth client secrets and delegated end user tokens in a Google managed store behind AuthProvider configuration objects, supporting API key authentication, two legged machine to machine OAuth and three legged, user delegated OAuth.
  • Documented design
    In the direct, ADK mediated retrieval path, the agent itself receives and attaches the raw credential. Search corroboration consistently reproduces a specific flow: a user triggers an event requiring outbound tool authentication, the deployed agent, using the Agent Development Kit, intercepts the tool request, queries Auth Manager, Auth Manager returns the API key or OAuth token, and the agent itself attaches that credential and invokes the external API. This record treats this as the credential exposure baseline for direct Auth Manager use, distinct from the Agent Gateway architecture below.
  • Documented design
    With Agent Gateway and Gemini Enterprise, end user credentials are encrypted by Auth Manager and decrypted only at the gateway, so the agent never sees the raw credential. Search corroboration consistently reproduces this as a distinct, stronger architecture specific to Agent Identity used together with Agent Gateway and Gemini Enterprise, where a Gemini Enterprise connector provisioned credential is encrypted by Auth Manager and decrypted only at the gateway. This record does not extend this stronger guarantee to Vertex AI Agent Engine or plain Agent Development Kit deployments that are not also sitting behind Agent Gateway, because nothing reviewed documents that extension.
  • Documented design
    A custom Organization Policy constraint can deny creating or updating a three legged OAuth AuthProvider that does not have PKCE enabled. Search corroboration consistently confirms a custom constraint scoped to the agentidentity.googleapis.com AuthProvider resource, applicable to CREATE and UPDATE methods, with a worked example denying an operation that would create or modify a three legged OAuth AuthProvider without PKCE enabled. This record could not read the exact YAML condition syntax directly, because docs.cloud.google.com was blocked throughout this session, and treats this as configuration time enforcement over how an AuthProvider may be built, not execution time enforcement over what a specific agent later does with the resulting credential.
  • Unknown
    Whether allowedScopes and blockedScopes constrain AuthProvider configuration only, or reach further into issued token scope or per agent retrieval. Search corroboration surfaced the field names allowedScopes, blockedScopes and workloadIds as associated with AuthProvider custom constraints, without this record being able to confirm their precise operational reach, because docs.cloud.google.com could not be fetched directly in this session. This record does not assume these fields narrow an already issued OAuth token's scope, or that they operate as action level runtime permissions, absent direct confirmation.
  • Documented design
    An AuthProvider's workloadIds field can name more than one agent identity, allowing a third party credential to be shared across agents. Search corroboration surfaced Google's own gcloud command reference documenting workloadIds as accepting one or more agent identity principals in the format principal://agents.global.org-ORG_ID.system.id.goog/resources/aiplatform/projects/PROJECT_ID/locations/LOCATION. This record treats this as evidence that per agent identity is not the same guarantee as per agent third party credential isolation, which Auth Manager makes configurable rather than guaranteeing by default.
  • Documented design
    A default Context Aware Access policy enforces mTLS and DPoP so a bound access token cannot be replayed outside its issuing runtime. Search corroboration consistently confirms a default Context Aware Access policy for Agent Identity enforcing mutual TLS to Agent Gateway and DPoP binding on the agent's access token, described by Google as making stolen bound credentials unreplayable, with a documented opt out that removes that protection for specific token sharing needs.
  • Unknown
    What deleting an Agent Identity, modifying an AuthProvider or revoking an IAM grant does to an already issued credential or active session is documented. Search corroboration confirms these revocation controls exist. Nothing reviewed for this record documents whether a credential already retrieved through Auth Manager, or a token an agent already holds mid session, is immediately invalidated by one of these actions, or continues to work until its own natural expiry.
  • Unknown
    A mechanism exists for a human approver to challenge or hold a specific proposed action once an agent already holds a valid credential. Nothing reviewed for this record, inside Agent Identity, Auth Manager, Organization Policy or Context Aware Access, names a challenge mechanism operating at the moment an agent is about to use an already issued, valid credential. Google's own separately documented Agent Gateway Semantic Governance Policy check is the closer analogue and is treated as a distinct capability, verified in Moona Intelligence's own earlier coverage of execution authority, not as part of Agent Identity or Auth Manager's own documented scope.
  • Unknown
    A generic mechanism exists for reversing an external tool action after it has executed. Nothing reviewed for this record describes a recovery path, inside Agent Identity or Auth Manager, for an external action already taken with a validly issued credential. Identity and credential revocation govern what happens next, not what has already happened.
  • Unknown
    A governance or resource ownership requirement, beyond technical IAM permission, is documented for who may configure an AuthProvider or grant it a scope. Nothing reviewed for this record, across Google's own IAM, Auth Manager or Organization Policy documentation, describes a specific organizational entitlement, resource ownership rule, delegated administration boundary or approval workflow that must be satisfied before a technically permitted administrator may configure an AuthProvider or grant it a scope. Technical IAM permission to configure it is documented. A separate organizational mandate to do so is not, the same gap Moona Intelligence has already found in GitLab's composite identity, Uber's actor chain architecture and Okta's Cross App Access.
Sources (7)

Agent Authorization Envelope (AAE)

L. K. Kroehl, CryptoKRI GmbH, individual submission to the IETF · Specification · Unknown license
Updated 21 August 2026

Individual Internet Draft, Independent Submission, revision 01, intended status Informational, expires 12 February 2027

Evidence at a glance
  • Documented design14
  • Vendor claim only1
  • Not supported2
  • Unknown2
Runtime enforcement: UnknownDelegated authority: Documented designHuman approval: No evidenceRevocation & expiry: UnknownAudit & attestation: No evidenceBypass resistance: No evidence
Moona Intelligence reading

AAE specifies agent authorization as a bounded, expiring grant rather than a standing credential, with a required rule that keeps a delegated grant inside its parent's scope. It is a young individual IETF submission built on the author's own reported deployment, read here from excerpts rather than the full draft.

View evidence (19 properties, 5 sources)
Vendor
L. K. Kroehl, CryptoKRI GmbH, individual submission to the IETF
Artifact
Specification
License
Unknown
Announced
11 August 2026
Maturity
Individual Internet Draft, Independent Submission, revision 01, intended status Informational, expires 12 February 2027
Enforcement point
A relying party that receives the envelope, checks its MANDATE, CONSTRAINTS and VALIDITY blocks, and follows what a supplied excerpt describes as a defined ordered sequence of checks, before permitting the agent's action. The draft names no reference evaluator implementation, and none tied to this specific draft was found public this session.
  • Documented design
    Draft exists as an Internet Draft on the IETF Datatracker. Multiple independent search results reflecting Datatracker content, and separately a document supplied to this session presenting itself as an excerpt packet for this draft, agree on the title, Agent Authorization Envelope (AAE): A Machine Evaluable Authorization Structure for Autonomous AI Agents, the author L. K. Kroehl of CryptoKRI GmbH, revision 01 published 11 August 2026, the Independent Submission stream, intended status Informational, and an expiry of 12 February 2027. datatracker.ietf.org and ietf.org were blocked by this session's network egress policy on every direct fetch attempt, so this entry is corroborated rather than independently read this session. Whether an earlier revision 00 exists, and its date, was not confirmed either way.
  • Not supported
    Adopted by the IETF, assigned to a working group, or published as an RFC. Every corroborating result describes this as an individual submission in the Independent Submission stream with intended status Informational and names no working group. It carries no RFC number. It is a personal Internet Draft, not an adopted IETF work item, not an RFC, not IETF endorsed, and not a standard.
  • Documented design
    Authorization is carried as three mandatory blocks. A passage supplied to this session as a verbatim excerpt of the draft states that AAE defines three mandatory blocks, MANDATE, CONSTRAINTS and VALIDITY, that together constitute a machine evaluable, cryptographically verifiable authorization assertion. MANDATE is the block that states what the agent is permitted to do, CONSTRAINTS the block that bounds it under what conditions, and VALIDITY the block that establishes whether the authorization is still effective. Graded documented, not verified, since this agent has read the supplied excerpt rather than the draft itself.
  • Documented design
    MANDATE defines permitted purpose, action patterns and delegation rules. MANDATE is described as carrying a permitted purpose expressed through enumerated categories such as commerce, data_read and data_write, together with allowed and denied action patterns and delegation rules. This is the block that states what the agent may attempt at all, before any constraint is applied.
  • Documented design
    CONSTRAINTS bounds the mandate with concrete limits. CONSTRAINTS is described as carrying time windows, financial thresholds, jurisdictions, counterparty minimums and obligations, alongside the transaction value, domain and rate limit members addressed separately below. This is the block that narrows a permitted action to the specific conditions under which it may run.
  • Documented design
    VALIDITY sets the temporal bounds of the authorization. A passage supplied to this session as a verbatim excerpt of the draft confirms not_before and not_after are each REQUIRED fields, the same required versus optional treatment described in the constraint-required-optional property above. Search corroborated material used to build the earlier version of this record separately described VALIDITY as also carrying issuer identity and a holder binding to a specific decentralized identifier; those elements are not part of what the supplied excerpts confirm, so they are recorded here as search corroborated rather than as confirmed by the supplied packet. See revocation-behavior for why a specific revocation mechanism is graded unknown rather than repeated as fact.
  • Documented design
    A numeric transaction value ceiling is defined with delegation comparison rules. Search indexed draft text describes a numeric upper bound constraint, given as max_transaction_value, and states that when this constraint is delegated the delegated value must be less than or equal to the parent value. This is a narrowing rule: a sub delegation can only lower a spending ceiling, never raise it.
  • Documented design
    An allowed domains constraint is defined as an allowlist that can only narrow. Search indexed draft text describes an allowlist constraint, given as allowed_domains, and states that a delegated value must be a subset of the parent value. A sub delegation can restrict which domains or counterparties an agent may reach, and cannot add ones the parent grant did not already permit.
  • Documented design
    A rate limit constraint is defined with an explicit comparison rule. Search indexed draft text describes a rate_limit constraint and states that, absent a profile defining other comparison semantics, a delegated rate limit must use the same window as the parent constraint and the delegated value must be less than or equal to the parent value. The draft is explicit that a relying party cannot assume a narrower rate limit unless it can prove no execution pattern the delegated limit permits would violate the parent limit.
  • Documented design
    Whether individual CONSTRAINTS members are mandatory or may be omitted per envelope. A passage supplied to this session as a verbatim excerpt of the draft states that relying parties MUST enforce all constraints they recognize, that a relying party MUST reject an AAE if any constraint marked required: true is unrecognized or cannot be evaluated, that a relying party MAY ignore an unrecognized constraint only when it is explicitly marked required: false, and that an absent required member MUST be treated as required: true. A separate excerpt states not_before and not_after are each REQUIRED. Taken at face value this resolves the question: individual CONSTRAINTS members carry a per member required flag that defaults to true, while VALIDITY's temporal bounds are unconditionally required. Graded documented rather than verified: this agent has read the supplied excerpt, not the draft itself, since datatracker.ietf.org and ietf.org, including the specific archive URL supplied alongside the excerpt, remained blocked on renewed attempts this session.
  • Documented design
    Delegation is required to be strictly subordinate to its parent. A passage supplied to this session as a verbatim excerpt of the draft states that implementations MUST enforce that delegated AAEs are strictly subordinate to their parent AAEs in actions, constraints and validity. The transaction value, domain and rate limit comparison rules elsewhere in this record are each a plausible concrete instance of that same subordination principle, though the excerpt supplied to this session states the general MUST rather than each field level comparison. Graded documented rather than verified, for the reason given on the constraint-required-optional property above.
  • Documented design
    The envelope is secured with JOSE and JWS using a named signature algorithm. A passage supplied to this session as a verbatim excerpt of the draft states an AAE MUST be secured using JOSE, that the Verifiable Credential is the payload of a JSON Web Signature in compact serialization, and that it is signed by the issuer using the Edwards curve Digital Signature Algorithm with the Ed25519 curve. Graded documented rather than verified, for the reason given above.
  • Documented design
    A relying party follows a defined ordered algorithm, not only conceptual guidance. A passage supplied to this session as a verbatim excerpt of the draft states that a relying party receiving an agent request with an attached AAE MUST perform a sequence of checks in order. The excerpt supplied to this session establishes that an ordered algorithm exists but does not include the individual checks that make it up, so what those steps are, and in what order, remains unconfirmed by what is available to this agent. Graded documented for the existence of an ordered algorithm, not for its contents.
  • Unknown
    Revocation is named as a VALIDITY concern, but its specific mechanism is unconfirmed. Earlier search indexed material used to build this record described VALIDITY as carrying a revocation endpoint URL and mandatory expiry with open ended credentials not permitted. Nothing in the excerpt supplied to this session names a revocation mechanism, an endpoint, or how a relying party behaves when a revocation check cannot complete, so that specific claim is not repeated here as fact. Graded unknown: the supplied excerpts confirm not_before and not_after are required temporal fields, but not what revocation itself consists of.
  • Documented design
    The envelope depends on W3C decentralized identifier and verifiable credential infrastructure. The draft is described as protocol agnostic while binding to W3C Decentralized Identifiers for agent identity and W3C Verifiable Credentials for the envelope itself, with the holder binding naming a single decentralized identifier the envelope must not be used by any other agent. An implementer needs a working DID and VC issuance and resolution path before this envelope format is meaningful on its own.
  • Not supported
    A similarly named public GitHub framework is a reference implementation of this draft. A public repository, massivescale-ai/agentic-trust-framework, surfaced during this session's research under a similar name. Its README was fetched directly this session and shows it is the Agentic Trust Framework (ATF), a five element Zero Trust governance specification published through the Cloud Security Alliance at specification version 0.9.1 dated April 2026, four months before this draft was posted. It defines no MANDATE, CONSTRAINTS or VALIDITY blocks, and names no connection to L. K. Kroehl, CryptoKRI GmbH or this Internet Draft. It is an unrelated project and is not evidence of an implementation of AAE.
  • Documented design
    The draft cites a same author arXiv paper as the origin of the specification. A passage supplied to this session as a verbatim excerpt states that the AAE specification is derived from the MolTrust production deployment documented in a reference the draft calls [ARXIV-AAE], and a second supplied passage states the draft's informative references identify [ARXIV-AAE] as arXiv:2605.06738 by Lars Kersten Kroehl. If accurate this establishes the citation by the draft's own text rather than by search engine name matching, which is what this record relied on before. This agent has not itself retrieved or read arXiv:2605.06738, the draft's references section, or the draft as a whole: arxiv.org, datatracker.ietf.org and ietf.org all remained blocked on renewed attempts this session, including against the specific archive URL supplied alongside the excerpts. The citation itself is graded documented, not verified, on that basis. The deployment claim it carries is a separate question, addressed in the adoption property below rather than promoted here: the draft and the cited paper share the same sole author, so even a confirmed citation would not make MolTrust independent evidence.
  • Unknown
    Intellectual property rights disclosure status. No IPR disclosure was found or ruled out for this draft. The supplied excerpts are explicit that they do not resolve IPR status and that it should be kept unknown absent independent inspection, and this record follows that instruction: the Datatracker's IPR tab was not independently inspected because direct fetch was blocked on every attempt. This remains unconfirmed, not confirmed absent.
  • Vendor claim only
    Adoption by anyone other than the author. A passage supplied to this session as a verbatim excerpt states that the AAE specification is derived from the MolTrust production deployment documented in the paper the draft cites as [ARXIV-AAE]. If accurate, that is the author's own account of the author's own system: the draft and the cited paper share their sole author, Lars Kersten Kroehl, so this is graded as an author reported deployment claim rather than as independent adoption, and this agent has not itself read either document to confirm the claim beyond the supplied excerpt. No named implementer, adopter, working group discussion or interoperability report independent of the author was found for this draft.
Sources (5)

x401, the HTTP Proof Requirement Protocol

Proof, with editors from Proof and Circle and reviewers from Lightspark, MATTR, Okta, OpenAI and Visa · Specification · Open license
Updated 22 August 2026

Public working draft, version 0.2.0, developed openly on the proof slash x401 GitHub repository under the Apache License 2.0.

Evidence at a glance
  • Verified in artifacts12
  • Documented design3
  • Vendor claim only3
  • Unknown4
Runtime enforcement: Documented designDelegated authority: UnknownHuman approval: No evidenceRevocation & expiry: UnknownAudit & attestation: Vendor claim onlyBypass resistance: No evidence
Moona Intelligence reading

x401 lets a resource server demand a route specific proof and decide if it is satisfied, leaving delegation, agent binding and authorization as optional pieces a deployment composes. It does not establish that a credential's subject was entitled to grant authority, or offer a way to revoke or challenge later.

View evidence (22 properties, 10 sources)
Vendor
Proof, with editors from Proof and Circle and reviewers from Lightspark, MATTR, Okta, OpenAI and Visa
Artifact
Specification
License
Open
Announced
25 June 2026
Maturity
Public working draft, version 0.2.0, developed openly on the proof slash x401 GitHub repository under the Apache License 2.0. No IETF, W3C or OpenID Foundation stream, no working group, and no tagged release exists in the repository; the version number lives only in the specification's own header and in an archived copy of the prior 0.1.0 text kept alongside the current draft. The specification's own status line reads Draft.
Enforcement point
The Verifier, meaning the protected resource or an entity acting for it, composes the route specific proof requirement, receives the Agent's retried request, and decides whether the presented result satisfies that requirement before the protected operation is allowed to proceed. The specification states the Verifier remains authoritative for proof validation regardless of how the Agent interprets the requirement. No separate enforcement component is named; enforcement is the Verifier's own authorization logic, running wherever that Verifier already runs.
  • Verified in artifacts
    x401 is a public working draft, not an adopted standard. Fetched directly from the proof slash x401 GitHub repository this session. The specification's own header reads x401: HTTP Proof Requirement Protocol, Status Draft, Version 0.2.0. The repository carries no tagged release, and its README describes the specification itself as a working draft. It is not an IETF Internet Draft, not a W3C document and not an OpenID Foundation specification, and it names no working group or standards body behind it. It is an open specification developed by Proof with named external editors and reviewers, not an industry standard.
  • Verified in artifacts
    The specification changed materially between the 25 June 2026 launch and version 0.2.0. Fetched directly this session, both the archived versions/0.1.0/spec.md and the current spec.md. Version 0.1.0 required Agent binding: it stated the Agent MUST identify itself to the Wallet with an Agent Identifier matching the protected route's HTTP caller, and the Verifier MUST bind the returned presentation to that identifier. Version 0.2.0 changed this to optional, stating plainly that Agent binding is OPTIONAL in x401. Version 0.1.0 treated delegation evidence as an unresolved open question; version 0.2.0 adds a specific, named list of delegation evidence mechanisms and a composability statement. The repository's own CHANGELOG entry for 0.2.0, read directly, documents further that the Verifier now composes the presentation request itself, where 0.1.0 had the Agent construct an OpenID4VP request; that the proof wrapper object was removed; that two Verifier binding modes, signed and unsigned, were introduced; and that by reference presentation delivery was added. This session could not establish the exact calendar date version 0.2.0 was published: the repository carries no release or tag, and the commit history retrievable this session runs from 22 June 2026 through 1 July 2026 without a commit mentioning 0.2.0, so the specific publication date of the 0.2.0 revision is left unknown rather than assumed to be the 22 August 2026 verification date.
  • Verified in artifacts
    The protocol runs over three dedicated HTTP headers and a retry. Fetched directly this session. Version 0.2.0 defines PROOF-REQUEST, carrying the Verifier's base64url encoded proof requirement payload; PROOF-RESPONSE, carrying the Agent's Result Artifact or proof satisfaction token on retry; and PROOF-RESULT, carrying the Verifier's verification response or error information. The flow is the Verifier declaring a requirement, the Agent obtaining a credential result through native invocation, relay or remote generation, the Agent retrying the original protected route with the result, and the Verifier deciding whether to allow the operation. This differs from version 0.1.0, which used PROOF-REQUIRED, PROOF-PRESENTATION and PROOF-RESPONSE with different semantics, confirming the header names themselves changed between versions rather than staying stable while the surrounding text was polished.
  • Verified in artifacts
    A Verification Token is a distinct artifact from an application's own Authorization credential, and the two coexist. Fetched directly this session. The specification defines a Verification Token as a verifier issued, short lived access token returned after successful proof verification and used by the Agent on later protected route requests. It states directly that if the protected route already requires an application token in Authorization, and the x401 Verification Token is separate from that application token, the Agent SHOULD preserve the existing Authorization value. The specification does not describe the Verification Token as a new issuer attestation about the credential subject; it records the Verifier's own decision that a presented result satisfied the proof requirement for that route.
  • Verified in artifacts
    Agent binding is explicitly optional, and the credential result binds to the Verifier by default. Fetched directly this session. The specification states in its own words that Agent binding is OPTIONAL in x401, and separately that x401 does not, by default, require the result to be bound to the Agent. The Agent Identifier is defined as an optional identifier for the Agent that a Verifier MAY bind to the HTTP caller. A deployment that wants the presented credential result tied to the specific calling Agent has to add that binding itself; the base protocol does not supply it by default.
  • Verified in artifacts
    The specification names several optional mechanisms a deployment can add for caller binding. Fetched directly this session. Named mechanisms include Web Bot Auth and HTTP Message Signatures for request layer caller authentication, OAuth proof of possession and mTLS for certificate and key bound authentication, DPoP for application layer proof of possession, and workload identity systems including SPIFFE IDs, JWT-SVIDs or WIMSE tokens for service to service scenarios. The specification states it mandates no single agent identity system, and that any mechanism used must not alter the composed request or the payment boundary.
  • Verified in artifacts
    Workload identity is documented as proving operational identity only, not credential holding, subject authorization or user delegation. Fetched directly this session, quoted verbatim from the specification: workload identity proves the caller's operational identity. It does not prove that the caller holds the requested credential, that the credential subject is authorized, or that an end user delegated authority to the Agent. This is the specification's own stated limit on one of the caller binding mechanisms it names, not an inference by this record.
  • Verified in artifacts
    Delegation evidence can be carried through several named mechanisms, composable with but separate from proof satisfaction. Fetched directly this session, quoted verbatim: delegation evidence can be carried as an additional credential, a credential disclosed through the request's dcql_query, an OAuth Token Exchange actor chain, a GNAP grant artifact, a Verifiable Intent credential, or another signed mandate or capability. This is a list of mechanisms the protocol can carry, not a single mandatory delegation format, and DCQL, the Digital Credentials Query Language, is the same mechanism through which the Verifier's composed presentation request already expresses ordinary credential requirements.
  • Verified in artifacts
    Delegation evidence composes best when scoped, time limited, replay resistant and bound to the Agent Identifier and the requested resource or action, stated as guidance rather than a universal guarantee. Fetched directly this session, quoted verbatim: delegation evidence composes best when it is scoped, time limited, replay resistant, and bound to the Agent Identifier and requested resource or action. The wording is composes best, not a MUST requirement that every transaction carry evidence with these properties. Delegation evidence is optional protocol machinery a deployment can add; nothing in the specification requires that it be present, and the composability sentence describes how it should be shaped when a deployment chooses to add it, not a guarantee every x401 transaction carries it.
  • Documented design
    The base protocol does not define who or what may be the authority grantor behind a credential. The specification is credential and issuer neutral, read directly this session: it defines how a Verifier composes and checks a proof requirement against whatever credential a DCQL query selects, and it does not itself require the credential subject to be a natural person, an organization or any other specific kind of grantor. Graded documented because this neutrality is what the specification's own header composition and delegation evidence sections describe, not because any artifact independently confirms a non human grantor deployment running in practice.
  • Vendor claim only
    Proof's own implementation, distinct from the base protocol, describes an IAL2 verified human as the grantor who signs a mandate. Direct fetch of proof.com and x401.id is blocked by this session's network egress proxy. Content corroborated through multiple independently phrased search passes returning consistent detail: Proof's own material describes a human verified once to IAL2 through biometric and government ID, enrolled in a cloud wallet, whose identity is re bound per mandate rather than per session, signing a scoped mandate naming the agent, the merchant, an action category, an amount ceiling and a time window. This is Proof's own account of Proof's own implementation, not a requirement the base x401 specification imposes on other issuers or deployments, and it is graded as a vendor claim about Proof's own product rather than independently verified. Editor should confirm directly in browser.
  • Unknown
    Neither the base protocol nor Proof's own material establishes that a mandate signer held legitimate authority to delegate. IAL2 verification, as Proof itself describes it, establishes who the signing human is. Nothing independently available to this session, in the base specification or in Proof's own corroborated material, establishes a mechanism for checking that the signing human held a corporate office, an account ownership right, a contractual authority or another organizational mandate that actually entitled them to authorize the specific action the mandate describes. No organizational credential or signing authority credential feeding into x401 or Proof's mandate was found by this session. Recorded as unknown rather than assumed present, because identity of a grantor and legitimacy of a grant are different facts, and nothing found here establishes the second.
  • Documented design
    The delegated scope dimensions named in Proof's implementation are not fields the base protocol itself requires. Proof's own corroborated material names agent, merchant, action category, amount ceiling and time window as mandate fields, cryptographically signed so the agent cannot exceed them. The base x401 specification, read directly this session, names none of these fields; it defines how a Verifier composes a credential requirement through DCQL and how delegation evidence can optionally be attached, leaving the actual content of any mandate or scope to the credential issuer and the Verifier's own policy. Attributing Proof's five named fields to the x401 specification itself would be inaccurate; they are graded here as Proof's own implementation choice.
  • Documented design
    Time and amount limits appear only where an implementer's own mandate format defines them, not in the base protocol. Proof's corroborated material states its mandate carries an amount ceiling and a time window that the agent cannot exceed. The base specification, read directly this session, defines no amount or time limit fields of its own; the delegation evidence section names mechanisms rather than a required field schema. Recorded as documented at the implementer level, not verified as a base protocol guarantee.
  • Verified in artifacts
    The specification keeps ordinary application authorization, workload identity and delegation evidence as separate, coexisting layers. Fetched directly this session. The Verification Token coexistence language, the workload identity limitation quoted above, and the optional delegation evidence section together keep three things distinct: an application's own Authorization credential, proof that a route specific credential requirement was satisfied, and evidence of who or what authorized the Agent to act. The specification does not describe any one of the three as substituting for another, and explicitly warns that workload identity alone does not establish that an end user delegated authority to the Agent.
  • Unknown
    Whether revoking the underlying mandate or credential immediately invalidates an already issued Verification Token is undocumented. The specification states a Verification Token SHOULD be short lived and describes token validation in terms of scope, audience, expiration and Agent binding, read directly this session. It does not state what happens to a Verification Token already issued if the credential or delegation evidence behind it is later revoked, and this session found no revocation endpoint, propagation rule or dedicated security considerations section addressing this case. Recorded as unknown rather than assumed either way.
  • Verified in artifacts
    The Verifier controls which credentials, issuers, assurance levels and bindings satisfy a protected route. Fetched directly this session. The Verifier composes the proof requirement, and the specification states the Verifier remains authoritative for proof validation regardless of Agent side interpretation. This establishes who decides whether presented proof is sufficient for one specific request. It is a separate question from whether an original grantor, issuer or organization can later challenge or invalidate the delegation itself, addressed in the next property.
  • Unknown
    Whether an original grantor, issuer, verifier or organization can later challenge or invalidate an already accepted delegation is not addressed. Nothing read directly by this session in the base specification names a channel through which a grantor, issuer, resource owner, auditor or regulator can dispute or invalidate a delegation already accepted by a Verifier. The specification's scope is proof composition and validation at the moment of a request, not a dispute process afterward. Recorded as unknown.
  • Unknown
    No rollback, compensation, dispute or reversal mechanism for an already executed action is defined by the base protocol. Read directly this session: the specification contains no dispute resolution, rollback, compensation or reversal language of any kind. It ends at the Verifier's decision to permit or refuse the protected operation; what happens after a permitted action has already executed, if that action later needs to be reversed, sits entirely outside what x401 defines. Recorded as unknown, and Proof's own corroborated material does not fill this gap either.
  • Vendor claim only
    Non repudiable is Proof's own characterization of its evidence, not an independently established legal or cryptographic guarantee. Direct fetch of proof.com is blocked by this session's network egress proxy. Search corroborated material attributes to Proof the claim that binding a credential, assurance level, scope and challenge together at the moment of authorization produces a non repudiable record. Non repudiation in the strict sense requires an artifact a party cannot later credibly deny producing under adversarial conditions; nothing independently available to this session tests that property, and this record attributes the claim to Proof rather than adopting it as an established fact.
  • Verified in artifacts
    Editors and reviewers named in the specification are individuals with listed organizational affiliations, not their organizations endorsing the draft. Fetched directly this session from the specification's own front matter. Editors are Daniel Buchner of Proof and Bhushit Agarwal of Circle. Reviewers are Jacky Lao of Lightspark, Oliver Terbu and Tobias Looker of MATTR, Tim Cappalli of Okta, Nick Steele of OpenAI, Darren Louie and Adam Lemmon of Proof, and Tony England and Steven Sacia of Visa. A separate commit message, read directly, credits changes requested from Google, OpenAI and Okta's FIDO representatives, though Google does not appear in the specification's own formal editors or reviewers list. None of this constitutes Circle, Lightspark, MATTR, Okta, OpenAI, Visa or Google adopting, deploying or organizationally endorsing x401; it documents that named individuals affiliated with those organizations participated in reviewing draft text.
  • Vendor claim only
    Circle is a named early adopter and co-endorser; payments and insurance adopters beyond Circle are vendor claims, unnamed. Circle's own public statements, corroborated through multiple independent search passes quoting Circle's account directly, describe Circle as proud to be an early adopter and co-endorser of x401, with Circle's own framing that x402 answers how an agent pays and x401 answers who authorized the action. That is Circle's own statement about its own participation, not merely Proof describing Circle, and is graded above the level of an unnamed vendor claim on that basis. Separately, Proof's own corroborated material describes unnamed organizations in payments and enterprise insurance as already building on x401, including an unnamed Tier 1 insurer evaluating it for customer authorized agents filing claims, opening accounts and submitting applications. Those unnamed claims are graded claimed and are not treated as independently verified production adoption. Editor should confirm directly in browser.
Sources (10)

Agent Control Layer

Rain · Implementation · Proprietary license
Updated 20 August 2026

Beta, by the vendor's own announcement, which in the same release describes it as production ready infrastructure.

Evidence at a glance
  • Documented design9
  • Vendor claim only3
  • Not supported3
  • Unknown3
Runtime enforcement: Vendor claim onlyDelegated authority: No evidenceHuman approval: Not supportedRevocation & expiry: Documented designAudit & attestation: No evidenceBypass resistance: Unknown
Moona Intelligence reading

Taken at the vendor's word, Rain's Agent Control Layer encodes an agent's spending boundaries, merchant, amount, task, window and frequency, before a transaction executes. What remains unestablished is whether enforcement behaves as described at that boundary, and the coalition Rain launched around these claims has membership but no published artifact.

View evidence (18 properties, 7 sources)
Vendor
Rain
Artifact
Implementation
License
Proprietary
Announced
9 June 2026
Maturity
Beta, by the vendor's own announcement, which in the same release describes it as production ready infrastructure. The card issuing and money movement rails underneath it are the vendor's existing commercial business. No property in this record is graded as verified in directly inspected artifacts: the vendor's pages and API documentation could not be reached from the verification environment, so every property rests on corroborated announcement, product page and independent press content.
Enforcement point
Card issuance and transfer initiation inside the vendor's issuing and money movement APIs, with the governing rules stated to be in place before a transaction is attempted, as described by the vendor
  • Documented design
    The Agent Control Layer was publicly announced on 9 June 2026. Rain's press release and its own resource page, dated 9 June 2026, describe the Agent Control Layer as a capability embedded across Rain's APIs for controlling how AI agents spend on cards and move money on behalf of users. Corroborated across multiple independent search passes; direct page inspection was blocked in the verification environment.
  • Documented design
    The product is in beta by the vendor's own statement. The announcement states the Agent Control Layer is available in beta. The same release calls it production ready infrastructure. Both statements are recorded and not collapsed: the branded control layer is the part in beta, while the card and payment rails underneath are the vendor's existing production business.
  • Documented design
    Card authority is scoped by merchant, category, amount, interval and expiry. The announcement and product pages describe configurable controls covering acceptable merchant category codes, approved merchants or payment recipients, transaction amounts, transaction frequency, spend intervals and card expiry, defined before the agent acts.
  • Documented design
    Program level caps bound the fleet, not only the card. Partners are described as capping the number of active agent cards at any given time and setting aggregate spend limits across their whole user base, alongside visibility intended to surface unusual patterns early.
  • Vendor claim only
    Cards are scoped to a task and retired when it completes. The product page describes virtual cards scoped to specific merchants, amounts and tasks, retired the moment the task is complete. No public material reached for this record describes the retirement mechanism, its trigger, or whether a retired card can be reused, so the lifecycle language is recorded as product language rather than a documented control.
  • Documented design
    The same parameters extend to money movement beyond cards. The announcement states the layer extends across the vendor's money movement suite, including virtual accounts, onramps, offramps and fiat and stablecoin payments, with approved counterparties, amounts, frequency and timing defined before an agent is permitted to act.
  • Documented design
    Rules exist before the transaction is attempted. The vendor states its parameters are enforced at card issuance and transfer initiation rather than applied after the fact, so the governing rules are already in place by the time an agent attempts to transact.
  • Vendor claim only
    A transaction outside the configured parameters fails before money moves. The vendor states that outside the configured parameters the card does not transact and a transaction that falls outside the rules does not proceed. The vendor's API documentation could not be reached from the verification environment, and no public artifact demonstrates a declined transaction, so the failure behavior rests on vendor statements alone.
  • Documented design
    Changes to configured payment terms require a human administrator. The announcement states that changes to configured payment terms require explicit action by a human administrator, in an example of agents restricted to approved vendors on a defined schedule for a defined amount. This is configuration authority, not per transaction approval. Who qualifies as an administrator, what authentication is required, and whether an agent can request a change are not publicly documented.
  • Not supported
    A human approves each individual transaction. Nothing in the vendor's public material describes per transaction human approval. Inside the configured limits the agent transacts without a person confirming each payment. The human role the vendor describes is setting and changing the configuration, not approving individual transactions.
  • Unknown
    Nothing but a human can widen an agent's limits. The human administrator statement covers changes to configured payment terms in the vendor's example. Whether every limit class can only be changed by a human, and what technically prevents a partner integration from widening limits programmatically, is not described in any public material reached for this record.
  • Vendor claim only
    Agents transact on this infrastructure in production. The vendor states agents have been transacting on its infrastructure in production for months, booking travel, subscribing to software, executing procurement workflows and moving money. No independent reporting, metrics, or case study of that activity was found, so the claim is recorded as vendor reported.
  • Documented design
    A named partner issues agent usable cards on the platform. The vendor names Sponge, a Y Combinator backed company issuing virtual cards against a user's stablecoin balance for agent use. Sponge's own site corroborates the issuing relationship from its side, describing its card as issued by Rain. Volumes and actual agent usage remain vendor reported.
  • Unknown
    A permitted transaction leaves signed evidence of the authorization decision. Visibility and monitoring appear in the vendor's material. No public material describes a record, signed or otherwise, binding a permitted transaction to the constraints it was evaluated against.
  • Documented design
    The Agentic Payments Alliance exists as a working coalition. Rain launched the Agentic Payments Alliance on 18 August 2026 with more than 25 members, founding members including Visa, Mastercard, Fiserv, Circle, Solana and Remitly, described as a working coalition run collectively by founding members who will set its charter and mission together. Independent same day coverage from American Banker and PYMNTS corroborates the launch, the membership and named focus areas including agent authorization.
  • Not supported
    The Alliance has published an authorization standard. At verification the Alliance had published no standard, no technical specification, no repository and no interoperability test, and its charter did not yet exist. Independent reporting describes early work as shared research and frameworks, experimentation with emerging standards for agent identity and authorization, and regulatory advocacy. A named focus area is intent, not an artifact.
  • Not supported
    Alliance membership implies adoption of the Agent Control Layer. Membership establishes participation in a coalition Rain convened and nothing about whether any member uses the vendor's products. The vendor's materials do not claim it does, and this record does not either.
  • Unknown
    Enforcement demonstrated publicly. No public artifact, demonstration, test or independent review shows any of these controls refusing a transaction or a transfer. Every enforcement statement traces back to the vendor.
Sources (7)

Grantex and the Delegated Agent Authorization Protocol (DAAP)

Sanjeev Kumar, Grantex · Specification and client SDK · Open license
Updated 23 August 2026

Two documents of one architecture, from one author.

Evidence at a glance
  • Verified in artifacts10
  • Documented design6
  • Unknown3
Runtime enforcement: Documented designDelegated authority: Verified in artifactsHuman approval: No evidenceRevocation & expiry: UnknownAudit & attestation: Documented designBypass resistance: No evidence
Moona Intelligence reading

Grantex enforces attenuation concretely, a delegated grant cannot exceed or outlive its parent, and revoking it cascades through everything beneath it, verified against the specification's own text. But one of Grantex's shipped packages does not check revocation, and nothing establishes that a grantor held legitimate authority to grant.

View evidence (19 properties, 13 sources)
Vendor
Sanjeev Kumar, Grantex
Artifact
Specification and client SDK
License
Open
Announced
25 February 2026
Maturity
Two documents of one architecture, from one author. The Grantex Protocol Specification, version 1.0, states its own status as Final and reads, quoted directly from the file fetched this session: Specification is now frozen. Changes require a new version, with a last updated line reading February 2026, revision 3. Alongside it, an individual Internet Draft, draft-mishra-oauth-agent-grants, was corroborated through independently phrased search passes as revision 00 published 27 February 2026 and revision 01 published 2 March 2026, both with intended status Informational, both authored by S. Kumar of Grantex. datatracker.ietf.org and ietf.org were blocked by this session's network egress policy on every attempt, so the draft's own text was not read directly and its chronology and content are recorded as documented rather than verified. A public monorepo, Apache 2.0 licensed, ships a reference authorization service, SDKs for TypeScript, Python and Go, a CLI, MCP packages and 29 framework integrations, fetched and read directly this session. Final describes the specification's own frozen status inside the Grantex project. Nothing found by this session states or implies IETF adoption, working group status or industry standard status for either document.
Enforcement point
A Grantex authorization service issues and can revoke RS256 signed grant tokens. A receiving service verifies a token, either offline against Grantex's published JWKS or online against the authorization service's current state, and only then permits the operation. The specification itself states that high stakes scopes SHOULD always use online verification and that a service caching revocation state MUST NOT cache it longer than 5 minutes. Enforcement is only as real as whichever receiving service actually performs that check. At least one of Grantex's own shipped packages, addressed below, verifies a token's signature and claims without performing that check at all.
  • Verified in artifacts
    Version 1.0 is Final and frozen inside the Grantex project, not an industry or IETF standard. Fetched directly this session from SPEC.md in the mishrasanjeev/grantex repository. The document's own header states Version 1.0, Status Final, Last Updated February 2026, revision 3, and states plainly: Specification is now frozen. Changes require a new version. Nothing in the document claims IETF, W3C or any other standards body recognition, and no working group is named. Separately, this session found search results describing the project's own site as calling itself standards track. The one IETF artifact independently corroborated for this project, draft-mishra-oauth-agent-grants, carries intended status Informational, which is a distinct IETF category from Standards Track. This record does not repeat the standards track characterization: Final means frozen within this one project's own versioning, and Informational, corroborated but not independently read, is not Standards Track.
  • Documented design
    The IETF draft and the Grantex specification describe the same architecture, from the same author, not two independent proposals. The Grantex repository's own changelog dates the initial version 1.0 specification and auth service launch to 25 February 2026, and SPEC.md's own header separately states the specification reached Final, frozen status at revision 3 with a last updated line reading only February 2026, with no more precise day found by this session. Search corroborated results place draft-mishra-oauth-agent-grants-00 two days after that initial launch, on 27 February 2026, and revision 01 five days after that, on 2 March 2026, both authored by S. Kumar of Grantex, the same person who maintains the mishrasanjeev/grantex repository under the GitHub handle mishrasanjeev. This record treats the frozen specification and the Internet Draft as one underlying protocol design documented in two places, not as two independent market signals, and grades this single record accordingly rather than counting each artifact separately.
  • Verified in artifacts
    Current package versions were confirmed directly against npm, PyPI and the Go module proxy, not taken from the vendor's own claim. Fetched directly this session from each registry's own API. npm: @grantex/cli 0.3.0 published 10 August 2026, @grantex/mcp 0.1.10 published 25 June 2026, @grantex/mcp-auth 2.0.2 published 25 June 2026, @grantex/sdk 0.3.13 published 11 July 2026. PyPI: grantex 0.3.14 uploaded 11 July 2026. The Go module proxy's own @latest endpoint for github.com/mishrasanjeev/grantex-go returned Version v0.1.10, Time 2026-07-11T01:54:18Z. These are the registries' own records, independently checked, not Grantex's description of its own release status.
  • Verified in artifacts
    A delegated grant token carries parentAgt, parentGrnt and delegationDepth fields. Fetched directly this session from SPEC.md, section 9. Quoted directly: when Agent A spawns Agent B, B's Grant Token must chain back to the original Principal's authorization, carried through a parentAgt field naming the parent agent, a parentGrnt field naming the parent grant, and a delegationDepth field. The specification requires delegationDepth to be incremented by exactly 1 at each hop, with the root grant at depth 0.
  • Verified in artifacts
    Child scopes MUST be a subset of the parent's scopes, and a child may hold exactly the parent's scopes. Fetched directly this session from SPEC.md, section 9, quoted verbatim: sub agent scopes MUST be a subset of the parent's scopes. A subset relation permits equality: nothing in this sentence, or elsewhere in the fetched text, requires the child's scope set to be smaller than the parent's, only that it not contain a scope the parent lacks. Section 9.1 confirms the enforcement point operationally: the delegation endpoint rejects with a 400 status if any requested scope is not present in the parent token's scp claim, a subset check, not a strict subset check. Separately, this session's search results describing the IETF draft in aggregate used the phrase strict subset. This record follows the specification's own verbatim text and the enforcement rule actually read from it, subset, over that secondary paraphrase, consistent with the instruction that a subset relation should not be written as a strict subset unless the source itself requires shrinkage.
  • Verified in artifacts
    A child token's expiry is computed as the earlier of the parent's expiry and the requested duration. Fetched directly this session from SPEC.md, section 9.1, quoted verbatim: compute expiry as min(parent token exp, now + expiresIn). A delegated grant can request a shorter lifetime than its parent's remaining validity, but cannot request one that outlasts it. No additional temporal semantics, such as a minimum grant lifetime or a separate clock skew allowance, were found in the fetched text.
  • Verified in artifacts
    Delegation depth carries a developer configurable default of 3 hops and a hard, non configurable cap of 10. Fetched directly this session from SPEC.md, section 9, quoted verbatim: implementations MUST enforce a developer configurable delegation depth limit. The default RECOMMENDED limit is 3. Implementations MUST enforce a hard cap of 10. The 3 hop figure is a recommended default an operator can change; the 10 hop figure is stated as a MUST level ceiling the specification does not describe as configurable. This record keeps that distinction rather than presenting both as the same kind of limit.
  • Verified in artifacts
    Revoking a root grant atomically marks every descendant grant revoked in one transaction, traced through parent_grant_id. Fetched directly this session from SPEC.md, section 9.2, quoted verbatim: revoking a Grant via DELETE /v1/grants/:id MUST atomically revoke all descendant grants, grants whose parent_grant_id traces back to the revoked grant, at any depth, and implementations SHOULD use a recursive CTE or equivalent to traverse the delegation tree in a single database transaction. This is atomic marking of every descendant record at the moment of revocation, not an ancestry lookup a verifier performs at each check and not a separately maintained revocation tree data structure. No detail beyond this mechanism was found in the fetched text, and this record does not infer one.
  • Verified in artifacts
    Default verification is offline against published signing keys, which does not by itself reflect revocation that happened after the token was issued. Fetched directly this session. The specification states tokens are RS256 signed with a published JWKS, and this session's repository summary independently corroborated that services verify locally without calling Grantex during normal operation, consistent with an offline signature and claims check. The specification itself, section 7.4, quoted verbatim, states high stakes scopes, its own examples are payments:initiate, email:send and files:write, SHOULD always use online verification, and that revocation caching MUST NOT exceed 5 minutes. SHOULD is not MUST: an integration that skips online verification for a scope the specification would call high stakes can accept a signed token whose grant was already revoked, until that token's own natural expiry. This record does not describe cascade revocation as immediately and universally effective; it is only as fast as the verification path an integration actually chooses.
  • Verified in artifacts
    The current @grantex/mcp-auth package explicitly documents that it does not check revocation state. Fetched directly this session from the package's own README and from COMPATIBILITY.md in the same repository, version 2.0.2, the version independently confirmed current against the npm registry above. Quoted directly: middleware and introspection verify signatures and claims but do not perform a live revocation lookup, and this middleware does not check current revocation state in 2.0.2. COMPATIBILITY.md separately states local introspection and middleware do not check revocation and that the Grantex authorization code is not persisted for token exchange, and instructs integrators to treat this release as single process evaluation software until a corrected package is published. This is the clearest documented gap between the specification's cascade revocation design and one of Grantex's own shipped integrations: a token whose grant has been revoked can still read as valid to this package until the token's own expiry.
  • Documented design
    The specification describes an append only, hash chained audit log, without an independently found external anchor. Fetched directly this session from SPEC.md, section 14, quoted verbatim: audit logs MUST be append only at the API level, no update or delete endpoints, and each entry's hash incorporates a prevHash field, which the fetched material describes as making retrospective tampering detectable. That is a real property: a party without direct database access cannot alter an entry without breaking the chain from that point forward through anything that reads it. This session found no description of the chain being anchored to an external, independently controlled system, a public ledger, a third party notarization service or similar, so an operator with direct database access could in principle rewrite the full chain without an outside party detecting it from the chain alone. This record uses append only and hash chained, the specification's own terms, and does not use immutable or tamper proof, which the fetched specification text does not itself claim.
  • Documented design
    Budget Allocation is not part of the frozen version 1.0 specification, and appears only in the reference implementation and later material. SPEC.md, fetched and searched directly this session for the word budget, contains no normative budget or spending limit language anywhere in the frozen version 1.0 text. Budget controls do appear elsewhere: this session's search results describe budget features named in the DAAP Internet Draft material and this session directly confirmed a budgets command surface in the CLI package description and a Budget feature column in a conformance table search results attribute to the project's own documentation. Budget Allocation therefore reads as a reference implementation and later draft feature, layered on top of the frozen core protocol, not a requirement the version 1.0 specification itself imposes.
  • Documented design
    The most recent test count this session could independently verify is 3,536 tests across 28 packages, dated 8 April 2026, not the approximately 362 figure from an earlier implementation report. Fetched directly this session from CHANGELOG.md in the mishrasanjeev/grantex repository. The version 0.3.8 entry, dated 2026-04-08, states verbatim: updated test stats, 3,536 tests across 28 packages, was 3,332 slash 27. This is a later and larger figure than the roughly 362 test count reported around the DAAP draft's own implementation report from March 2026, and this record uses the later figure rather than the draft's, consistent with the project having continued to add tests since. No changelog entry dated after 8 April 2026 and visible to this session restates a new total, so 3,536 across 28 packages, dated 8 April 2026, is recorded as the most recent figure this session could verify, not as a current, as of August 2026, count.
  • Verified in artifacts
    The specification defines the Principal narrowly, as the human user who authorizes an Agent, not an organization. Fetched directly this session from SPEC.md. The specification's own definitions state an Agent is an AI powered software process that takes autonomous actions on behalf of a Principal, and a Principal is the human user who authorizes an Agent to act on their behalf. The signed grant token identifies this human Principal, not the organization operating the agent. Enterprise features this session found described, SSO through OIDC, SAML and an LDAP direct bind preview, authenticate which human is signing in; they are not themselves a different, organization level Principal type the specification defines, and this record does not treat successful SSO as evidence of a broader organizational grantor.
  • Unknown
    Nothing found by this session establishes that a Principal held legitimate organizational, contractual or account authority to grant the scope a token describes. The specification, the README, the compliance material and the SDK documentation available to this session establish who a signed grant identifies as Principal, a human user, and what scope that Principal granted. None of it establishes that the identified Principal actually held a corporate office, an account ownership right, a contractual authority, a power of attorney or another organizational mandate entitling them to grant that scope, whether for themselves or for an organization the agent is meant to act for. Grantex's SSO, DPDP consent record and EU AI Act control mapping features authenticate identity and record consent; none of that is a mechanism this session found for representing or checking upstream authorization to delegate. Recorded as unknown rather than assumed present, matching how this dataset already treats the same gap for x401.
  • Documented design
    A Grantex grant constrains only the operation a receiving service actually checks it against, not any credential an agent holds outside that path. The specification and the reference implementation describe delegated scopes, expiry and depth for tokens issued and checked through Grantex's own flow. Nothing found by this session describes Grantex constraining, discovering or revoking an ambient credential, an API key, a standing service account or another authorization surface an agent might hold and use independently of the Grantex grant path. A service that does not verify a Grantex token before acting is not constrained by anything this record found Grantex to enforce. This record does not read Grantex as bounding everything an agent can do, only what a service chooses to gate behind it.
  • Unknown
    No mechanism beyond revocation itself was found for a Principal, administrator or third party to formally challenge a grant's legitimacy. The specification describes revoking a grant and the cascade that follows. It does not describe, and this session did not find elsewhere, a distinct dispute, challenge or contest mechanism separate from the binary act of revoking, for example a flagged or contested state a grant could enter while its legitimacy is examined without immediately cutting off the agent. Token verification itself is not a challenge mechanism; it is the ordinary check a receiving service performs on every request. Recorded as unknown.
  • Unknown
    Cascade revocation stops future use of descendant grants; nothing found addresses reversing an action a now revoked grant already authorized. Section 9.2's cascade revocation mechanism, verified above, prevents a revoked grant or its descendants from passing verification going forward. Nothing in the fetched specification text, the README, the compliance material or the CLI's audit and compliance command surface describes a rollback, compensation or reversal mechanism for an action a grant already authorized before it was revoked. A payments:initiate scope that already executed a payment is not described as reversible by anything this session found. Recorded as unknown, matching how this dataset already treats the same gap for x401.
  • Documented design
    Public attention is modest, and no named third party production deployment independent of the vendor was found. The mishrasanjeev/grantex repository, fetched directly this session, shows 31 stars and 7 forks. The 29 framework integrations this session found described, LangChain, AutoGen, CrewAI, the OpenAI Agents SDK, Google's ADK and others, are packages published from within the same repository by the same author, not independent third party attestations of use. Search results describe an external security review with no critical or high severity findings, with the full report available to enterprise customers under NDA, which this session could not itself inspect, and describe no formal third party attestation as published. No named company, product or working group independent of Sanjeev Kumar and Grantex was found by this session actually running Grantex or DAAP in production. This record treats that as the current state of adoption evidence, not as an indictment: a young, single author protocol with a genuine specification, a real reference implementation and evolving tests, short on independent validation so far.
Sources (13)

Cross App Access (XAA) and MCP Enterprise-Managed Authorization

Okta · Implementation · Mixed license
Updated 24 August 2026

Okta describes Cross App Access as generally available since it was introduced on 23 June 2025 as an OAuth and OIDC based app to app flow.

Evidence at a glance
  • Verified in artifacts5
  • Documented design8
  • Unknown4
Runtime enforcement: Documented designDelegated authority: No evidenceHuman approval: UnknownRevocation & expiry: UnknownAudit & attestation: No evidenceBypass resistance: No evidence
Moona Intelligence reading

XAA moves one decision, whether an app may reach a resource on a signed in user's behalf, into policy an administrator sets once at the identity provider. Its pieces span different maturity, from a stable MCP extension to Claude's integration still in beta, so none of it is generally available.

View evidence (17 properties, 8 sources)
Vendor
Okta
Artifact
Implementation
License
Mixed
Announced
23 June 2025
Maturity
Okta describes Cross App Access as generally available since it was introduced on 23 June 2025 as an OAuth and OIDC based app to app flow. Okta named more than 25 early adopters in an expanded ecosystem on 23 June 2026. Auth0 describes support for building a Resource Application as Open Early Access since 6 August 2026. Auth0's own guidance frames a further Okta Integration Network catalog milestone naming ten of those partners as expected to begin on 24 August 2026, the date this record was verified, and this record does not treat that expectation as a confirmed general availability event. The underlying ID JAG grant is an adopted IETF OAuth Working Group Internet Draft, not an RFC. The Model Context Protocol's own Enterprise Managed Authorization extension has been marked stable since 18 June 2026. Claude's own integration remains a beta limited to approved joint Okta and Anthropic customers as of the verification date.
Enforcement point
Split across two points rather than one. The enterprise identity provider evaluates and grants or denies the cross app connection itself, issuing a signed ID JAG only when an administrator configured policy already permits the requesting application to reach that resource application for that user. The resource application's own authorization server then separately validates that assertion and mints its own scoped access token. Nothing reviewed for this record documents either point evaluating the specific action an agent later attempts with the resulting token.
  • Documented design
    Okta announced Cross App Access as an OAuth based protocol on 23 June 2025. Okta's developer blog post dated 23 June 2025 could not be fetched directly in this session, blocked by the tooling environment's network egress proxy. The date and the core mechanism, a requesting application exchanging a signed identity assertion with the enterprise identity provider instead of prompting the signed in user to connect to each resource application separately, are corroborated across repeated, independently phrased search passes and by Help Net Security's own contemporaneous coverage, independently dated 23 June 2025.
  • Verified in artifacts
    The protocol exchanges an ID token for an ID JAG, then the ID JAG for a scoped access token. Fetched directly from Auth0's own public sample repository, auth0-samples/auth0-cross-app-access-inspector, on GitHub. Its documentation states the flow exchanges an ID token for an Identity Assertion JWT, the ID JAG, at the enterprise identity provider's authorization server using RFC 8693 token exchange, then exchanges that ID JAG for an access token at the resource application's own authorization server using a JWT bearer grant, with the resource application's registered API identifier carried as the audience.
  • Verified in artifacts
    Enterprise Managed Authorization governs the cross app connection, not the individual action an agent later attempts. Fetched directly from the Model Context Protocol's own blog, blog.modelcontextprotocol.io. Its 18 June 2026 post states the extension makes the organization's identity provider the authoritative decision maker for MCP server access and describes it as governing connection setup, not per operation decisions. Nothing in that post describes the extension evaluating a specific tool call or action once a connection is already authorized.
  • Verified in artifacts
    XAA and the ID JAG grant are one compatible mechanism for Enterprise Managed Authorization, not a required one. The same Model Context Protocol blog post presents Okta's Cross App Access and the ID JAG grant as how the extension works with one specific identity provider, alongside other named early adopters, rather than naming XAA as the only mechanism the extension permits.
  • Verified in artifacts
    Enterprise Managed Authorization is a separate MCP extension marked stable, not part of the ratified core specification. The Model Context Protocol blog post, dated 18 June 2026 and authored by Paul Carleton, a core maintainer, states the Enterprise Managed Authorization extension is now stable and points to a dedicated ext auth repository, distinct from the core specification.
  • Documented design
    The ID JAG grant is an adopted IETF OAuth Working Group Internet Draft, not an RFC. Direct fetch of the IETF Datatracker was blocked by this session's network egress proxy. Search indexed content of the tracker page identifies draft ietf oauth identity assertion authz grant as a working group document of the OAuth Working Group, authored by Aaron Parecki, Karl McGuinness and Brian Campbell, succeeding an earlier individual submission, draft parecki oauth identity assertion authz grant, with intended RFC status still unset. This record does not describe the grant as a ratified standard.
  • Documented design
    Okta named more than 25 early adopters in an expanded XAA ecosystem on 23 June 2026. Direct fetch of Okta's newsroom was blocked by this session's network egress proxy. The announcement's title, date and partner list, including Anthropic, Asana, Atlassian, Canva, Cloudflare, Cursor, Datadog, Docker, Figma, Glean, Granola, Linear, Slack, Supabase, VS Code and Zoom, are corroborated across repeated, independently phrased search passes returning consistent detail.
  • Documented design
    Okta categorizes named partners as requesting applications, resource applications or infrastructure providers. Search indexed summaries of Okta's own 23 June 2026 announcement describe three categories: requesting applications that ask on a user's behalf, including Claude, Cursor, Docker, VS Code and Zoom; resource applications that hold the data reached, including Asana, Atlassian, Canva, Datadog, Figma, Glean, Granola, Linear, Slack, Supabase and Zoom; and identity infrastructure or gateway providers. This record could not confirm the exact original wording of that categorization against the raw release, blocked by this session's egress proxy, so it treats the category assignment as documented rather than verified, and notes Zoom is described in both of the first two categories.
  • Documented design
    Auth0 describes XAA support for Resource Applications as Open Early Access since 6 August 2026. Direct fetch of auth0.com was blocked by this session's network egress proxy for every attempt made. Search indexed summaries of Auth0's own documentation describe Cross App Access for Resource Applications as in Open Early Access, usable in production at no additional cost through Auth0 Enterprise Connections, for Enterprise, B2B Pro and B2B Essential customers. This record records Auth0's own maturity label rather than treating it as either a beta or a general availability claim.
  • Documented design
    Auth0 frames the 24 August 2026 Okta Integration Network milestone as expected, not confirmed. Across repeated, independently phrased search passes, the recurring verb describing the milestone naming Anthropic, Asana, Canva, Cloudflare, Cursor, Datadog, Docker, Figma, VS Code and Zoom was expected, never a firm availability claim. Direct fetch of the Auth0 article that states this was blocked by this session's egress proxy, so the exact verbatim sentence is not independently confirmed, only its consistently hedged sense across sources.
  • Unknown
    Current Okta Integration Network catalog entries for Claude and Slack were independently confirmed as of 24 August 2026. Direct fetch of oin.okta.com and the individual Claude and Slack integration pages was blocked by this session's egress proxy on every attempt. Search indexed snippets of unconfirmed freshness describe a Slack listing carrying Cross App Access and Brokered Consent capability tags and a Claude listing carrying AI agent management capability alongside a beta Cross App Access program, but this record could not verify that either listing, as it actually reads today, matches those snippets rather than an older cached version. This record does not treat the scheduled 24 August milestone as confirmed live on the strength of that indirect material alone.
  • Documented design
    Claude's Enterprise Managed Auth integration remains a beta for approved participants. Direct fetch of claude.com, docs.claude.com and support.okta.com was blocked by this session's egress proxy. An Okta support article titled Claude Enterprise Managed Auth With Okta Cross App Access XAA Beta Participation Guide is independently corroborated by its title alone across separate search passes. Search indexed summaries of Anthropic's own 18 June 2026 blog post state the capability is in beta for Claude Team and Enterprise plan customers, with Ramp, Webflow and HubSpot named as joint customers and seven MCP resource providers supported at launch: Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase. This record does not promote that beta to general availability.
  • Verified in artifacts
    The represented employee supplies identity and context while the administrator decides whether a requesting application may reach a resource application for that user. The Model Context Protocol blog post states the mechanism removes repeated per app consent prompts because an administrator enables a server for the organization once, scoped to the groups and roles a user already holds, and access is granted automatically the first time that user signs in. The user's own identity and existing group membership still govern what is reachable. The decision that the requesting application may reach that resource application at all is the administrator's, made once, upstream of any individual user's session.
  • Documented design
    Disabling a user or an agent's access through the identity provider is documented as blocking renewal, triggered by offboarding. Search indexed summaries describe centralized revocation through Okta when a user or a deployed agent is offboarded, and Auth0's general refresh token documentation, not XAA specific, describes revoking a refresh token as removing the ability to obtain a new access token afterward. This record treats offboarding driven revocation of the renewal path as documented and does not extend that to a specific claim about XAA's own revocation mechanism beyond what is stated.
  • Unknown
    Already issued access tokens are invalidated immediately upon revocation rather than left valid until their own expiry. No source reviewed for this record states whether an access token already issued under XAA is invalidated the instant an administrator revokes the underlying grant, or whether it simply cannot be renewed and remains valid until its own short expiry. General Auth0 refresh token documentation describes the latter pattern, access continues until the access token's own expiration once only the refresh token is revoked, but this record does not extend that general OAuth behavior to XAA's own token lifetime as a confirmed claim.
  • Unknown
    XAA is documented as bounded by the user's existing permissions in the resource application, unable to grant access the user does not already have. The reviewed material states that an administrator configured XAA policy gates whether a requesting application may reach a resource application for a user at all, and that the resource application's own authorization server independently issues the final access token. Neither of those statements, read directly, confirms or denies whether that final token can carry access to an object, such as a specific Slack channel, Asana project or Supabase resource, the user does not already hold in that resource application's own permission model. This record leaves the question open rather than assuming either direction.
  • Unknown
    A governance or resource owner approval requirement, beyond generic Okta administrator access, is documented for configuring an XAA policy. Nothing reviewed for this record, across Okta's, Auth0's or Anthropic's own material, describes a specific administrative role, delegated administration boundary, resource owner sign off or entitlement management workflow that must be satisfied before an Okta administrator may configure an XAA policy connecting a requesting application to a resource application. Technical capability to configure the policy is documented. A separate organizational entitlement to do so is not.
Sources (8)

About the methodology

Read what this evidence adds up to →

Every architecture on this page is assessed the same way, and nothing here is scored. Each property carries one of five grades, defined once and applied consistently.

01

Collect

Read the specification, source code, documentation and launch material an architecture publishes.

02

Assess

Map each claim to a graded property: what is stated, and what the artifact would need to show to support it.

03

Grade

Assign one of five grades: Verified in artifacts, Documented design, Vendor claim only, Not supported, or Unknown.

04

Review

Record when the artifacts were verified, separate from when a vendor announced them, and revisit as new evidence appears.