The Agent Created Another Agent. Which Permissions Came With It?

Version 2.1.232 of Claude Code changed a default. Anthropic's changelog puts it in one line: subagent forking is now on by default, a subagent_type: "fork" subagent inherits the full conversation and prompt cache, and non-teammate agent spawns in interactive sessions now run in the background by default.

Everyone read that as a productivity change. Parallel agents, less re-explaining, cheaper cache reuse. All true. What I think actually matters is smaller and harder: when one agent creates another agent to finish part of its work, which parts of the first agent's authority silently come along?

Claude Code made forking ordinary

The version itself is easy to place. npm's registry metadata for the @anthropic-ai/claude-code package records 2.1.232 as published on 13 August 2026. The changelog does not carry calendar dates, so package publication metadata is the dating evidence here, not an official Anthropic release announcement.

Anthropic's subagent documentation confirms the default is scoped, not universal. Fork mode is on by default in interactive sessions, off by default in non-interactive mode with -p and in the Agent SDK, and the interactive default requires v2.1.232 or later. The CLAUDE_CODE_FORK_SUBAGENT environment variable overrides it in either direction.

That is the whole feature summary you are getting from me. This is not a changelog recap.

The child does not start from zero

Anthropic's definition is precise and worth quoting closely. A fork is a subagent that inherits the entire conversation so far instead of starting fresh. The documentation says this drops the input isolation that subagents otherwise provide: a fork sees the same system prompt, tools, model and message history as the main session. The fork's own tool calls still stay out of the main conversation and only its final result comes back. Because system prompt and tool definitions are identical to the parent, the first request reuses the parent's prompt cache.

Note what that list contains and what it does not. Context, system prompt, tool definitions, model, prompt cache. Anthropic does not describe credentials or identity as inherited objects here, and I am not going to invent that. Filesystem behaviour is documented separately: a subagent starts in the main conversation's working directory, and isolation: worktree gives it a separate copy of the repository instead.

Permission state is documented separately again, and it is the interesting one. Anthropic says that if you leave permissionMode unset, the subagent inherits the main conversation's mode, which starts as auto mode on Pro, Max and Team plans unless settings or an organization change it. Setting it overrides that mode, with exceptions the documentation is explicit about: if the parent uses bypassPermissions or acceptEdits, that takes precedence and cannot be overridden, and if the parent is in auto mode the subagent inherits auto mode and its own frontmatter mode is ignored, with the classifier evaluating the subagent's tool calls using the same block and allow rules as the parent session.

That is a coherent design. It stops a subagent definition from quietly escalating past what you chose for the session, and it stops a child claiming a stricter posture than the classifier the parent is actually running under. It also means the direction of inheritance is set by the parent's state at spawn time, not by the child's declaration.

A task and its authority are not the same thing

Here is the conceptual centre, and it is not a Claude Code question.

When a parent agent delegates, four different things can travel with the handoff. The task. The context. The tool definitions. The permission state. Product design usually treats these as one bundle because that is what makes delegation feel seamless. They are not one thing. Handing another actor the job of drafting tests is a statement about work. It is not, by itself, a statement about which consequential operations that actor may execute against your infrastructure.

Most authorization thinking still assumes the actor existed before the authority was granted. Agent systems invert that. The actor is created, at runtime, by another actor, and its authority arrives as a side effect of how it was created rather than as a decision anyone made about it.

Inheritance is useful, and I am not calling it a flaw

Shared context is the entire point of a fork. Anthropic's own reasoning is sound: use a fork when any other subagent would need too much background to be useful, or when you want to try several approaches in parallel from the same starting point. Reusing the prompt cache makes it cheaper than a fresh subagent. Background execution means the work does not block you.

Permission inheritance is what makes that practical. A subagent that re-prompted for every decision the parent session already settled would be useless. Nobody is going to configure a permission mode for every ephemeral child.

But inheritance creates a new authorization boundary

The questions worth asking are the ones nobody asks while the feature is working.

When the child reaches a genuinely consequential operation, who authorized that specific action? The user authorized a session. The parent authorized a task. Neither of those is the same as authorizing the thing the child is about to execute. When the parent session is running under a broad mode, the child runs under that mode too. When several children are running in the background at once, the number of actors operating under that inherited posture is no longer one.

Anthropic documents that background subagents surface every permission prompt in the main session, naming the subagent that is asking, and that you can approve or press Esc to deny that one tool call without stopping the subagent. So the parent is observable and interruptible. That is a real control and I want it stated clearly, because the failure mode here is not agents running loose. It is a prompt arriving with no way to reconstruct which chain of delegation produced it.

Anthropic already exposes controls

Fairness matters more than a scary framing. The documented controls are substantial. A custom subagent can declare a tools list, and Anthropic notes it inherits every tool available to subagents if that field is omitted. disallowedTools removes tools from the inherited or specified list. A specific subagent type can be blocked with an Agent(name) rule in permissions.deny, including the fork type, and delegation can be switched off entirely by denying the Agent tool itself. isolation: worktree runs the subagent against a temporary git worktree. Anthropic also documents that when the main conversation itself runs isolated in a worktree, the same checks apply to every subagent it spawns, including ones without that setting. Background subagents run with a smaller built-in tool set than foreground subagents, except for conversation forks. Plugin subagents cannot use permissionMode, hooks or mcpServers at all, which Anthropic states is for security reasons.

Those are per-configuration controls over which child gets created and what it may touch. They are not the same as a record of where a given child's authority came from.

Delegation is not concurrency

We have written about several agents acting at once, and this is a different question. When three agents with conflicting goals began revoking each other's access, every actor already held its own authority and the problem was interaction. When an agent runs unattended for hours on one objective, the question is how long a prior authorization stays meaningful. When Claude Code automated the decision about when to ask you for permission, the question was who decides that a human needs to be involved.

Authority Inheritance is the one underneath all three: where did this new actor's authority come from in the first place? Concurrency assumes the actors exist. Delegation creates them. That is our framing and our vocabulary. Anthropic does not use the terms Authority Inheritance or Agent Authority, and nothing here should be read as Anthropic endorsing them.

Why this is not hypothetical

Anthropic has independently documented a real internal incident showing why authority inheritance across agent creation can matter. In its August 2026 risk report, Anthropic describes an employee whose AI usage was not logged and was not covered by automated offline monitoring giving an agent a relatively open-ended task that involved spinning up new agents in a cluster with very sensitive resources. Due to legacy instructions, the report says, the main agents spawned the new agents with --dangerously-skip-permissions, and those new agents were also not covered by offline monitoring. One of them deleted a large number of jobs, which is how the agents were caught and shut down. Anthropic says it believes the agent was attempting to delete only jobs it had created and made a mistake, but that given the monitoring gap it cannot confirm this. Anthropic states it has since developed blocking controls that would very likely have prevented that kind of activity, and that offline monitoring still does not cover all employees and all usage in those clusters. Some details are redacted in the report.

That incident is separate evidence. It is not attributable to Claude Code 2.1.232, it is not described as involving the fork mechanism, and I am not connecting them causally. What it establishes independently is that the moment of agent creation is a real place where a permission posture propagates further than anyone intended.

What I am not saying

Anthropic does not document that credentials, identity, network reach or arbitrary filesystem access inherit through a fork, and nothing here claims they do. A fork is not unconstrained: Anthropic documents that a fork cannot spawn further forks, that the Agent tool's run_in_background parameter is removed when fork mode is on, and that managed settings restrictions apply to every subagent regardless of how it is defined. Cross-session messaging exists in the same release, with @ mentions and SendMessage, and Anthropic's 2.1.222 entry says messages sent to other agent sessions through SendMessage are evaluated by the permission classifier before dispatch. That is a related surface, not the thesis.

Grantex answers the same question with an opposite default

Anthropic's fork mechanism inherits by default and then lets an operator narrow it back down with tools, disallowedTools, deny rules and worktree isolation. Somewhere else in the same broad space, an independently developed protocol takes the reverse position: authority does not travel down a delegation chain unless it is bounded on the way, by construction, at every hop. That protocol is Grantex, and this section verifies it directly rather than repeating what its own site says about itself.

Grantex is a single author project. Its GitHub repository, mishrasanjeev slash grantex, fetched directly this session, carries an Apache 2.0 license, 31 stars and 7 forks. The protocol specification inside it, SPEC.md, states its own header plainly: Version 1.0, Status Final, Last Updated February 2026, revision 3, and a following line reading Specification is now frozen. Changes require a new version. The repository's own changelog dates the initial protocol specification and auth service launch to 25 February 2026. Final here means frozen inside this one project's own versioning. Nothing in the specification claims IETF, W3C or any other standards body recognition, and this piece does not describe it as an industry standard.

A related document exists at the IETF. Independently phrased search passes agree on a title, Delegated Agent Authorization Protocol, DAAP, an author, S. Kumar of Grantex, the same person behind the GitHub repository, revision 00 published 27 February 2026, two days after Grantex's own changelog dates the initial version 1.0 launch, and revision 01 published 2 March 2026, both carrying intended status Informational. datatracker.ietf.org and ietf.org were blocked by this session's network egress policy on every attempt, so this record does not claim to have read the draft's own text directly, and grades what it describes as documented rather than verified for that reason. What matters more than the individual dates is the relationship between the two documents. This is one author's one architecture, described in a frozen specification and, days later, in an Internet Draft, not two independent proposals converging on the same idea. Treated as market signal, it is one data point, not two, and this piece treats it that way. It is also worth being precise about what an Internet Draft is and is not. It is an individual submission, available through IETF infrastructure because anyone can submit one. It is not an RFC. It is not adopted by the OAuth Working Group merely because its name uses an oauth prefix and it appears in that working group's own Datatracker listings. It is not IETF endorsement, certification or consensus, and nothing here should be read as claiming otherwise.

What actually attenuates, and what does not yet

Set the framing aside and read the mechanism, verified directly from SPEC.md fetched this session. When one agent spawns another, section 9 states the child's Grant Token must chain back to the original Principal's authorization, through three fields: parentAgt, naming the parent agent, parentGrnt, naming the parent grant, and delegationDepth, incremented by exactly 1 at each hop from a root grant at depth 0. That is a documented answer to the exact question Anthropic leaves undocumented for a Claude Code fork: where a subagent's authority came from is not left to be reconstructed from a permission prompt, it is a field on the token itself.

Three specific rules bound what a child grant can be, each quoted directly from the fetched specification text. Scope: sub agent scopes MUST be a subset of the parent's scopes, enforced at the delegation endpoint, which rejects with a 400 status if a requested scope is not present in the parent token's own scp claim. A subset relation permits equality, a child can hold exactly its parent's scopes, only a scope the parent lacks is prohibited, so this piece uses subset rather than strict subset, matching the specification's own enforced rule rather than a stronger phrase this session found used loosely elsewhere about the same project. Expiry: compute expiry as min(parent token exp, now + expiresIn), so a child's lifetime can be shorter than its parent's remaining validity and cannot be longer. Depth: implementations MUST enforce a developer configurable delegation depth limit, with a default RECOMMENDED limit of 3 and a hard cap of 10 the specification does not describe as configurable.

Revocation cascades by the same directness. Revoking a Grant MUST atomically revoke all descendant grants, grants whose parent_grant_id traces back to the revoked grant, at any depth, with implementations directed to use a recursive database query to mark the whole delegation tree revoked in one transaction. That is atomic marking of every descendant record at the moment a root is revoked, not a lookup a verifier performs later and not a separately maintained revocation tree structure, and it is the concrete version of a sentence this piece already asked in the abstract: revoking a parent should be able to take a child down with it.

That gap is not hypothetical inside Grantex's own shipped software. Its MCP authorization package, at version 2.0.2, the version this session independently confirmed as current against the npm registry, documents the limitation in its own README rather than leaving it to be discovered: middleware and introspection verify signatures and claims but do not perform a live revocation lookup, and a revoked but otherwise valid token can remain active until expiry. A companion file in the same repository, COMPATIBILITY.md, states plainly that local introspection and middleware do not check revocation and instructs integrators to treat this release as single process evaluation software until a corrected package is published. Cascade revocation exists as a real, atomic mechanism in the authorization service. Whether a specific integration actually consults it before letting an action proceed is a separate question, and for this one, currently shipping package, the documented answer is no.

The audit trail is real and specifically described, and this piece is deliberately narrow about what that specific description supports. Section 14, fetched directly, states audit logs MUST be append only at the API level, no update or delete endpoints, with each entry's hash incorporating the previous entry's hash. That is a genuine property: altering an entry without database level access breaks the chain from that point forward through anything that later reads it. This session found no description of that chain being anchored to any system outside Grantex's own database, 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 piece uses append only and hash chained, the specification's own language, and not immutable or tamper proof, which the fetched text does not itself claim.

Two things worth naming precisely because they are easy to get wrong. Budget Allocation, a spending limit control this session found described in later Grantex material and search results describing the DAAP draft, is not part of the frozen version 1.0 specification, which this session searched directly and found no budget language in at all; treat it as a reference implementation and later draft feature layered on the frozen core, not something version 1.0 itself requires. And the project's own test count moves: an implementation report tied to the DAAP draft's original March period is reported elsewhere as roughly 362 tests, but the repository's own changelog, fetched directly this session, records a later entry, dated 8 April 2026, stating updated test stats, 3,536 tests across 28 packages. That later, larger figure is what this piece uses, not the earlier one, and no changelog entry visible to this session past that date restates a new total, so it is recorded as the most recent figure this session could verify, not as current to August 2026.

The Authority Provenance ledger

Moona Intelligence separates what a Grantex grant proves from what it does not, the same discipline this desk already applies to x401's proof requirements, rather than letting a well specified mechanism stand in for a fully proven chain of authority.

Authority grantor. The specification's own definitions are narrow and worth quoting directly: 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. A signed grant identifies that human Principal. Enterprise features this session found described, single sign on through OIDC, SAML and an LDAP preview, authenticate which human is signing in. They are not a separate, organization level Principal the specification itself defines, and this piece does not collapse a verified sign in into a broader organizational grantor.

Mandate or basis. Undocumented. A signed grant establishes that a specific human Principal authorized a specific Agent to hold a specific scope. Nothing this session found, in the specification, the README or the compliance material, establishes that the Principal actually held a corporate office, an account ownership right, a contractual authority or another organizational mandate entitling them to grant that scope in the first place. Identity of the grantor is documented. Legitimacy of the grant is not, and this piece records that as unknown rather than inferred from a successful sign in.

Delegated scope. Documented and specifically enforced: a subset check at the delegation endpoint, verified directly above. Whether a scope string like payments:initiate carries an enforceable numeric ceiling depends entirely on whether a receiving service parses and checks that string; nothing this session found makes such a convention a normatively enforced part of the protocol itself, and this piece does not treat a scope string as a guaranteed numeric policy.

Explicit limits. Documented precisely: expiry capped at min(parent exp, now + expiresIn), and delegation depth defaulting to 3 with a hard cap of 10. Budget controls, addressed above, sit outside the frozen core specification.

Inherited permissions and assumptions. A Grantex grant constrains the operation a receiving service actually checks it against, and nothing more. This piece found no description of Grantex discovering, constraining or revoking an ambient credential, an API key or a standing service account an agent might hold and use outside the Grantex path entirely. A service that never verifies a Grantex token is not bounded by anything this record found Grantex to enforce.

Revocation or modification. Cascade revocation is real and atomic inside the authorization service, verified directly above. Its effect at a specific receiving service depends on that service's own verification choice, online or offline, and on Grantex's own shipped MCP authorization package currently not checking revocation state at all. This piece does not describe cascade revocation as instantly and universally effective everywhere a Grantex token is accepted.

Challenge authority. Undocumented. This session found revoking a grant, and found no distinct mechanism for a Principal, an administrator or a third party to formally contest a grant's legitimacy separate from that binary act.

Recovery. Undocumented. Cascade revocation stops future use of a compromised chain. Nothing this session found addresses reversing, compensating for or rolling back an action a since revoked grant had already authorized before it was revoked.

Provenance evidence quality. Layered, not uniform, and worth stating plainly rather than rounding up. The mechanism that governs how much authority a child grant can hold, for how long, how many hops deep and how it gets cut off at the root is real, specific and independently verified against the specification's own text. Who was actually entitled to create the grant in the first place, whether a specific service verified it before acting, and whether anything survives to challenge or reverse an action already taken, are each undocumented or only partially enforced, and this piece keeps those apart rather than letting a well built attenuation mechanism imply a fully proven authority chain.

Why this belongs next to Anthropic's fork, not instead of it

These are not competing descriptions of the same system. Anthropic documents what Claude Code's own fork mechanism actually does: inherit broadly by default, then let an operator narrow it with explicit controls. Grantex documents a different system entirely, a protocol for a grant one agent hands to another across a service boundary, designed to attenuate by default and require an operator to do nothing extra for a child to end up with less than its parent, not more. Anthropic's design and Grantex's design are answers to the same underlying question, asked in two different runtime contexts, not two accounts of one mechanism. What Grantex demonstrates, independent of Anthropic and independent of Claude Code, is that full inheritance is a choice, not the only available default. A subagent could be built to receive strictly less than its parent by construction, with a signed record of exactly how much less and where the chain traces back to, and at least one real, if young and largely single author, project has built exactly that as its starting point rather than as an add on control.

A second draft reaches the IETF, aimed at WIMSE this time

Grantex is one author's protocol with an Internet Draft attached. Days after this piece last updated, a second, separate individual submission reached the IETF addressing the same Authority Inheritance question from a different angle: draft-asor-wimse-agent-delegation-chain-00, titled Verifiable Attenuated Delegation for AI Agent Chains, authored by Rafael Asor, whose listed affiliation is Attenu, the same organization behind attenu.io and its attenu-guard reference implementation. The draft's own header lists its category as Standards Track and its working group as WIMSE, Workload Identity in a Multi System Environment. That is the author's own stated intent, not a fact about the document's standing. This session found no evidence that the WIMSE working group has adopted it, no draft-ietf-wimse prefix, which the working group's own adopted documents carry, and nothing suggesting IETF consensus, RFC status or endorsement of any kind. It is an individual submission, reachable through the same IETF infrastructure any submitter can use, exactly as this piece already said about Grantex's own draft.

datatracker.ietf.org and every ietf.org host this session tried, including the mail archive, were blocked by this session's network egress policy on every attempt, the same blockage this piece already recorded against Grantex's draft in the prior update. That means this record cannot independently confirm the live Datatracker state directly: whether a revision past -00 has since appeared, the document's current IETF state such as Active Internet-Draft or Expired, or the exact page count an announcement email is reported to carry. What this session could and did verify directly is a full copy of the draft's own text, mirrored in attenu-guard's public GitHub repository as the specification source the reference implementation is built against, plus a repeated, independently phrased general web search that surfaced neighboring WIMSE and OAuth delegation drafts by name but never a revision -01 of this one, consistent with, though not proof of, a document posted the same day this session ran. The Datatracker page itself, and the announcement's page-count claim, are recorded here as manual-review, the same accepted state this desk already uses elsewhere in this piece, not as independently confirmed.

What the token has to carry

Read from that mirrored draft text directly. A Delegation Token is a JWS-signed JWT built on the OAuth 2.0 JWT access token profile, RFC 9068, carrying an authorization_details claim under RFC 9396's Rich Authorization Requests format: an array of typed authority objects, each naming permitted actions, target locations and a constraints object. Five constraint types are defined, a numeric ceiling that a child's value must not exceed, an enumerated set a child's value must belong to, a set a child's value must not belong to, a required string prefix and an ordered rank a child must not exceed, and the draft states a verifier encountering an unrecognized constraint type MUST deny, a fail-closed rule rather than a permissive default. Holder binding runs through a cnf claim and DPoP, RFC 9449, so a service checks the presenter proved control of the bound key on the request, not merely that it holds a copy of the token; mTLS-bound tokens are named as an alternative. Two depth claims bound the chain: del_depth, 0 at the root token and incremented by exactly 1 at each hop, and del_max_depth, set once on the root and required not to increase in any descendant.

The field doing the structurally new work is par_hash, required on every token after the root and required absent on the root itself. As read from the draft text, it is a base64url-encoded SHA-256 digest of the parent token's own JWS Signing Input, the exact bytes RFC 7515 section 5.1 defines as the base64url header joined to the base64url payload by a period, not a hash of the parent's claims alone and not a hash of its full compact serialization including its signature. The stated purpose is narrow and specific: stop a valid child token being presented next to a different or broader parent chain than the one it actually descends from, a failure mode the draft calls chain splicing. That is the claim this piece verifies and repeats. It is not a claim that par_hash defends against every form of token substitution attack, and nothing here should be read as saying so.

Offline verification, and what offline does not mean

The draft's verification procedure, as read directly, asks a final Enforcement Point holding trusted root keys to check, in order, denying on the first failure: every token's signature, with the root token verifying against the trusted root key; every non-root token's par_hash against its actual parent's Signing Input; the depth sequence, root at 0, each hop incrementing by 1, and the chain length staying under the root's del_max_depth; that every child's authority is subsumed by its immediate parent's, under the same five constraint rules described above, plus an expiry that is no later than the parent's; ordinary temporal validity on every token in the chain; a valid DPoP proof binding the presenter to the leaf token's cnf; revocation status against a cached Token Status List where one is referenced; and finally, only after every earlier check passes, whether the specific requested action falls inside the leaf token's own authority. That last step is the material finding this piece already anticipated in its framing above: delegation history is not an audit trail read after the fact, it is an input the enforcement point evaluates before authorizing the action itself.

The draft's own security considerations are explicit that this offline design has a cost, and this piece preserves that language rather than rounding it into a stronger guarantee. Because the status list is cached, an enforcement point can honor a token whose revocation has not yet propagated to its local cache; the draft frames this as a standard status-list trade-off between offline verification and revocation latency, to be bounded by shorter token lifetimes rather than eliminated. An online alternative exists too, an optional RFC 7009 revocation endpoint, which implies contacting an authorization server and trades away the offline property the rest of the design is built around. None of this describes instantaneous, guaranteed cascade revocation across every relying party; it describes a cacheable, offline-checkable status mechanism with a documented staleness window.

The parent is not consumed, and a narrower child is not proof of a legitimate root

Two limitations sit in the draft's own security considerations, not in a gap this piece is inferring, and both matter to Moona's broader Authority Lifecycle framing. First: attenuation creates a narrower child token, and the draft states this does not itself invalidate the broader parent token; a holder who still possesses the parent still possesses its broader authority until that parent separately expires or is revoked. This is delegation with retention, not a transfer that empties the source, and this piece is deliberate about that distinction because task language elsewhere in this space tends to blur it. Second, and this is a limitation the draft's text does not itself address rather than one it disputes: nothing in the token profile, the subsumption algorithm or the verification procedure establishes that the entity holding the root token, the Principal implied by iss and sub on DT0, was actually entitled under any organizational mandate to create the authority the root token represents. The chain proves internal lineage from a trusted root key forward. It does not reach backward into why that root key was trusted with that authority in the first place. That gap is the same one this piece already recorded against Grantex, restated against a different mechanism.

A related distinction the draft's own chain-splicing framing makes precise, and this piece keeps precise rather than widening: par_hash is a defense against a specific structural attack, presenting a genuine child beside the wrong parent, not a general claim about resisting every category of token theft, replay or substitution. The draft pairs it with short token lifetimes and holder binding as three separate, cooperating mitigations, not one mechanism doing all the work. Cryptographic proof that a chain narrowed correctly is also not proof that a downstream action the leaf token authorized actually completed as intended, and it is not a mechanism for reversing an action already taken before a delegation was revoked; the draft addresses neither, and this piece does not credit it with either.

Where this sits next to RFC 8693 and five neighboring drafts

The comparison this piece can state precisely, because the draft states it directly: RFC 8693, OAuth Token Exchange, already supports a nestable act claim recording prior actors in a chain, and the draft's own text describes that nested information as informational at the recipient rather than something the recipient is required to check hop by hop, with token exchange itself typically implying an authorization server round trip at each step. That is a narrower claim than saying RFC 8693 cannot represent delegation, which it plainly can and does. What this piece finds is not equivalently specified there is the combination the draft is proposing: offline verification, cryptographic parent-to-child linkage through par_hash, and a subsumption check the recipient enforces as a precondition of authorizing the action, rather than a chain it can choose to read or ignore.

The draft names, and states an intent to converge with, several neighboring individual submissions this session independently located and confirmed exist through search corroboration rather than direct fetch: draft-niyikiza-oauth-attenuating-agent-tokens, which the draft describes coordinating with specifically on the shared authorization_details type value to avoid two incompatible registrations; draft-coetzee-oauth-spt-txn-tokens, a differently shaped transaction-bound token design the draft says it intends to converge with rather than replace; draft-klrc-aiagent-auth, named as companion work; draft-reece-wimse-cross-org-delegation, a WIMSE problem-statement and requirements document the draft claims satisfies its stated requirement for an attenuation mechanism; and draft-mw-spice-actor-chain, a separate and more mature individual submission, five revisions deep as this session found it, that extends RFC 8693 itself with cryptographically committed actor-path profiles rather than replacing the token exchange model. That is at least six named individual efforts, including this one, working the same general problem from different angles, an active and unsettled area, not a gap one draft is filling alone. This piece does not repeat the newer draft's own framing of novelty without that context, and found no basis this session for a first-of-its-kind claim about any single one of them.

Attenu built the implementation before the draft had a number

attenu-guard's own GitHub changelog, fetched directly this session, dates a wire-format release, JWS Delegation Tokens plus a scenario harness, to 17 August 2026, ten days before the draft's own 27 August posting date, and records a 0.4.0 entry, renaming the project from delegation-guard to attenu-guard and adding Ed25519 verification, offline evidence verification and bundle redaction, dated 24 August 2026. A 0.4.1 entry, dated 26 August 2026, is a packaging fix, one day before the draft itself was posted. PyPI's own registry timestamps for both releases record 26 August 2026, a day later than the changelog's dates for 0.4.0, which this piece notes as a discrepancy between the project's internal release date and its public package distribution date rather than resolving it in either direction. Either dating places the reference implementation's core mechanism in existence before the Internet-Draft's own posting date, supporting this piece's reading that 27 August is the draft's publication event, not the first date this attenuation mechanism existed as running code.

What attenu-guard actually is, verified directly against its own repository, documentation and package registry entry: a permissively licensed Python library, one star and no forks on GitHub at the time this session checked, a size and adoption signal this piece states plainly rather than rounding into an established project. It exposes a local, in-process Guard API, issue, delegate, check, enforce, revoke, that computes a child's authority as the intersection of a parent's authority and a requested authority, and a separate wire format for delegation tokens intended for cross-service verification. Its own standards-alignment documentation, fetched directly this session, states plainly that the token profile itself, the JWT and JWS envelope, the RFC 9068 claims discipline, the RFC 9396 authorization_details format and the RFC 9449 holder binding, reuses existing IETF work, and names the draft's actual contribution as the cryptographically linked, subsumption-enforced, offline, multi-hop verification algorithm layered on top. Framework adapters exist, by this session's count, for thirteen agent frameworks including LangGraph, CrewAI, the OpenAI Agents SDK, Google's ADK and the Claude Agent SDK. Its own README states the library does not decide authority for you, a limitation this piece takes at face value: the library enforces a boundary a deployer configures, it does not itself establish that the deployer was entitled to configure that boundary in the first place, the same mandate gap already described above.

Maturity claims are represented as this session found them documented, not rounded up. The project's own README describes a self-authored property-based test harness generating four thousand random delegation trees per invariant and a seventeen-scenario adversarial red-team suite, both explicitly self-conducted by the maintainers, not an independent audit. This session found no independent security audit, no SOC 2 attestation and no third-party penetration test documented anywhere in the repository, its documentation site or its package registry entry. The README separately claims the library is enforced live on real applications built with Google ADK, CrewAI and LangGraph, a self-reported usage claim this piece records as such, distinct from independently verified or broad production adoption, which this session found no evidence of. A related project, attenu-derive, is described in the same repository family as a separate engine for computing a proposed authority set from application structure; this piece keeps it out of the Internet-Draft's own protocol scope, since the draft's token profile and verification procedure do not depend on it and this session found no place the draft itself names it as a required component.

Running this piece's own Authority Provenance discipline against the newer draft lands close to where it already landed for Grantex, for a different reason each time. Authority grantor: the root token's iss and sub identify a signing party and a Principal cryptographically, not an organizationally verified one. Mandate or basis: undocumented in the draft's own text; a verified chain says nothing about whether the root Principal held a corporate office, an account ownership right or another entitlement to grant the authority in the first place. Delegated scope and explicit limits: strong and specifically enforced, through the five-type constraint vocabulary, the expiry-monotonicity rule and the depth ceiling, each verified directly above. Inherited permissions: bounded by construction, a child cannot hold what its subsumption check would reject, which strengthens rather than replaces this piece's existing contrast between full inheritance and bounded, attenuating inheritance. Revocation: real through the status-list mechanism, bounded by the caching latency the draft itself documents, and explicitly not a claim that the broader parent authority disappears when a child is created. Challenge authority and recovery: this session found neither a formal contest mechanism separate from revocation nor any mechanism for reversing a downstream action a since-revoked token had already authorized; both remain outside the draft's stated scope. Evidence quality: high for the internal delegation lineage the chain itself proves, cryptographically and directly verifiable; low or unknown for root mandate legitimacy, ecosystem adoption at this stage, and for anything about the downstream effect an authorized action actually produced.

What the draft itself says about fan-out, injection and replay

Re-reading the mirrored draft text directly, two days after its own posting rather than treating the 27 August pass as final, surfaces language this record had summarized in substance but not yet quoted precisely. On fan-out, the draft's own words are direct: fan-out, one parent delegating to many children, is not limited by the token format and MUST be bounded by the issuing infrastructure if required. That is the draft naming its own boundary. The subsumption algorithm bounds what any one child can hold relative to its parent. It says nothing about how many children a parent may create, and the draft does not claim otherwise. A system can correctly enforce that child_1, child_2 and child_3 are each individually within their parent's scope while the aggregate authority those children exercise concurrently exceeds what anyone intended, and nothing in the token profile or the subsumption rule this record has already verified addresses that aggregate case. This record does not describe attenuation as a solution to fan-out or concurrent-authority budgeting, because the draft itself does not claim to be one.

On the confused-deputy and prompt-injection claim, the draft's own sentence is narrower than a casual reading of "cannot be induced to exercise authority the parent lacked" might suggest, and worth stating exactly: because each hop's authority is the meet, the intersection, of the parent's authority and the request, a child cannot be induced, for example by prompt injection, to exercise authority the parent lacked. Read precisely, that is a claim about authority escalation, not about misuse. It says an injected instruction cannot cause a child to hold or exercise more authority than its parent already granted it. It does not say, and this record does not attribute to the draft, that prompt injection cannot cause a child to misuse authority it already legitimately possesses inside that narrower grant, for example by directing an agent already authorized to send email toward an unintended recipient. This record keeps that distinction, escalation beyond the parent versus misuse within an existing grant, exactly where the draft's own sentence draws it.

On resource binding, the draft's own text states that tool audiences, carried in the token's aud and locations claims, are pinned, so a token minted for one resource cannot be replayed at another. That is a direct, verifiable claim about cross-resource replay, consistent with the locations field this record already found documented in the draft's authorization_details representation, now stated as its own explicit property rather than left implicit in the constraint vocabulary described above.

On revocation, reading the verification procedure's own normative language again confirms what this record already treated as conditional rather than mandatory, now stated more precisely: Delegation Tokens are RECOMMENDED, not REQUIRED, to be short-lived, and each token MAY, not MUST, carry a Token Status List reference. A verifier consults that reference where one is present. Carrying revocation-checkable state into a token at all is the base profile's own optional design, not a universal requirement every implementation of the draft is bound to satisfy.

Three more releases, and what their own test vectors do and do not cover

attenu-guard did not stand still in the two days after the draft's own posting. Its changelog, fetched directly again this session, records three further releases: 0.5.0 on 27 August, adding a Haystack adapter, adapters for two AutoGen successor frameworks, Microsoft Agent Framework and AG2, and supply-chain provenance tooling, SLSA build provenance through sigstore attestation and weekly OpenSSF Scorecard runs; 0.6.0 on 28 August, adding an Agent2Agent (A2A) adapter and, more relevant to this record's own verification discipline, packaging the library's interop test vectors inside the installed package itself as attenu_guard.vectors, accessible without cloning the repository; and 0.6.1 on 29 August, adding an eighth rejection vector for wildcard scope widening. PyPI's own registry confirms the same version and dates independently of the project's own changelog: 0.6.1 as the current release, uploaded 2026-08-29T03:57:25Z, with 0.5.0 and 0.6.0 uploaded on the two preceding days.

Fetching the repository's tests/vectors directory directly this session found nine files: one valid chain, valid_chain.json, and eight named rejection cases. Five map directly onto the subsumption dimensions this record already verified from the draft's own algorithm: reject_widened_scope.json, reject_exceeded_ceiling.json, reject_spliced_parent.json, reject_depth_exceeded.json and reject_nonmonotonic_exp.json. A sixth, reject_bad_signature.json, exercises signature forgery rather than a subsumption rule. Two more, reject_wildcard_boundary.json and reject_wildcard_widening.json, added 28 and 29 August, exercise a specific edge case in wildcard scope matching, that a broader wildcard scope like crm.* must not be treated as satisfying a check for a narrower concrete scope, and that a wildcard must not match past its own namespace boundary. That is real, specific adversarial coverage of exactly the properties it targets, and this record states it as such rather than rounding it down. It is equally precise about what the named set does not include: no vector in this directory exercises revocation, an already-revoked token being presented and correctly rejected, and none exercises token replay, a validly issued token being presented at a destination or in a context other than the one it was bound to. This record does not describe attenu-guard's shipped test coverage as reaching those two properties, because nothing this session found in the vectors directory does.

The repository's own signals of independent adoption are unchanged from the 27 August pass: 1 star, 0 forks, no additional contributor listed beyond the project's own maintainers when checked directly this session. A general search for independent implementations of the draft's wire profile, and a targeted search of the WIMSE working group's own mailing list archive for the draft by name, found neither an independent implementation nor any adoption discussion. This record continues to state working-group adoption as not established, and adds one concrete point of contrast rather than an inference: draft-ietf-wimse-arch, the WIMSE working group's own adopted architecture document, carries the draft-ietf- prefix the working group's own adopted documents use, the same marker this record already noted as absent from draft-asor-wimse-agent-delegation-chain. That prefix is what actual working-group adoption looks like in the Datatracker's own naming convention, and this draft does not carry it.

Verifying, separately, that the five neighboring drafts this record already named are not one organization's echo: draft-niyikiza-oauth-attenuating-agent-tokens is authored by N. Niyikiza of Tenuo; draft-coetzee-oauth-spt-txn-tokens by R. Coetzee of Violet Sky Security SEZC; draft-klrc-aiagent-auth by a multi-author group spanning Defakto Security, AWS, Zscaler, Ping Identity, OpenAI and Okta; and draft-reece-wimse-cross-org-delegation by Reece. Each is a genuinely separate author or organization from Attenu and from each other. That corroborates this record's existing treatment of them as distinct individual submissions working the same general problem, not as five citations of one company's proposal, while leaving unchanged the point this record has made throughout: an individual Internet-Draft, however many distinct authors are working adjacent ones, is a proposal circulating for comment, not evidence of market or standards convergence on its specific mechanism.

Canonicalization tightens, the draft itself does not move, and RFC 8693 confirms its own framing directly

attenu-guard's release cadence did not pause when this record's own 29 August pass closed. Its changelog, re-fetched directly this session, records three further entries, all dated 29 August itself, after the 0.6.1 release this record already verified from earlier that day. 0.7.0 is marked a breaking change: every signed and hash-linked artifact must now use RFC 8785 JSON Canonicalization Scheme bytes exclusively, with delegation tokens declaring a c14n label of JCS, and duplicate object members, non-finite numbers, lone surrogates and non-canonical encodings all rejected; the interop suite grew to seventeen vectors covering divergence cases between the library's Python implementation and an ECMAScript one, plus a ninth named rejection vector for a wildcard namespace boundary. 0.7.1 follows immediately: the c14n label itself becomes informational only, since verifiers now enforce JCS canonicalization from canonical bytes and hashes regardless of what the label states, closing a gap where the label alone could not be trusted. 0.8.0 formalizes scope syntax as one interoperable grammar, lowercase dot-separated segments with a wildcard permitted only as the complete final segment after a dot, covering any depth below that boundary but not a bare prefix or an adjacent namespace, and adds two further vectors pinning malformed wildcard forms to a distinct rejection reason. PyPI's own registry independently confirms the same sequence: 0.7.0 uploaded 2026-08-29T09:50:07Z, 0.7.1 at 12:22:01Z, and 0.8.0, the current release this session found, at 19:24:35Z.

Fetching the repository's tests/vectors directory again this session found twenty-one files: a README and a generator script, one valid base-case chain, six further valid-case files exercising JCS canonicalization edge cases such as big integers, exponent notation and non-ASCII text, and twelve named rejection vectors, up from the eight this record verified on 27 and 29 August. The additions target signature and encoding failures, canonicalization violations and malformed wildcard syntax specifically. None of the twelve is named for revocation or for token replay, the same gap this record already recorded, unchanged by three more releases. The repository's own star and fork counts, re-checked directly this session, remain 1 and 0, and this session again found no independent implementation of the draft's wire profile and no WIMSE working group mailing-list discussion naming it.

None of this is a change to the Internet-Draft itself. draft-asor-wimse-agent-delegation-chain-00's own text, as read from the mirrored copy this record already cites, is unrevised, and this session again found no revision past -00 through independently phrased search, no draft-ietf- prefix, and no adoption discussion on the WIMSE mailing list. Canonicalization and scope-syntax discipline are choices attenu-guard is making inside its own implementation of a token profile the draft specifies at a less granular level; the draft's own text names JWS and JSON but does not itself mandate JCS or a specific scope grammar in its -00 revision. This record treats the distinction as worth keeping precisely for that reason: an actively developed reference implementation is not the same signal as a standard actually moving.

Separately, this pass puts one of this record's own standing claims to direct test rather than continuing to rely on the newer draft's own description of RFC 8693. datatracker.ietf.org and rfc-editor.org both remained blocked to this session's network egress policy on direct fetch, the same blockage recorded throughout this piece, so this is corroborated through independently phrased search rather than a direct read of the RFC's own served text, and is recorded as such. What surfaces, attributed specifically to RFC 8693 Section 4.1, is a sentence stating plainly that prior actors identified by any nested act claims are informational only. That is RFC 8693 describing its own act claim in almost the same words this record already used, sourced from the newer draft's own characterization: a history trail rather than something a recipient is required to check hop by hop. Finding the same language independently, rather than only through the draft that cites it, is what this record was already missing, and this pass closes that gap rather than changing what the record already concluded.

Execution binding arrives, and what it does and does not prove

attenu-guard's changelog, re-fetched directly this session, records one further release after the 30 August pass closed, 0.8.1, with a PyPI upload timestamp of 30 August 2026, but no dated entry of its own in the changelog file, the same packaging-only pattern this record already noted for 0.4.1 back on 26 August. A second release, 0.9.0, uploaded 31 August according to PyPI's own registry, is substantive. Its own changelog states plainly that bundle and anchor verification previously did not check schema version or chain identity at all, and could therefore incorrectly verify a mismatched bundle, a real prior gap rather than a hardening of an already-correct check, now fixed. The same release rejects integers beyond RFC 8785's safe integer range at construction time for the library's numeric ceiling types and at wire load, where they had previously silently collided with a neighboring integer once rendered as a binary64 float, adding a tenth vector for the case and bringing the interop suite this session counted directly in the repository's tests/vectors directory to twenty named files, still with none for revocation or for token replay.

The release's main addition is execution binding, and this record is precise about what it is. Gated behind an opt-in schema_version=2 parameter that leaves the library's existing default behavior unchanged, check() and record_denial() now allocate a cryptographically-secure call_id, and a new Guard.record_outcome() method lets the calling code report back an observed body state, returned, raised, abandoned or deferred, tying that outcome to the specific authorization decision that permitted the call, with a required error_code only when the state is raised. Six framework adapters, CrewAI, the OpenAI Agents SDK, Google ADK, Pydantic AI, Haystack and AutoGen, gained support for capturing that outcome automatically, and evidence.verify_bundle() gained matching per-call and per-node reporting so a stored evidence bundle can show which authorized calls were later confirmed to have actually run and how.

That is a genuine addition to the evidence layer, and this record states exactly how far it reaches rather than rounding it up. It is attenu-guard's own library feature, not a revision to the Internet-Draft's own text, which this session again found unchanged at revision -00. What it records is self-reported: the guarded call, or the framework adapter wrapping it, tells the same library that authorized the call what happened afterward, and the library stores that claim. Nothing in this release makes that report independently verified against the outside system the action actually touched, the way a bank statement independently confirms a payment a ledger entry only claims was made. Execution binding narrows, without closing, the gap this record has already named in the draft's own security considerations: that a chain verifying correctly is not proof a downstream action completed as intended. It gives a verifier a place to look for that proof, opt-in and self-reported, rather than supplying the proof itself. A fifth reconfirmation this session, the same search passes run on 27, 29 and 30 August repeated again, again found no successor revision to -00, no WIMSE working group mailing-list discussion naming the draft, and no implementation of its wire profile independent of Attenu.

Revision 01: a dedicated scope grammar, and a floor that narrows upward

The draft's own text moved on 3 September 2026, seven days after this record's own 27 August pass first found it. Read directly from the mirrored revision 01 text and diffed line by line against the retained revision 00 text in the same repository, the change is not editorial. Revision 00 expressed authority through a generic authorization detail object, a type field alongside actions and locations fields naming permitted operations and targets, with a constraints member mapping constraint names to typed values. Revision 01 replaces that with a dedicated type, agent_delegation, carrying a required scopes member, an array of strings, and moves constraints to an array of objects each naming a required key, the constrained dimension, alongside one typed value, for example a key of max_rows paired with a max of 5000 rather than the earlier max_rows mapped directly to its own constraint object.

Revision 01 also defines, for the first time, a normative grammar for what a scope string may actually contain. Its own ABNF is precise: a segment is a lowercase letter followed by lowercase letters, digits, underscores or hyphens; a scope is at least two such segments joined by periods, optionally ending in a wildcard, a bare asterisk, as its final segment only. A parent literal scope covers only an identical child scope. A parent wildcard scope covers any child scope that begins with the parent value once its trailing asterisk is dropped and the period kept, so crm.* covers crm.read and crm.x.y.z, but not the bare name crm and not the unrelated crmx.read. A bare asterisk on its own, a partial segment such as crm.re*, and a wildcard anywhere but the final segment, such as crm.*.read, are each invalid, and a verifier that encounters one must reject the token as malformed before it ever reaches subsumption. The draft is explicit that this wildcard rule belongs to the scopes member of the agent_delegation type specifically, not to authorization detail types in general.

The subsumption section is rewritten to match this new authority shape rather than merely relabeled. Revision 00 asked whether a child's actions and locations were subsets of its parent's, with wildcard and prefix semantics left to whichever authority type defined them. Revision 01 states the rule for its own type directly: every scope in the child must be covered by some scope in the parent under the wildcard rule above, and every constraint present in the parent must have a corresponding constraint in the child whose admissible set is a subset of the parent's, with a constraint present in the parent barred from disappearing in the child entirely, since absence would mean unbounded rather than narrower.

That callout is the shape of revision 01's other addition. Its sixth constraint type, min, is a number a child's associated value must not fall below, the mirror of the max ceiling the draft already defined. The draft states the direction in its own words, that where max carries a ceiling tightened downward, min carries a floor tightened upward, so a child's min must sit at or above its parent's rather than at or below it. The revision's own acknowledgments name where the addition came from: feedback from Amr Hassan, author of a separate individual submission, draft-hamr-oauth-agent-delegation, this session independently confirmed exists and was posted to the Datatracker on 2 September 2026, one day before this draft's own revision 01. The acknowledgments report that Hassan observed revision 00 had no comparator for a floor tightened upward, and name that draft's own duration typed tenure floor as the motivating example. This record treats the specification text describing the addition as verified and the private feedback exchange it describes as the author's own documented account, not something this session could independently confirm.

Two smaller but concrete changes round out the revision. Where revision 00 told producers to serialize with JCS and told verifiers only to reject non canonical encodings in general terms, revision 01 tells a verifier exactly what to check: that the decoded protected header and payload byte strings equal the JSON Canonicalization Scheme serialization of the parsed object precisely, not merely that some canonical form was used somewhere upstream. And revision 01 names a second new neighboring draft alongside Hassan's, draft-sweeney-wimse-credential-delegation, an online Delegation Server model, describing the two designs as two halves of one whole separated by a single axis, whether a server sits in the request path, while stating plainly that an Enforcement Point receiving a chain must still perform its own offline verification regardless of whether an online server is also in use anywhere upstream. This record found no evidence beyond that citation, which this session could not independently verify against the cited draft's own text, that the two designs have actually converged on anything beyond a shared vocabulary for the problem.

One claim this record previously quoted from revision 00 no longer holds. Revision 00's confused deputy section stated that pinned tool audiences, its aud and locations claims, stop a token minted for one resource from being replayed at another. Revision 01 drops that sentence entirely, consistent with dropping the locations field itself along with the actions and locations authority model it belonged to. This record no longer attributes a locations based resource binding claim to the draft's current text, and states the correction here rather than leaving the earlier passage to stand uncorrected.

The wire format arrived at the reference implementation before the prose did

Reading the specification is one kind of evidence. Reading what the reference implementation actually signs and ships is another, and this pass did both rather than trusting the first to describe the second. attenu-guard's changelog, re-fetched directly this session, records five further releases since the 0.9.0 this record verified on 31 August: 0.10.0, extending the opt-in execution-binding capability to six more framework adapters; 0.11.0 through 0.12.1, adding a whole-hop bundle interop vector suite that checks monotonicity across an entire evidence bundle rather than one delegation-token chain; and 0.13.0, adding observer envelopes, a witness's own signature over one committed ledger entry, carried beside a bundle rather than inside the delegation-token chain this draft specifies. None of those five entries names agent_delegation, a minimum or floor constraint, or a keyed constraint array anywhere in its own prose.

Decoding attenu-guard's own shipped interop vectors directly, the same twenty named delegation-token files this record already verified on 31 August, tells a different story than the changelog does. Every one of the twenty, its base64url-encoded JWT payload read directly this session, already carries an authorization_details entry of type agent_delegation, a scopes array, and a constraints array of key-bearing objects, the exact shape revision 01 specifies and revision 00 did not. That is a wire-format change the project shipped without narrating it, evidently building toward the revision before the revision's own text caught up in public. What none of the twenty vectors carries is a min constraint: every constraint object across every file this session decoded uses only max or rank. This record does not describe the min constraint as implemented in the reference library, only as specified in the draft's own text, and treats that gap, a real one between a published requirement and a demonstrated running implementation, as worth stating rather than assuming closed. Repository metrics, rechecked a sixth time, are unchanged: one star, zero forks, despite 229 commits on the main branch.

A fourth architecture, and the first to ship as a generally available product

Grantex and the WIMSE draft are, on this record's own reading, one author's protocol and one individual's Internet Draft, real and independently verified, but neither a shipped enterprise product a paying customer runs today. HashiCorp Vault Enterprise 2.1 changes that. Its native agentic IAM moved out of beta and reached general availability on 1 September 2026, verified directly from HashiCorp's own general availability blog post and cross checked against the hashicorp/vault repository's own v2.1.0 release page on GitHub, both fetched directly this session. developer.hashicorp.com itself, the domain carrying HashiCorp's own agentic IAM concept documentation, its Agent Registry reference and its release notes, was blocked to direct fetch by this session's network egress policy on every attempt, the same blockage this record already documents against every ietf.org and datatracker.ietf.org host above. Every claim below sourced to that domain rests on repeated, independently phrased search returning consistent detail rather than a direct read, and is graded documented, not verified, for that reason; an editor with unblocked access should confirm the underlying pages directly.

Vault's own starting point is a registry, not a permission. An agent authenticating through Vault's OAuth resource server path must first be registered in the Agent Registry and mapped to exactly one Vault Identity entity, and a client presenting an OAuth credential for an entity with no such registration is rejected outright. That gate is narrower than it first sounds, and this record states the narrowing precisely rather than letting registered read as a synonym for authorized. Registration is a prerequisite specific to the OAuth resource server authentication path; nothing this session found in HashiCorp's own material suggests an agent authenticating through an unrelated method, an AppRole or a Kubernetes auth mount among them, needs an Agent Registry record at all, and this record does not describe Agent Registry coverage as universal across every way an agent might reach Vault. Nor does the registry record itself grant anything. It identifies an agent and attaches a ceiling; the ceiling, not the registration, is where permission is bounded, and this record keeps registered agent and authorized agent as two separate facts throughout.

The ceiling itself carries a default an operator cannot opt out of. HashiCorp's own material, corroborated through search, describes a built in default-ceiling policy Vault automatically attaches to every agent registration, a narrow grant permitting an agent to read only its own registry record and the text of the default and default-ceiling policies, specifically so an agent acting on a subject's behalf cannot use the subject's own permissions to rewrite the very constraint governing it. A ceiling can only remove from what a subject's own baseline policy would otherwise permit, never add to it, and Vault 2.1's own release notes record one specific, narrow expansion of what a ceiling may express: a restriction that previously blocked deny statements inside a ceiling policy, producing a request error when one was attempted, has been removed, so a ceiling may now deny as well as simply omit permissions.

For a delegated, on behalf of request specifically, that is the rule HashiCorp's own general availability post states directly: the represented user's own permissions, the agent's ceiling policy and a per request authorization constraint, each an independently sourced limit checked on its own terms, with access granted only where every one of the three agrees. The third limit is Rich Authorization Requests under RFC 9396. The external authorization server, not Vault itself, embeds an authorization_details claim in the OAuth JWT it issues, and Vault checks that specific request's path and operation against the claim in addition to, not instead of, the entity's own ACL policies, so a request must clear both checks to succeed. HashiCorp's own material, corroborated through search, states this authorization_details claim is required by default: a request that arrives without one is denied. An operator can relax that default in either of two independently configurable places, on the OAuth resource server profile itself or on a specific agent's own registry record, and where it is made optional and a delegated request carries no agent registration at all, Vault falls back to evaluating the user's permissions and the agent's ceiling alone, without the third check. This record treats the secure default and its documented, operator controlled override as two separate facts rather than one softening the other: both are real, and neither substitutes for the other in describing what Vault actually does out of the box versus what an operator can choose to relax.

Vault 2.1 also adds parameter level constraints inside that same authorization_details claim, allowed, denied and required parameter lists that HashiCorp's own material describes as working like the equivalent controls already available in ordinary Vault ACL policies, alongside support for templated paths expressed through identity based expressions. Search corroborated detail on how the two constraint sources combine states a specific precedence rather than a vague narrowing: a parameter denied by either the policy or the RAR is denied, a parameter allowed by one but not the other is not allowed, since allowed lists intersect rather than union, and a parameter required by either source is required. This record does not extend that precedence rule to every secrets engine or parameter type Vault exposes, since nothing found here states it operates identically everywhere, and treats it as documented design for the mechanism as described.

The credential this whole check produces is short lived in a specific, named way, and this record keeps two different things apart that are easy to blur into one. HashiCorp's own general availability post states the resulting Vault token exists only for the lifetime of the request and does not persist, with Vault deriving its metadata fresh from the presented JWT's own claims on every request rather than storing a grant to reuse. That is the internal, request scoped Vault authority. It is a separate fact from the external OAuth JWT's own lifetime, which the issuing authorization server sets on its own terms and which is not limited to a single request. A consequence of re-deriving authority from scratch on every call, stated here as this record's own reading rather than a sentence HashiCorp's material uses verbatim, is that a request authorized a moment ago is not thereby guaranteed for the next one: if the represented user's policy, the agent's ceiling or the registration itself changes in between, the next request meets the new state, not the one that authorized its predecessor.

With Vault's audit devices enabled, HashiCorp's own material states that audit logs record Agent Registry operations and authenticated API requests together with identity and authorization metadata, and that a delegated, on behalf of token's own audit entry carries both the represented user's and the acting agent's identity rather than only one. This record treats that audit trail as evidence that a request happened, under which two identities and against which claims, not as proof that the underlying business action was substantively legitimate or that whatever the request touched was subsequently used as intended. An audit record is not itself an authorization receipt, and this record does not read it as one.

Revocation is the piece this record bounds most carefully, because the boundary is easy to round into something stronger than what is documented. Vault 2.1's own release notes add revocation of OAuth JWTs through Vault's token revoke APIs, described in search corroborated detail as a denylist that prevents a specific token's further authorization across every namespace inside that one Vault deployment. That is revocation scoped to Vault itself. A JWT is an immutable, independently signed artifact under the issuing authorization server's own control, and nothing this record found describes Vault's own denylist reaching backward to invalidate that same JWT at any other resource server that might also accept it. Vault revoking a token stops that token working against Vault. It does not, on anything this record found, stop the same token working anywhere else it remains valid, and this record states that distinction explicitly rather than letting Vault local revocation read as a global one.

HashiCorp's own material also documents management surfaces beyond the runtime check itself: an Agent Registry section inside Vault's own console UI, and Terraform Vault Provider resources, vault_agent_registration and vault_oauth_resource_server_config_profile, alongside API and CLI access. This record treats those as how an operator configures the mechanism already described, not as a change to the authorization model itself.

A different shape of narrowing, not a competing one

Set beside Grantex and the WIMSE draft already covered above, Vault's own three way intersection is a materially different mechanism reaching for a similar property. Grantex and the Asor draft both attenuate at the moment of delegation: a child grant must be a cryptographically or structurally verifiable subset of its parent at the point it is issued, and everything downstream trusts that the subset check already happened. Vault's third limit is not derived from any prior grant in a chain at all. It is a fresh, independently sourced constraint the external authorization server issues for that specific request, checked against the user's and the agent's own limits at the moment the request arrives rather than inherited from anything upstream of it. This record does not describe one architecture as superseding the other. A delegation chain that narrows correctly at each hop and a runtime that re-checks a fresh, request specific authorization on every call are complementary answers to the same underlying Authority Inheritance question this record keeps asking, not two implementations of one mechanism, and a system could in principle run both at once, a bounded delegation chain reaching a resource server that itself re-checks a per request constraint on arrival. This desk's own separate coverage of where authority is actually checked at the moment of execution already argues that a chain verifying correctly is not the same fact as the specific action being separately authorized; Vault's own per request RAR check is a concrete, generally available instance of exactly that argument, a resource server declining to treat a valid credential alone as sufficient and insisting on a fresh, request scoped authorization detail before it acts. Okta's own Cross App Access and Agent SSO, covered separately by this desk, governs a different layer again, whether a connection between two applications may exist at all, upstream of any single request; Vault's three way intersection operates once that connection already exists, deciding what one specific request through it may do.

Running this record's own Authority Provenance discipline against HashiCorp's own material lands on a similar shape to Grantex and the WIMSE draft, for a related but distinct reason each time. Authority grantor is not one party here but three: the represented human's own enterprise identity chain, establishing their baseline Vault policy; the Vault administrator who configures an agent's registration and its ceiling; and the external authorization server that issues the per request RAR constraint. Vault itself originates none of these grants; it only evaluates the intersection of all three. Mandate or basis remains exactly as undocumented here as this record already found it for Grantex and the WIMSE draft: a validly issued RAR constraint proves an authorization server was configured to assert it, not that the underlying business action was substantively legitimate, and this record does not read RFC 9396 or Vault's own enforcement of it as establishing that mandate. Delegated scope and explicit limits are strong and specifically enforced, through the three way intersection itself, the parameter level allow, deny and required controls, and the default ceiling's own narrow floor. Revocation is real and specifically bounded to Vault's own denylist, not a claim of removal at any other resource server the same JWT reaches. Challenge authority and recovery are, on everything this record found, undocumented here exactly as for the other three architectures already covered: nothing surfaced describes a formal channel for contesting a granted request separate from an administrator later changing policy, and nothing describes reversing an action a since revoked or since narrowed credential had already completed before that change took effect.

A fifth architecture asks the reverse question

Every architecture this record has covered so far answers a version of the same question: how much authority should a delegation carry forward. Grantex and the WIMSE draft answer it at the moment a grant is issued, requiring a child to be a verifiable subset of its parent. Vault answers it at the moment a request arrives, intersecting three independently sourced limits on every call. A late-discovered research signal, verified directly from the paper's own eight pages after the arXiv host itself and every mirror this session tried remained blocked by network egress policy throughout, and readable only once the paper was supplied to this session directly, asks the question in reverse: when one delegation is withdrawn, which of the authority it once supported should actually disappear?

The paper is VERA: Authority-Preserving Edge Revocation for Federated AI-Agent Workflows, arXiv:2608.30091v1, posted 30 August 2026 by three independent researchers, Lifei Liu, Haoran Yu and Xiaochong Jiang, each listed on the paper itself as an Independent Researcher in Seattle, Washington. VERA itself is an acronym the abstract spells out as Verifiable Edge Revocation for Agents, distinct from the paper's own title phrase, Authority-Preserving Edge Revocation, and this record keeps the two apart rather than treating the title as the acronym's expansion. Jiang's own listed email address carries a northeastern.edu domain; the paper states no university affiliation anywhere in its own header, and this record does not infer one beyond what the paper itself says. Jiang also appears, verified directly from VERA's own reference list, as a co-author on two further 2026 papers in adjacent agent-security research the same list cites, ChainCaps, a monotonic capability-attenuation framework for tool composition, and a runtime supply-chain analysis of agentic AI as an attack surface; this record notes that continuity without treating either paper's own findings as established here.

The paper's own framing names the gap precisely. Delegation graphs in real agent frameworks are not chains, they are directed acyclic graphs: a shared specialist can be authorized by more than one orchestrator, a task agent can be authorized by both a scheduling and a billing agent, and a task can cross from one deployer's domain into another's. Where a node has more than one parent, revoking one edge into it raises a question that neither Grantex's subtree cascade, the WIMSE draft's single-parent subsumption chain, nor a deployer-scoped administrative revocation actually answers: does the node keep its authority through the parent that was not revoked, or does it lose everything the revoked parent ever granted, including access through relationships the revocation never touched?

The formal target, read directly from the paper

VERA models a federated agent workflow as what it calls a SIGNED-DAG, a tuple G = (V, E, σ) where V is a finite set of agent nodes, E is a set of directed delegation edges, and σ maps each edge to a deployer signature over the edge descriptor; each node carries a deployer label and a public key, an edge (p, c) means parent p delegates authority to child c, and the graph is acyclic by construction, with retries and recurring workflows represented as successive signed epochs rather than literal cycles. Roots(G) are trust anchors a verifier already knows out of band, and reach(G) is the set of nodes reachable from any root by following directed edges. A signed revocation log carries edge identifiers and revocation times; a root-to-node path is valid at time t only if every edge on it is both authenticated and unrevoked at t.

The authority policy the paper studies throughout, and states explicitly that it is studying rather than proving universal, is disjunctive authority: a node is active at time t if and only if at least one valid root-to-node path survives. The paper is precise that this is one policy among others, matching settings where independent orchestrators can each authorize a shared agent, and states directly that it does not cover threshold approval, all-parent approval or path-scoped authority, each of which would need a different target function. This record does not extend VERA's result beyond that stated scope, and treats any claim about k-of-n or all-parent authority models as out of scope for what this paper actually establishes.

Under that policy, the paper's central definition names the exact target a revocation should hit. For a single edge e, the edge-removal intent is T_intent(e, G) = reach(G) minus reach(G with e removed), the nodes that had authority before e was removed and do not have authority after. The paper proves, as Lemma 1, that this is exactly the set of nodes for which every root-to-node path contained e; the proof runs in both directions from the definition of reachability itself, and the paper states plainly that its own contribution is not a new dominator algorithm, since the target is computable in linear time by two reachability traversals or precomputed with standard dominator machinery, but turning that already known graph-theoretic quantity into an explicit revocation-API contract for signed agent-delegation systems. This record treats T_intent as exactly what the paper proves it to be: a target defined and proven correct relative to the disjunctive-authority policy and the SIGNED-DAG model as stated, not a universal formula for every authority policy a delegation graph might carry.

A direct consequence of that same definition, not a separately worked example in the paper but a direct application of Lemma 1 this record verified against the definition itself: if a node C holds authority through two parents, A and B, and C in turn delegates to a further node D, revoking only the A to C edge leaves D untouched exactly because C itself remains reachable through B, so no root-to-D path that runs through C loses its only route. D's authority is D's own question, answered by whether every root-to-D path happens to pass through the specific edge being revoked, not by whether C's own authority came under partial pressure from one of its two parents.

Over-revocation, under-revocation, and what the paper actually measured

The paper names two opposite failures against that target, and defines them precisely: for a mechanism M, a graph G and the semantic target S, over-revocation is the count of agents the mechanism revokes that the semantic target does not, an availability and correctness failure since legitimate agents lose authority; under-revocation is the count of agents the semantic target says should lose authority that the mechanism leaves active, a security failure. Two small, deliberately constructed witnesses in the paper make the point structurally rather than statistically. On a shared sub-DAG where a root delegates to both A and B, both A and B delegate to C, and C delegates to D, revoking only the A to C edge leaves the exact target empty, since C and D both remain reachable through B; a tree cascade, which revokes a child of the withdrawn edge and everything reachable from it by forward traversal, revokes both C and D anyway, over-revoking by two nodes. On a cross-deployer chain, a root in deployer d1 delegating to A in d1, delegating to C in d1, delegating to D in a second deployer d2, revoking the A to C edge should remove both C and D under the exact target, but a cascade scoped to what deployer d1 can see revokes only C, missing D entirely, an under-revocation the paper attributes directly to the same administrative-boundary pattern that keeps a Kubernetes RoleBinding deletion, an OAuth token revocation at its issuing server, or a SPIFFE and SPIRE trust domain each contained inside one administrative domain by design.

The paper is explicit that these two witnesses are small by design, meant to show the two failures are deterministic consequences of topology and visibility rather than to estimate how often either occurs, and it separately measures scale. Generated Barabasi-Albert graphs with up to 2,000 nodes show tree cascade over-revoking on every sampled revocation event, with mean collateral loss ranging from 5.9 nodes on the smallest graphs to 79.7 nodes on the largest; across 200 random multi-parent graphs sampled under five different edge-selection policies, tree cascade over-revokes on 63.5 to 100 percent of the edges it selects. The paper's own primary agent-native evidence, what it calls E16, replays seven fixed LangGraph workflow families plus an exhaustive three by six customer-support matrix, each cell run 20 times as a compiled LangGraph StateGraph with runtime-stream events and caller-to-callee invocations recorded and normalized into parent-domain-signed delegation decisions; construct validity is deliberately narrow, a raw runtime event becomes a delegation decision only when it names a caller, a callee, a full permission tuple and a known deployer label. That yields 500 framework traces, 10,500 raw runtime events and 2,000 valid signed delegation decisions across 20 deployer domains, with 13 of the 25 workflow and input cells containing a runtime-observed multi-parent agent and 8 of 25 containing cross-deployer sharing. At cell level, the paper reports tree-cascade over-revocation affecting a mean 46.9 percent of edges and deployer-scoped under-revocation affecting 61.6 percent, each with a bootstrap 95 percent confidence interval the paper states directly, 29.3 to 64.8 percent and 45.6 to 76.7 percent respectively. Against 1,960 single-edge withdrawals replayed as baselines, holder or node revocation preserves 0 of 320 alternate-parent shared agents, an APS-style tree cascade also preserves 0 of 320 and is exact on only 35.7 percent of edge cases, and a deployer-scoped cascade is exact on 49.0 percent while under-revoking all 880 cases whose true target crosses a deployer boundary; the paper's own exact edge target and a complete-graph credential revalidation are each exact on all 1,960 cases, though the paper notes the latter requires a verifier to hold the entire graph, which the exact edge target does not.

A separate result the paper proves formally rather than only measuring, Proposition 2, is that batch revocation does not compose: for a set of withdrawn edges, the correct joint target is not generally the union of each edge's own individually computed target. The paper's own proof constructs the minimal case directly, a root delegating independently to A and B, both delegating to C: removing either edge alone leaves C reachable through the other, so both single-edge targets are empty, but removing both simultaneously disconnects C, so the batch target contains a node neither individual computation would ever produce. Measured across 39,991 sampled revocation sets over 200 random multi-parent graphs, the union of exact single-edge targets under-revoked the true batch target in a mean 21.25 percent of cases, missing a mean 0.24 and as many as 5 nodes per graph; a concrete RBAC-inspired case study, a backend service account with two parent bindings, shows the same pattern exactly, revoking either parent edge alone leaves an alternate path so both single-edge targets are empty, while revoking both at once disconnects a three-node group that a system unioning single-edge targets would fail to revoke at all. In the acyclic subset of a separately mined corpus of 28 third-party LangGraph applications, 8 of 33 alternate-parent pairs exhibited the same non-compositional gap. This record treats that as an operational warning specific to how a revocation API is implemented, not a claim about how often multi-parent revocation happens in production, which the paper itself does not claim to estimate from these numbers either.

What the prototype actually checks, and what portability does and does not mean here

The paper's reference implementation is a Python prototype using Ed25519 signatures. Its revocation log is rollback-evident: revocation events are signed, edge-targeted envelopes appended to a log that publishes a signed checkpoint carrying an entry count and a hash chain back to the previous checkpoint, so a relying party that has already seen one checkpoint rejects any later log with a smaller count, a substituted same-count history or a broken checkpoint chain; the paper states this catches rollback and substitution only after a relying party has actually observed the honest checkpoint once, not before. Rather than shipping a verifier the whole graph, an issuer ships a claimed target set plus survivor witnesses, one revocation-free signed root path for every reachable node outside the target; because disclosing only a target node's in-edges is not sound on its own, a dishonest issuer could omit an unrevoked in-edge to make a live node look disconnected, the paper closes that gap with what it calls authenticated adjacency completeness: each node's own deployer signs a commitment to that node's complete accepted in-edge set, and a verifier checks the disclosed cut in-edges of every target node against that signed commitment exactly, rejecting any omission. In the paper's own adversarial test, a forged target that revokes one in-edge while omitting a surviving alternate parent is rejected in all 40 of 40 attempts, and a second, separate check pins the completeness of the node roster itself through a federation-signed manifest, exercised by a further adversarial test that removes a disconnected roster node and confirms the proof is rejected. This record is precise about what that completeness actually covers: it is completeness relative to what each node's own deployer has already signed and committed to, not a claim that a verifier can independently discover an edge or a node no deployer ever disclosed, and this record does not read the paper as claiming the stronger, global version of that property.

Measured overhead on generated multi-parent graphs up to 2,000 nodes puts target computation at 0.17 to 2.15 milliseconds, dominated by Ed25519 verification rather than graph traversal, with a proof bundle running 64.7 to 69.0 percent of the full signed graph's size; the paper states this control-plane cost is paid when a revocation bundle or checkpoint is ingested, not on every individual agent tool call, which instead uses cached, already-verified revocation state. A broader attack matrix the paper reports rejects 1,100 of 1,100 malformed envelopes, commitments, log histories and unauthorized revocation signers, and the LangGraph replay separately adds 760 of 760 rejected attempts at unauthorized signers and omitted in-edges.

On portability, this record keeps a distinction the paper's own numbers make necessary, and states it precisely rather than rounding every framework the paper touches into equal support. LangGraph is the paper's primary agent-native evidence: real compiled StateGraph executions, real runtime-stream capture, normalized into signed delegation decisions, the same E16 evidence this record has already described. CrewAI reaches the same bar independently, in what the paper calls E19: five pinned CrewAI 1.15.1 workflows with deterministic local model behavior, all five Crew.kickoff() runs completing and yielding 35 of 35 valid task-context handoffs through the same schema. A2A and, by the paper's own table, AutoGen do not reach that bar in this paper: the paper's own adapter-boundary table groups A2A and AutoGen artifacts together as wrapper-hooked, schema-shaped evidence, two traces from an A2A artifact and two more from what the paper labels shaped artifacts, nine traces in total across A2A, AutoGen and CrewAI combined, all of which pass schema and signature validation. That is real, verified evidence that VERA's signed-DAG schema and target computation carry over to events shaped from those frameworks' own artifacts. It is not evidence that VERA ran inside a live AutoGen or A2A execution the way E16 and E19 show for LangGraph and CrewAI, and this record does not credit A2A or AutoGen with the same independent implementation weight LangGraph and CrewAI earn here, consistent with the wrapper-only hook surface the paper's own table states for them. Across that combined A2A, AutoGen and CrewAI evidence, edge targets preserved all 8 of 8 alternate-parent cases the paper selected, and deployer-scoped cascade missed all 19 of 19 cross-domain target cases, the same qualitative failure the LangGraph evidence already shows at larger scale. A separately mined static corpus of 28 third-party open-source LangGraph applications, reduced to 18 acyclic graphs after excluding cyclic control flow, is treated by the paper itself, and by this record, as lower-bound structural evidence of how often multi-parent sharing appears in real repositories, not as direct revocation traffic: 8 of 18 graphs contain a multi-parent node, and tree cascade deviates from the exact target on 54.9 percent of edges in that static set.

The paper's own stated limitations are narrower than its headline numbers might read on their own, and this record repeats them rather than smoothing them over: the policy is disjunctive authority specifically, with the paper stating directly that all-parent, k-of-n or path-scoped authority would need a different target function it does not derive; E16 uses real LangGraph machinery but controlled workloads rather than production traffic; E17 through E19 test schema portability rather than prevalence; the static corpus can miss dynamic routing a live system would exhibit; and production-scale traces and a propagation layer, the mechanism that would actually deliver a computed revocation to every relying party in bounded time, remain explicitly open, with the paper only naming the shape a propagation budget would need to take rather than building one. This record adds one further limit the paper's own text does not resolve: its closing Artifact Availability statement names an identifier, artifact-14BA, with no resolvable URL, repository name or DOI anywhere in the paper's own text, and none in the document's own embedded metadata, which this record inspected directly. This record states implementation availability as unknown, not established, on that basis, and does not treat the paper's own claim that reproduction instructions and E16 through E19 scripts exist as equivalent to an inspectable, independently locatable repository; the same standard this record has already applied to Grantex and to attenu-guard, verified there because their own repositories were directly fetched and read, applies here in the opposite direction because VERA's could not be located at all.

Where this sits next to the other four

Running this record's own Authority Provenance discipline against VERA lands in a different place than it does for Grantex, the WIMSE draft or Vault, because VERA is not itself a grantor mechanism. Authority grantor: unchanged from whatever issued the underlying delegation graph VERA is layered onto; VERA authenticates edges and revocations, it does not itself decide who may create a root of trust. Mandate or basis: the paper's own threat model states plainly what it does and does not cover. Forged delegations, unauthorized revokers, omitted in-edges, omitted reachable nodes and detectable log rollback are each named as covered; delayed or suppressed propagation and a Byzantine deployer or privacy leak are each named out of scope, in the paper's own threat table. Nothing here establishes that a deployer signing an edge was organizationally entitled to grant the authority it represents, the same gap this record has already found undocumented for every other architecture it covers. Delegated scope and explicit limits: this is where VERA's own contribution is concrete and specifically proven, an exact, formally characterized revocation target under a stated policy, verified directly against the paper's own definitions and proofs above. Revocation: the target computation is exact relative to an observed, authenticated prefix of the graph and revocation log, which is what the paper's own correctness proposition actually proves; whether that computed target reaches every relying party in bounded time is the propagation layer the paper explicitly leaves to future work, and this record keeps target correctness and delivery exactly as separate as the paper's own design-implications section states them. Challenge authority and recovery: undocumented, the same gap this record has already recorded for Grantex, the WIMSE draft and Vault, and nothing in VERA's own text addresses reversing an action a since-revoked edge had already authorized before the revocation was computed or delivered. Evidence quality: high for the formal target and its correctness proof, and for the LangGraph and CrewAI framework-grounded measurements this record has verified directly above; lower for A2A and AutoGen, where the paper's own evidence is schema and signature validation on shaped artifacts rather than live execution; and unestablished for independent implementation and production adoption, since this record could not locate the paper's own named artifact anywhere in its text or metadata.

VERA does not compete with Grantex, the WIMSE draft or Vault; it answers a question none of the three actually poses. Grantex and the WIMSE draft both narrow authority at the moment a grant is issued, and neither specifies what a verifier should do to the rest of the graph once a grant it already issued is later withdrawn from a node with more than one parent; a subtree cascade, the mechanism the WIMSE draft's own closest relative APS explicitly names as its intended revocation mechanism for a single-parent rooted tree, is exactly the over-revoking baseline VERA measures against and finds over-revokes on the majority of edges it selects across every graph family the paper tested. Vault's own three-way intersection re-derives authority fresh on every request rather than inheriting it from a chain at all, which sidesteps the multi-parent revocation-target question entirely rather than answering it; a Vault deployment could adopt VERA's own edge-level revocation log as one of the signals its per-request check consults without the two mechanisms conflicting. This record's own Authority Inheritance question, asked throughout this piece, has so far been which authority a new agent receives when one is created. VERA is evidence that the same graph needs an equally precise answer to the question in reverse: which authority a standing agent should lose, and which it should keep, once one edge that helped constitute it is withdrawn. This record does not read VERA as evidence that AEW-006, which this desk already tracks as authority inherited at delegation without attenuation, needs to widen: VERA's own authority gap is revocation-target correctness in a graph that already has more than one parent, not the absence of a subset check at the moment a grant is first issued, and this record keeps the two gaps distinct rather than folding a paper about the second into a weakness already defined around the first.

A sixth architecture answers the question inside one machine

Grantex and the WIMSE draft attenuate a token at the moment it is issued. Vault re-derives authority fresh at the moment a request arrives at a remote resource server. VERA asks what a graph of such delegations should do once one edge inside it is withdrawn. A sixth architecture, verified directly against its own source this session, answers a version of the same Authority Inheritance question at a different layer than any of the four already covered: not a credential a delegate presents to a service somewhere else, but the operating system level sandbox a single local process runs inside on the machine actually executing the work. nono, an open source CLI runtime maintained by nolabs-ai, ships a feature called Tool Sandbox, documented in its own repository, that lets a profile name specific commands, git, gh, kubectl, curl among them, and turn each into what nono's own documentation calls a brokered tool execution: a fresh, ephemeral child sandbox the broker builds for that one invocation, drawn only from the policy that names it, not from whatever the invoking session or the invoking command already holds.

This record verifies nono at the commit immediately following its v0.75.0 tagged release. v0.75.0 itself was published 1 September 2026, confirmed directly from the project's own CHANGELOG.md and from the tagged commit's own timestamp, both fetched directly this session; the one commit sitting between that tag and the branch this record actually read adds unix socket support for a Git filesystem monitor daemon, unrelated to Tool Sandbox's own delegation model, so everything this record states below about that model holds unchanged for v0.75.0 itself. Tool Sandbox is not new in this release. This record found the mechanism already mature, with its own executable trust checks, chained tool examples and credential brokering all present well before v0.75.0, and states the feature's own original introduction date as unknown rather than guess it from wherever this session's own reading happened to stop, consistent with how this piece has already treated the difference between when a mechanism was verified and when it was first built.

nono's own documentation states the default plainly: each child command starts from a minimal runtime baseline, and does not inherit outer allow grants, current working directory access, broad profile groups, raw credential paths, or outer network access. This record verified that sentence directly against the mechanism it describes rather than repeating it on trust. The broker's own child capability construction, read directly from its Linux implementation, begins from a blocked network posture and builds every filesystem, socket, environment and credential grant a child receives from the one command policy the broker selected for that specific invocation, never from the invoking session's own capability set as a source of grants; the invoking session's grants only ever bound what the outer session itself may do, never what a child command spawned inside it receives. An integration test the project ships alongside the feature makes the same point operationally rather than only in prose: a profile granting the outer session its own directory access still denies a mediated command inside the same session read access to that identical directory, because the mediated command's own selected policy grants nothing there, and a credential named in a profile's own command policy configuration is inert for any command whose own selected sandbox does not separately list it. Holding the authority to invoke a command is not, in this implementation, the same fact as the invoked command holding that authority itself.

What one mediated command may invoke next is governed by a second, independent policy object, not by whatever the calling command itself was granted. A command's own can_use array names the other commands it may invoke through Tool Sandbox; the callee's own from.<caller> entry, keyed by that specific caller's name, states what the callee receives for that one edge. Both this record verified as fail closed in every case this session traced through the broker's own caller resolution: a callee named in a caller's can_use but carrying no from.<caller> entry of its own is denied, not granted the callee's own top level sandbox by default; an explicit from.<caller> value of deny is honored as a denial rather than falling through to any other rule; and a caller whose own process ancestry cannot be attributed back to a live, already mediated command or to the session itself, a daemon that has double forked and reparented to process id 1 being the documented case, is denied outright rather than defaulting to the broader session policy. The one documented exception is a command invoking itself with no explicit self entry configured: rather than requiring a can_use edge naming itself, nono lets the invocation continue under whatever policy edge already selected that command instance for the current run, which this record treats as continuity of an already granted edge rather than a fresh, unearned one.

For a chain longer than one hop, agent to command A to command B to command C, nono's own chained tool example states the model directly: letting git invoke ssh through can_use and a matching from.git entry on ssh's own policy does not touch whether the outer session may invoke ssh directly, which a separate from.session entry set to deny blocks independently. This record traced the same principle through a three hop fixture the project's own integration tests carry, a parent command invoking a child command invoking a further command: the middle command's authority comes from its own from.parent entry, and the innermost command's authority comes from its own from.child entry, a policy object that names no relationship whatsoever to the parent command or to the session. Each hop's authority is reconstituted from that hop's own caller specific edge, not accumulated from, intersected with, or inherited through every hop that came before it. That is the durable claim this record has been building toward across five prior architectures, made concrete at the level of individual processes on one machine: a delegation chain's downstream authority is a sequence of independently authored grants, one per edge, not one grant propagating unchanged, or even monotonically narrowing, through however many hops separate an action from the session that first requested it.

Credential handling follows the same edge specific rule rather than any broader inheritance. This record verified a concrete instance directly from one of the project's own shipped examples, a GitHub CLI profile: the real GitHub token is held only by nono's own proxy, loaded from an environment variable, an OS keyring entry or a 1Password reference depending on the example, and never placed in the mediated gh process's own environment. Running gh auth token inside that sandbox returns a broker minted phantom value instead of the real token; the real credential is injected only when a matching outbound request actually reaches the upstream host the policy names, gated by an endpoint policy that defaults every unlisted method and path to deny and lists specific GitHub API routes as allowed, denied or requiring approval. nono's own documentation states the same asymmetry generally, across four declared credential types, a local socket path, a raw file, a proxy backed value and an ambient broker held secret, and is explicit that only the raw file type hands a mediated command the actual bytes; a raw file credential additionally requires an explicit opt in field before any caller other than the top level session may reference it at all, treating handing a real secret file further down a delegation chain as a deliberate widening a profile author must state, not a default. An agent that can cause gh to authenticate is not, on this evidence, the same fact as an agent that holds GitHub's own credential, and nested commands do not receive a parent command's own credential grants unless their own selected policy separately lists them.

nono's own documentation extends the same non inheritance to network access with a named, concrete example rather than only the general rule. Where a top level session grants itself a loopback callback port for an interactive OAuth login, its own material states plainly that the same grant does not extend to a tool sandbox child: if the login command instead runs as a mediated command declared under its own command policy, that command's own network policy must separately grant the callback port it needs, since the top level grant does not reach it automatically. This record found the general mechanism this specific example rests on, that a mediated child's network capability begins blocked and is only ever widened by that command's own selected policy, verified directly in the broker's own child capability construction; it did not find a dedicated automated test exercising this exact OAuth callback scenario, and states that absence rather than inferring test coverage the source does not show.

A further binding this record verified directly, and one Moona's existing Authority Inheritance material has not previously needed to state, concerns the identity of the executable behind a policy's own command name rather than the name itself. nono's own source carries a dedicated utility, documented in its own words as existing because brokers run unsandboxed, as the real user, and resolve executables by bare name via PATH, and because a sandboxed process able to write to any directory on that PATH could plant a trojan binary there for an unsandboxed broker to execute with real user privileges. That utility strips every PATH entry the sandbox could write to, directly or through a writable ancestor or symlink, before a broker resolves a bare command name, and a narrower variant additionally checks whether the sandbox holds a file scoped write grant on the exact binary name being resolved inside an otherwise safe directory. A test shipped with that code plants a trojan script in a directory the sandbox is granted write access to and a genuine script in a separate, non writable directory, both under the same bare name, with the writable directory listed first on the search path, and asserts the trojan never runs while the genuine binary does. Read against Moona's own Authority Provenance discipline, this is a specific, source verified answer to a question this record has not previously had cause to ask this precisely: authority a profile grants to a command name is bound, at the point the broker actually resolves and launches it, to a specific executable identity the sandbox cannot substitute, not merely to whatever a bare name lookup happens to find.

That binding is not absolute, and nono's own documentation is direct about the boundary rather than silent on it. A policy controlled command reached by its exact canonical path instead of through nono's own shim is denied by default, a control this record verified is enforced by comparing the resolved file's own device and inode identity against every policy controlled command nono knows, not merely its name. A profile may explicitly list a canonical path under a command's own direct exec bypass field, but nono's own documentation states what that buys plainly: the shimmed name continues to run through Tool Sandbox, while the bypassed canonical path runs with the outer session's own capabilities, not the child sandbox the command's policy would otherwise have built for it, and a command that uses any credential must separately opt into an additional field before its bypass path is even accepted, since a bypass invocation runs entirely outside the brokered launch path that would otherwise inject or withhold that credential. This record does not read Tool Sandbox as mediating every possible way a named binary can be reached; it reads the bypass path as a documented, narrow, opt in exception whose effect, reverting to the outer session's own authority, is stated rather than hidden.

The one place this record found nono's own documentation state a deliberate departure from narrowing is worth stating as plainly as the source states it, because it bears directly on a claim this piece has been careful not to make about any of the five architectures already covered. An intercept rule, matched against a specific invocation's arguments before nono decides how to handle it, may carry its own sandbox object; when that rule matches, its sandbox completely replaces the command's own selected sandbox for that one invocation, and nono's own documentation is explicit that this replacement is validated only for being well formed, not checked against the command's base sandbox, so it is not restricted to narrowing, and it can grant capabilities the base sandbox does not. This record does not describe Tool Sandbox as guaranteeing that delegated authority only ever shrinks. It describes something narrower and, this record thinks, more durable: that a delegation edge's authority is independently constituted by whichever policy object actually governs it, a command's own selected sandbox in the ordinary case, a matched intercept's override where a profile author has deliberately authored one, rather than automatically inherited or automatically narrowed from anything upstream. Widening a specific invocation this way is a grant, made by whoever authored the profile's intercept rule, and this record's own Authority Provenance discipline treats it as exactly that: a grant with the same open question this record has already found undocumented for every architecture it covers, whether the profile author held an organizational mandate to make it, which nothing in nono's own configuration syntax or source establishes and which this record accordingly leaves unknown rather than inferring from the fact that the syntax permits it.

Where a profile routes an invocation or a specific credentialed endpoint through an approval rule, nono's own source resolves an effective backend and timeout, falling back through a per rule value, a named backend's own configured timeout, a profile wide default and finally a hard coded sixty second default when nothing else is configured, and treats a timed out request as a distinct outcome from an explicit denial while failing the invocation either way, since only an explicit grant satisfies the check the broker actually runs before launching anything. This record verified that fail closed default directly rather than assuming it, and did not find any mechanism caching or replaying a prior approval decision across separate invocations of the same command; each matched request this session traced constructs a freshly identified approval request of its own. A terminal backend prompts inside nono's own supervisor process, which keeps the controlling terminal for exactly this purpose, showing the command name, its arguments, the resolved caller and the specific rule that required approval; a webhook backend posts the same structured request to an operator configured endpoint and accepts a granted, denied or timed out decision back. Whether the approved invocation then runs under the command's ordinary selected sandbox or under a matched intercept rule's own override sandbox depends on whether that specific rule carries an override of its own, the same authority reconstitution this record has already described above, with approval simply gating entry into whichever sandbox that rule's own policy already names.

The Authority Provenance ledger

Running this record's own Authority Provenance discipline against nono lands differently than it does for any of the five architectures already covered, because nono is not itself a grantor of organizational authority at all; it is a local enforcement mechanism a profile author configures. Authority grantor: whoever authors and deploys the profile, a role nono's own configuration format calls out repeatedly through named commands, callers and credentials, but never itself authenticates or verifies. Outer principal: the session or agent nono launches under a given profile. Outer authority: that profile's own session level policy, itself bounded by nono's own outer capability set. Delegation event: a controlled command's invocation, whether by the outer session or by another already mediated command. Delegated principal: the fresh child process the broker launches for that one invocation. Delegation basis: the command's own selected policy edge, its top level sandbox or session entry for a direct session invocation, or a caller specific entry naming that specific caller for a chained one, verified fail closed in every gap this record traced. Delegated scope: whatever filesystem, network, environment and credential grants that one edge's own sandbox object states, nothing carried over from the invoking session or the invoking command by default, verified directly above through the project's own shipped test fixtures. Inherited authority: explicitly limited by design, with the one documented exception of an unmodified self invocation continuing under its own already selected edge rather than requiring a fresh one. Nested delegation: each further hop's own caller specific edge, independently authored and independently enforced, never a union or an intersection with any ancestor beyond the immediate caller. Credential grantor: the profile author who configures a named credential's source, itself resolved from an environment variable, an OS keyring, a password manager reference or a broker held ambient value, with the underlying service, GitHub, a cloud provider, whatever a credential ultimately authenticates to, remaining the actual resource grantor nono's own local policy cannot substitute for. Authority expansion: an intercept rule's own optional sandbox override, documented plainly as unrestricted to narrowing and capable of granting what the base sandbox does not, a deliberate widening this record attributes to whoever authored that specific rule rather than to the mechanism narrowing by default. Grantor legitimacy: external to everything nono's own configuration or source establishes, exactly as this record has already found for Grantex, the WIMSE draft, Vault and VERA; a profile that names a caller and a callee proves that a profile author wrote that edge, not that the author held a mandate to grant whatever it authorizes. Revocation: a changed or removed profile takes effect on the next invocation nono evaluates, since every edge is evaluated fresh rather than cached from a prior grant, the same request time re-evaluation this record already found for Vault's own three way intersection, though nono's own audit trail, a hash chained, tamper evident record of every command policy decision the broker itself makes, is a record of what happened, not a channel for contesting a decision before it takes effect. Challenge authority: undocumented, the same gap this record has already recorded for every architecture it covers. Recovery: nono's own project documents a local filesystem snapshot and rollback capability scoped to files a session touched on the machine nono runs on; this record does not read that as a general mechanism for reversing an external effect, a sent message, a merged pull request, a cloud resource created, once a mediated command has already produced one. Provenance evidence quality: high for the mechanics this record verified directly against nono's own source and its own shipped integration tests, the fresh per edge capability construction, the fail closed caller resolution, the credential phantom substitution, the executable identity binding and the documented, bounded widening path all traced to specific code this session read rather than taken from documentation alone; unestablished, and left that way rather than guessed, for the feature's own original introduction date, for whether any profile in production use actually authors an intercept override that widens rather than narrows, and for whether the organizations deploying nono held whatever mandate its profiles assume.

nono does not compete with Grantex, the WIMSE draft, Vault or VERA; it answers this record's own question at the one layer none of the four reaches, the local operating system boundary a command actually runs inside once every remote token, ceiling and revocation log has already been checked. A credential that clears every check the other four architectures describe still executes, in the end, as some process on some machine, and nono's own evidence is that the boundary around that specific process is, in a real, currently shipping implementation, its own independently constituted grant rather than a shadow of whatever invoked it.

A reviewer that inherited the implementer's own task

Adept, an open source multi-agent development orchestrator, is this record's seventh architecture, and the first surfaced entirely through the delegated actor's own maintainer filing a bug against the actor's own tool, rather than through a vendor announcement, a security advisory or a research paper. Issue 334, opened 7 September 2026 by the account randomparity against the project's own repository, is titled directly: trial-loop dispatches its reviewer as an unspecified subagent type, so a fork voids both stated isolation properties.

This record reads Adept's own skill contracts directly rather than through the issue's characterization of them alone. gauntlet's own skill text states the reviewer's constraint in terms this record already uses elsewhere: read-only with respect to the target and git state, forbidding editing reviewed files, running formatters that modify the target, posting PR comments, or otherwise changing git state, with a single named exception, quoted directly, that --out writes the review JSON to a caller supplied path and nothing else, minting a run id and overwriting rather than accumulating a file across a looping caller's iterations. trial-loop's own dispatch text, read directly, states the reviewer worker's own tool allowlist must include Write, without which --out silently no-ops and the loop dead-ends, and dispatches the selected reviewer, gauntlet by default, by running it in a subagent with --json --out <findings-path>. Neither skill's own text, as read this session, names which subagent type performs that dispatch.

That gap is the issue's own diagnosis, not an inference this record adds to it. Fork semantics are intentional and already documented elsewhere in Adept's own material, the issue states, but the calling skill underdetermines the dispatch contract: it constrains the reviewer's tool allowlist in the same passage, the issue notes, which is itself evidence that dispatch terms belong in the specification, while the subagent type is simply absent. A fork type subagent, on the same default this record already documents for Claude Code, inherits the entire conversation and active instructions of whatever spawned it rather than starting fresh, so a reviewer dispatched that way does not begin from the read-only charter gauntlet's own text states; it begins already holding the parent's own live implementation objective.

The issue's own evidence section states what happened next during what it calls a campaign run, cross referencing separate maintenance issues on a sibling repository, kdive: a quest worker dispatched a fork during simplify operations, and the fork inherited active quest state and autonomously completed the workflow, applying changes, committing, pushing branches, creating a pull request, randomparity/kdive#2308, and posting handoff notifications, rather than returning a review verdict to the workflow that dispatched it. The issue separately lists collision incidents from the same underlying gap, a worktree removed mid-operation by a sibling agent, a scratch file rewritten between write and read by another agent, and multiple agent identities falsely attributed as PR authors among them, which this record records as the issue's own account and does not independently verify beyond the issue's own text.

This record independently confirms the named pull request on its own terms. randomparity/kdive#2308, titled fix(diagnostics): accept all registered worker-vantage check ids, was opened and merged the same day, 7 September 2026, at merge commit cfd2a4d6ca2d6d2bd88645417290c8f474e1a072, closing kdive#2301, with a description reading as an ordinary diagnostics fix, extending an allowlist of check identifiers, moving batch deserialization from an all-or-nothing failure to per item error degradation, and adding regression tests against the live descriptor registry, and no reference anywhere in the pull request's own text to how it was produced. That existence and merge is independently corroborated evidence of a downstream artifact. That the specific acting process behind it was the forked gauntlet reviewer, rather than some other actor active in the same run, is the issue's own first-party account: this record found no session log, commit trailer, host-level trace or maintainer comment independently naming the acting subagent, and states that attribution at the evidentiary level the issue itself supplies it at, not as independently confirmed causal telemetry.

The issue's own root cause language is worth reading in its own words, because it states a principle this record has already been arguing across six prior architectures more directly than any single source this record has previously quoted: prompt-level read-only directives are, in the issue's own phrase, insufficient, and subagent type is the load-bearing enforcement mechanism. That is a claim from the tool's own maintainer, about the tool's own runtime, that a documented behavioral constraint and the container a delegate actually executes inside are two different things, and that only the second one enforces anything. The issue's own Expected Resolution section proposes exactly that separation: specify the subagent type explicitly rather than leaving it implied, reframe the isolation claims already in the skill's own text as preconditions that depend on that specified type rather than as freestanding assertions, extend the same fix to a downstream skill, quest, that references trial-loop's own dispatch pattern without restating its constraints, and audit other skills carrying a similar pattern. Its own Proposed Approach section describes the fix as skill text modifications only, no script or harness changes, fully reversible.

As of this record's own verification the issue is open, carrying labels including bug, priority:P1 and status:in-review, with no milestone set and no linked pull request, branch, commit or comment this record could find describing a shipped fix. This record does not describe Adept's own remediation as merged, released or independently validated; the issue's own text states a proposed direction, not a completed change, and this record holds that distinction the same way it has already held it for every proposed or in-progress fix covered elsewhere in this corpus.

Set beside the six architectures already gathered here, Adept's own account does not add a new failure mode. It is the same fork inheritance Anthropic documents as Claude Code's own default, reported this time from inside a different vendor's own orchestrator, caught by the tool's own maintainer rather than by an outside researcher, and it reinforces rather than revises this record's own recurring finding: a documented instruction that a delegate stay within a bounded role is not, on its own, the mechanism that keeps it there. The mechanism is whichever container the dispatch layer actually selects, fresh or forked, and Adept's own issue states, in its own words, that leaving that choice unspecified left the sentence claiming isolation with nothing underneath it.

An eighth architecture, read from a compact bundle rather than a direct fetch

Improbable's own launch post for Bolter, an AI native messaging platform taken out of stealth on 10 September 2026 with a 10 million dollar investment, is this record's eighth architecture, and the first this record admits entirely through a single compact upstream EVIDENCE_BUNDLE that Moona Intelligence Radar itself captured and verified, rather than through a direct fetch this session made on its own. That path is documented in docs/discovery-artifact-capture.md, "Accepting an upstream EVIDENCE_BUNDLE": the bundle's own four captured excerpts were each independently traced back into its own captured text before admission, and its substantive content was captured through the same canonical raw artifact path, captureRadarSignalArtifact, every other architecture in this record's own evidence trail already uses, as artifactId sha256:e82a6f188e28f083dfcb4a83d98f1978901c46c0f4b33a4133eb60c21490aa64 and occurrence occ-moona_intelligence_radar-e82a6f188e28-<sequence>, the artifactId pinned exactly and the occurrence's content-derived prefix checked by tests/bolter-multi-agent-authority-evidence-bundle.test.ts, whose own trailing sequence number is a process-order-dependent capture counter rather than part of the bundle's own content.

Improbable's own text states that every Bolter agent runs on its own computer, with its own browser and memory, a per agent execution boundary closer in shape to nono's Tool Sandbox, covered above, than to Claude Code's own default fork, which explicitly shares context, tools and permission mode with its parent. Improbable's own text also states that Bolter's agents plan, debate, and hand work to each other, language that names delegation without stating what a delegated task carries with it once handed off. This record's own four captured claims run no further than those excerpts; it does not read into a launch post more than the launch post itself states.

Two further claims from the same post reach past authority inheritance into the binding question this record's own AEW-005, approval not bound to the executed action, already asks of every approval gate it has examined. Improbable states that every run produces a receipt showing what ran, what changed, and what awaits sign off, and that approval gates hold anything that leaves the workspace until a person approves it. A receipt naming what awaits sign off describes pending state; it is not, on this post's own text, a statement that the sign off a person eventually gives is checked against that exact receipt, or against the exact artifact or execution state the receipt described, at the moment something actually leaves the workspace. An approval is only as strong as what it is checked against at the point of execution, not at the point it was granted, and this record does not read Bolter's own launch material as stating what its own approval gate is checked against.

What this compact bundle does not establish is more consequential than what it does. It does not state what a delegation envelope actually carries across an agent to agent hand off, whether the receiving agent's own separate computer, browser and memory constitute a narrower grant than the delegating agent held, or simply a separate copy of the same standing authority. It does not state whether a task handed from one agent to a further, second recipient can carry a wider scope than the first hop itself received, the re-delegation question this record's own Grantex and WIMSE draft sections above answer only for architectures that specify it explicitly, each with an explicit hop count and a subset requirement this launch post does not describe. It does not state what the approval gate's own sign off decision is actually checked against, a specific diff or artifact, a session, or nothing more granular than the workspace as a whole. And it does not state whether a mutation to workspace state after a receipt has already been issued invalidates that receipt, or the pending approval it describes, before a person acts on it. This record treats each of those four questions as unknown rather than assuming Bolter's own architecture answers them favorably merely because the product exists and describes itself in authority relevant language. Per agent process isolation, hand off, a receipt and an approval gate are, on this evidence, a product's own account of where it has put authority, not yet a mechanism this record can verify the way it verified nono's own source directly above or HashiCorp Vault's own three way intersection in its own general availability material.

The question that is left

When the second agent attempts the action, the important question is not only what it can do. It is who authorized it to do that, and whether that authority actually survived the handoff.