You Approved the Right Command. The Agent Executed Something Else.
A patched Cursor vulnerability from earlier this year is worth reopening, because Docker's account of it names the actual failure precisely. The command a developer approved was never swapped for a different one. It stayed exactly what it said it was. What changed was the environment it ran in, mutated moments earlier by something the approval step was never shown.
Event analysed: . This analysis was published on 22 August 2026.
Nothing does automatically, and a patched Cursor vulnerability is the clearest documented case of why. CVE-2026-22708, reported by Dan Lisichkin of Pillar Security and disclosed on 14 January 2026 in GitHub Security Advisory GHSA-82wg-qcm4-fp2w, affected Cursor versions 2.2 and earlier when the Cursor Agent ran in the non default Auto-Run Mode with Allowlist mode enabled. Cursor's allowlist checked whether a proposed command matched a program on disk. Shell built-ins including export, typeset and declare are not programs on disk, so they executed without ever appearing in the allowlist and without any approval prompt, even against a completely empty allowlist. Those built-ins can set, modify or remove environment variables. An attacker able to place instructions in content the agent later reads, a file, a dependency, an issue, could use that gap to poison the shell environment before the agent ever proposed a command a human would see. A later command the agent proposed and the developer genuinely approved, exactly as written, could then behave differently than its own text promised, because part of what decided its behavior, the environment it ran in, had already been rewritten by something the approval step was never shown. Cursor fixed this in version 2.3, released alongside the disclosure, improving how terminal command parsing handles these edge cases and moving toward requiring explicit approval for anything its parser cannot classify. Docker's analysis, published 18 August 2026 as part of its coding agent security series, revisits the patched vulnerability to make a structural point rather than a current threat claim: an allowlist checks whether a command's name is approved, not what the command will actually do once it runs, and an environment variable set moments earlier can change the second thing while leaving the first thing, and the check built around it, completely satisfied. Updated 23 August 2026 with Pillar Security's own fuller proof of concept chain, which sets PYTHONWARNINGS, BROWSER and PERL5OPT in sequence to reach code execution through an ordinary python3 command rather than through Docker's git example, with verification of Cursor's current layered Auto-review run mode, introduced after the patch, and a dedicated Authority Provenance ledger establishing that the developer approving a command is documented only as the proximate grantor of that one call, with no broader organizational mandate, revocation channel or recovery path established in available material.
Most of what gets called an approval bypass in agent security is a story about a check that did not fire. Somebody found a way to skip the prompt. CVE-2026-22708 is a more unsettling variant, and it is worth returning to now that Docker has written it up carefully, because the check did fire, correctly, on the command that actually mattered. The developer saw it. The developer approved it. It ran exactly as written. And it was still not the action they thought they were authorizing.
What Pillar Security found, precisely
Pillar Security's research team, credited to Dan Lisichkin, reported the underlying issue to Cursor privately in 2025, and it was disclosed publicly on 14 January 2026 in GitHub Security Advisory GHSA-82wg-qcm4-fp2w, assigned CVE-2026-22708. We read the advisory directly. It affects Cursor Agent versions 2.2 and earlier, specifically when a workspace runs in Auto-Run Mode with Allowlist mode enabled, a configuration Cursor itself describes as non default rather than what most installations use out of the box. Cursor rates the advisory High severity. It was fixed in version 2.3, and the advisory's own remediation language is narrow and specific: terminal command parsing around edge cases was improved.
The mechanism is the part worth sitting with. Cursor's allowlist was built to check whether a proposed command matched a program the operator had already trusted, and that check worked by looking for an executable on disk. Shell built-ins, export, typeset and declare among them, are not executables on disk. They are interpreted directly by the shell itself. Because the checker was looking for the wrong kind of object, these built-ins ran without ever being evaluated against the allowlist and without triggering an approval prompt, and the advisory states this held even when a workspace's allowlist was completely empty, the most restrictive setting available. An attacker who could get instructions into content the agent later reads, a README, a dependency, an issue comment, through indirect prompt injection, could use exactly this gap. Not to run their payload directly. To set the table for it.
The command that ran was the command that was approved
Docker's account, published 18 August 2026 as the fifth entry in its coding agent security series, works through a version of the exploit chain built around a command almost nobody would hesitate to click yes on: git branch. We read Docker's article directly. Its shape is this. Something the agent reads first contains an instruction to run export, setting the PAGER environment variable to a command of the attacker's choosing. That step needs no approval and shows the developer nothing, for exactly the reason Pillar's research identifies: export is a built-in, and the allowlist was never watching for built-ins in the first place. Later, the agent proposes git branch, an ordinary, safe looking, entirely accurate description of what it is about to do. The developer approves it, because it is git branch, and git branch is what it says on the label. Git then does what git always does on startup: it checks the PAGER environment variable to decide how to display its output, and PAGER is no longer what the developer's shell configuration set it to. It is whatever the attacker's export statement put there.
Nothing about the command the developer approved was false. Its name was accurate. Its arguments were accurate. If you compared the text the approval prompt showed against the text that reached the shell, they would match exactly, character for character. What did not match was the environment those characters were about to execute inside, and the approval step had no visibility into that environment at all. It could not have, because the environment was not part of what was being approved. It was ambient. It was the water the approved command swam in, silently changed by something upstream that the approval prompt was never designed to notice.
The fuller chain Pillar demonstrated
Docker's PAGER example is a minimal, explanatory illustration, chosen because git and its use of PAGER are familiar to almost any developer. Pillar Security's own research demonstrates a fuller chain, and it is worth holding the two apart, because the fuller chain does not depend on git, or on any command a reader would recognize as display related, at all. Multiple independently phrased searches of secondary reporting on Pillar's research converge on the same sequence, though Pillar's own site was not reachable for a direct read in this session: export sets PYTHONWARNINGS to a value crafted so that the next matching warning causes Python's interpreter to import antigravity, a Python standard library easter egg dating to 2008 whose own code calls webbrowser.open to launch a comic in a browser. The webbrowser module decides what counts as a browser by reading the BROWSER environment variable, so a second export, setting BROWSER to perlthanks, a Perl script that ships alongside a standard Perl installation, hands that call to Perl instead of an actual browser. Perlthanks itself respects PERL5OPT for command line options, and a crafted PERL5OPT using Perl's -M flag loads and executes arbitrary Perl code the attacker supplies. Every step in that chain is itself an export, so none of it ever reaches Cursor's allowlist, for exactly the reason the PAGER example does not: none of it is a program on disk, and reporting on Pillar's research is consistent that this chain also worked against a completely empty allowlist. What makes it the fuller demonstration rather than a second illustration of the same point is what it rides on. The command a developer ultimately approves in this chain is not a display tool like git branch. It is an ordinary python3 script.py, the kind of command a developer approves for reasons that have nothing to do with warnings, browsers or Perl, and Docker's own account credits Elttam's 2020 research on environment variable driven code execution as the technique this chain builds on, repurposed here for Cursor's specific allowlist gap.
Three ways an authorized action can fail, and this is the third one
It is worth being exact about which failure this is, because collapsing it into ordinary allowlist bypass talk loses the part that makes it distinct. Moona Intelligence reads three separate failure modes hiding under the single word approval, and CVE-2026-22708 demonstrates the least discussed of them.
The first is an action executing without the approval it was supposed to require. The export and typeset calls in this vulnerability are exactly that: a control that should have fired and did not, because the checker was built to recognize the wrong category of thing. This failure mode is not new to this piece. A patched AWS vulnerability in Strands Agents Tools showed a related version of it, where a shell tool's human consent gate had a real off switch, and the off switch was a parameter the model itself was allowed to set. Both are cases where the human never got a chance to say no.
The second is an action changing after approval, a bait and switch where what runs is not what was shown. That is not what happened here. Nobody swapped git branch for a different command after the developer clicked approve.
The third is the one this vulnerability actually demonstrates: the visible action stays textually identical to what was approved, and its consequential meaning changes anyway, because something outside the scope of what was approved, in this case a shared, mutable piece of execution state, determines part of what the action actually does. The command was real. The approval was real. The gap sat entirely in what the word command was assumed to include. An approval prompt that shows a command's name and arguments is implicitly claiming that the name and arguments are the whole of what it is authorizing. Nothing about a shell environment is included in that claim, and nothing about a shell environment is stable between the moment a human reads a prompt and the moment the shell actually executes it.
What proves the meaning held
That is the question this vulnerability leaves standing after the patch. Cursor 2.3 closes the specific gap Pillar's research found, by classifying built-ins correctly rather than letting them slip past the allowlist as an unrecognized category. It does not, and could not on its own, answer the more general question a shell environment poses to any approval mechanism: once a human has approved a command's text, what continues to guarantee that the environment resolving that text at execution time is the same environment the human implicitly assumed when they approved it. Cursor's current documentation, corroborated through independent search after direct access to cursor.com remained blocked in this session, describes a layered Auto-review run mode, introduced in a later release than the one that patched this vulnerability, that evaluates a proposed command against the allowlist first, then a sandbox where one is available, then a separate classifier model, and states plainly that the allowlist itself remains best effort, not a security boundary, and that a determined agent or a prompt injection may still get past it. That is a materially different architecture from the single allowlist check CVE-2026-22708 exploited, and it is worth crediting as such. It is still, on the evidence available to this record, a defense in depth design rather than a claim that any one of its three layers, the allowlist included, is itself a hard boundary, and nothing in Cursor's own documentation claims otherwise. Separately, Cursor's current permissions reference documents each allowlist entry as a command or command prefix string matched against a proposed command's text, which corroborates precisely the object this piece has argued approval actually binds to: a command's displayed text, not the environment resolving it.
What containment answers, and what it does not
Docker's own contribution is not a claim to have solved the authorization question. Docker is explicit that its sandboxing does not stop the injected instruction from running, and does not stop the poisoned environment variable from being set. Inside a Docker Sandbox, by Docker's own account, the export statement still executes, and PAGER still gets poisoned. What changes is what that poisoned execution can subsequently reach. Docker describes microVM isolation with a deny by default network posture, so the same PAGER trick that could reach an SSH key or exfiltrate data on an unsandboxed machine finds no SSH key present and no open path out. Docker also documents two of its own caveats worth repeating rather than smoothing over: a workspace directory is live on the host by default, so a poisoned git hook or Makefile target inside that live directory stays reachable unless an operator explicitly isolates it, and Docker's shared skills store is mounted read write across sandboxes by default, so a skill modified inside one poisoned session can reach the next session even though it cannot reach the host directly. Docker separately describes Kits, a declarative network and filesystem policy an organization can review and version like code instead of maintaining as a personal allowlist, and an organization wide governance layer it says can override a local allow rule and generate an audit event, naming the user, the timestamp and the rule that fired, for every policy decision. Those are Docker's own documented claims about its own product, not independently reproduced by Moona against a running deployment, and they are containment claims rather than authorization claims.
The distinction matters more than it looks. Whether an action should be allowed to execute at all is a question authorization answers. Whether the action that actually executed still corresponds to the action a human meant to authorize is a separate question, approval integrity, and it is the one CVE-2026-22708 speaks to. What happens to the consequences once an action executes anyway, despite a broken or absent answer to either of the first two questions, is a third question, containment, and it is the one Docker's sandboxing, network policy and audit logging actually address. An audit event that records a poisoned PAGER variable being set is a real improvement over silence, and Docker is right that it converts an invisible bypass into something an investigator can find. It is a record of the bypass having happened. It is not evidence that the bypass did not happen, and it is not a mechanism that binds a command's meaning to what a human approved. Reducing what a compromised execution can reach is valuable and distinct from guaranteeing that execution matches authorization in the first place. Moona Intelligence's reading is that Docker's own framing supports exactly this separation, and the risk in covering this story is treating the second as proof of the first.
Where this sits against what this desk has already argued
The broader argument that instructions cannot be the boundary, and that authority has to be evaluated at the moment an action executes, is the family this piece belongs to, and CVE-2026-22708 sharpens a part of it that earlier evidence had not isolated. That argument is mostly about whether a system prompt or a written instruction can be trusted to hold a line. This vulnerability is not about an instruction failing to hold a line. It is about an approval succeeding, on exactly the text it was shown, while a separate and unmonitored piece of shared state decided what that text would actually do. Evaluating authority at execution time, the standard the earlier piece argues for, only closes this gap if what gets evaluated at execution time includes the environment the command is about to resolve inside, not only the command's own name and arguments. Most approval architectures, allowlists very much included, evaluate the second and never look at the first.
The Strands Agents Tools pattern, where the field controlling whether a consent gate fired was itself exposed to the model, is the nearest relative rather than the same failure. There, the model could turn its own gate off, inside the same tool call the gate was supposed to be guarding. Here, the gate never had jurisdiction over the mechanism at all. Shell environment variables are not a field in any tool's input schema. They are ambient state that persists across an entire session, readable and writable by any built-in the shell recognizes, and no schema level fix closes a channel that was never inside the schema to begin with. Approval becoming an action an agent can request is a different member of the same family again, about who is authorized to grant approval. CVE-2026-22708 does not touch who grants approval. It touches whether granting it means anything once granted. Claude Code's own move away from a per call prompt, toward a classifier that judges an action before it runs, is worth naming here too, because it is close to what Cursor's current Auto-review run mode now does with its own third layer. Neither is evidence that a classifier closes the specific gap this piece describes. A classifier judging a proposed action is still judging the action as represented to it, and this record has not verified what representation either classifier actually receives.
What this does not show
This is a patched vulnerability, not a current one. Cursor 2.3 and later versions are not affected by the mechanism described here, and nothing in this piece should be read as a claim otherwise. Moona Intelligence found no evidence, in Pillar's research, in Cursor's advisory or in Docker's later analysis, that this vulnerability was exploited against a real deployment before it was fixed. This was responsibly disclosed research, reported privately and patched, and the record of it becoming public runs through a coordinated advisory rather than an incident report. Nor does one environment variable technique, on one editor, in one non default configuration, establish that every approved command can be arbitrarily transformed. What it establishes is narrower and still durable: a command's approved text is not, by itself, evidence of what that command will do, because a command's meaning is resolved against an execution context that an approval prompt showing only a name and its arguments has no way to represent.
The Authority Provenance ledger
Authority grantor. The developer presented with Cursor's approval prompt, the person who reads a proposed command and decides whether to approve it, is the proximate execution grantor for that one call. That is as far as the evidence reaches. Nothing in Pillar's research, Cursor's advisory or Docker's account establishes, or was written to establish, that holding a Cursor session or a development workstation carries any broader organizational authority than the single call being approved, and this record does not infer one from the fact that a person had access to approve it.
Mandate or basis. Undocumented. None of the three primary accounts this record relies on address why the developer approving a command is entitled to authorize every consequential effect reachable through the privileges the Cursor agent process already holds. That is a question about organizational delegation, separate from Cursor's software, and none of the available material was written to answer it.
Delegated scope. This is the center of the vulnerability, and the evidence is precise on it. What a human approves, in Cursor's allowlist and its approval prompt, is a command's displayed text, its name and its arguments, checked as a string or a string prefix against a list of trusted programs. It is not the environment that command will resolve inside at the moment it runs. CVE-2026-22708 exists because those two things were treated as a single act of approval when they are not. Approving a command's text is not the same fact as authorizing every effect the command produces once environment state outside that text has already been changed by something the approval step never saw.
Explicit limits. Recorded here exactly as they operated in the affected versions, up to and including 2.2, rather than generalized to the product today. Auto-Run Mode with Allowlist mode enabled checked a proposed command against a list of trusted programs found on disk. Shell built-ins, export, typeset and declare among them, are not programs on disk, so the check never evaluated them, and this held even when the allowlist itself was empty, the most restrictive configuration available. That is not a limit that occasionally failed under pressure. It is a category of command the check was never built to see at all.
Inherited permissions or assumptions. What executed inherited exactly the privileges already available to the running Cursor agent process, nothing more. Neither Pillar's research, Cursor's advisory nor Docker's account claims privilege escalation beyond that process, and this record does not assert root, administrator or cloud level authority for either demonstrated chain. The PAGER chain and the PYTHONWARNINGS chain each hand execution to a program, a calculator application, a shell, Perl, that the agent process itself was already permitted to run.
Revocation or modification path. What exists is a parser change, not a runtime revocation mechanism. Cursor 2.3 made anything its parser cannot classify require approval going forward. Available material does not describe a way to revoke or invalidate one specific already granted approval, or to detect and roll back an environment variable that was poisoned in the moments before a human approved a command that then read it. What this record can confirm is a version upgrade, applied once, that closes the path for future calls.
Challenge authority. The human confirmation mechanism existed, and that is why this is not a case of approval simply being absent. Cursor showed the developer a command and asked. The failure is narrower and more specific than no challenge occurring at all: what was displayed and challenged did not encode the shell environment the command would actually run inside, so approving the displayed object left a variable outside that object's scope free to determine part of what execution actually did. This record keeps that distinct from a complete absence of human challenge, a different and more familiar failure documented elsewhere in this corpus.
Recovery path. Undocumented beyond the patch itself. Pillar's research, Cursor's advisory and Docker's account each describe how the vulnerability worked and how it was fixed. None describes a rollback, compensation or restoration process for a command that already executed against a poisoned environment while a version before 2.3 was deployed. Patching the parser prevents a future recurrence. It does not reverse an effect a poisoned command already produced.
Provenance evidence quality. Strong and independently corroborated for the technical mechanism: Cursor's own advisory, read directly, and Docker's own account, read directly, agree on what the allowlist checked, what it missed and why. Weaker, and undocumented rather than merely thin, for everything upstream and downstream of that mechanism: no material establishes an organizational mandate for the developer granting approval, a channel through which someone other than that developer could challenge a specific approval already given, or a recovery path for an effect a poisoned command already produced before the patch. The strongest evidence in this record is mechanical, what the parser checked and what it now checks instead. The weakest is exactly what a human's approval was supposed to settle and could not, on its own, guarantee.
The question worth carrying forward
Every approval architecture answers a version of the same question its designer has to be honest about: when a human looks at a proposed action and says yes, what exactly is included in that yes. A name and its arguments are the easiest thing to show a person and the easiest thing to check against a list. They are not the same thing as the full state that determines what running that name with those arguments will actually do. CVE-2026-22708 is one small, patched, well documented case where that gap had a name, PAGER, and a mechanism, export. The gap itself is not specific to Cursor, to shell environments, or to this one CVE. It is specific to any approval step that checks what an action is called without checking what, at the moment it runs, that action has been quietly set up to mean.
Corrections and updates
: Added Pillar Security's own fuller demonstrated proof of concept chain, distinct from Docker's illustrative PAGER and git branch example: export statements set PYTHONWARNINGS, BROWSER and PERL5OPT in sequence, so that an ordinary python3 command a developer would approve for unrelated reasons ends in arbitrary Perl code execution, corroborated through multiple independently phrased web searches after direct access to Pillar's own site remained blocked at this session's network egress proxy. Added verification of Cursor's current documentation on its layered Auto-review run mode, introduced after this vulnerability's patch, which evaluates a proposed command against the allowlist, then a sandbox where available, then a separate classifier model, and states the allowlist itself remains best effort rather than a security boundary; cursor.com is blocked to direct fetch in this session, so this is corroborated through independent search rather than a direct read. Added a dedicated Authority Provenance ledger verifying authority grantor, mandate or basis, delegated scope, explicit limits, inherited permissions and assumptions, revocation and modification path, challenge authority, recovery path, and provenance evidence quality against a strict standard: no material found establishes an organizational mandate for the developer whose approval CVE-2026-22708 concerns, a channel by which someone other than that developer could challenge a specific approval already given, or a recovery path for an effect a poisoned command already produced before the patch, and each is recorded as undocumented rather than assumed. The original analysis of CVE-2026-22708, the PAGER example and Docker's containment claims is unchanged.
Sources
This analysis interprets third-party reporting, research and announcements. Moona is not the original reporter of the underlying events.
Protocol evidence
This record does not assess these architectures. The connection runs through the Risk Registry requirement each one bears on, and these published authority architectures are what the evidence says about that requirement.
Protocol evidence related through AEW-005 Approval not bound to the executed action
- Supports requirement
Agent Flight Recorder
Laurent Bindschaedler, Quentin Botha, Christoph Siebenbrunner (independent research, arXiv preprint)
Requirement Cryptographic binding of the approval field to the approver's identity and the specific action is described as a production deployment property, not an unconditional schema guarantee
This weakness's own known examples are, across every one of them, a case where an approval attached to nothing verifiable or a later state change went unchecked against a prior decision. Agent Flight Recorder's own schema keeps a human approval field and an execution field as two independently checkable facts rather than one narrative line, which is a direct answer to the underlying need this weakness names: an approval must bind to a specific action, not merely occur near one. It supports that requirement rather than implementing an enforced version of it, because the reported cryptographic binding of the approver's identity to the specific action applies only in production deployments of the construction, not as an unconditional schema guarantee, and the mechanism records the approval/execution relationship for later forensic inspection rather than checking it before the action dispatches the way EMILIA's action hash rejection or Codex CLI's authorization freshness recheck do.
- Supports requirement
Agent Infrastructure Control Protocol (AICP)
Tihan-Nico Paxton, Apollo Deploy (individual submission to the IETF)
Requirement An accepted approval binds cryptographically or transactionally to one exact plan revision
This weakness's own corrective response pattern calls for binding an approval to the exact action object by hash or an equivalent identity, and rejecting execution when the action presented for review differs from the action about to run. AICP's own Section 9.4 requires an accepted approval to be cryptographically or transactionally bound to the Plan identifier, exact revision, approving principal, material changes and expiry, stating directly that approval of prose alone is insufficient and that a changed revision is not authorized by the old approval. The HTTP binding in Section 14.5 enforces the same binding mechanically, through a conditional request against the Plan's strong entity tag. Recorded as design evidence for the requirement this weakness already states, not as a claim that any provider has implemented this draft's text.
- Supports requirement
An Architecture for Auditing Agent Delegation and Interactions (audit-architecture)
Mirja Kuehlewind (Ericsson) and Henk Birkholz (Fraunhofer SIT), individual submission to the IETF
Requirement Authorization is modeled as an ordered sequence of transitions, not a single current value
This weakness's own response pattern calls for recomputing an approval's binding to the exact action at the enforcement point rather than trusting an earlier decision, including the temporal window that decision was made under. The draft's Action Record carries an authorization scope and expiry alongside the action it bears on, and its Authorization Transition Record class exists specifically so the state in force at a given point in a run can be reconstructed rather than assumed from whatever is currently known. Recorded as design evidence for the general response pattern; this record's own evidence separately connects to a targeted extension of Moona's canonical Authority Resolution engine closing the equivalent gap in Moona's own runtime reasoning, not a claim that this draft's own text was implemented anywhere.
- Supports requirement
ChainIT Authority Protocol and Agent Subject Profile for pre execution authority validation
ChainIT
Requirement A canonical transaction digest is described binding payer, payee, destination, amount, currency or asset and payment rail to approval and execution
A canonical transaction digest binding payer, payee, destination, amount, currency or asset and payment rail to both approval and execution is a direct, more specific response to an approval that attaches to nothing in particular. This is the corrective this weakness describes, named at the level of concrete payment fields rather than a generic hashed parameter set.
- Supports requirement
Codex CLI 0.151.0, restored permission profiles and authorization bound Guardian classifications
OpenAI
Requirement A cached low risk score is checked against the current authorization state before it is allowed to approve, and a mismatch defers to strict review rather than proceeding
Codex CLI's own fix rechecks a cached decision against current authorization state before it is allowed to approve anything, refusing to let a decision computed under one state keep approving after that state has moved. Claude Code's own current plugin marketplace documentation, read directly, describes an installed plugin auto-updating on a version, commit or content digest signal with no described mechanism to diff, flag or gate a change to the plugin's own hooks.json specifically, so whatever authority a user's earlier trust decision represented is not shown to be rechecked once a later update changes what that plugin's bundled hooks execute. Codex CLI's own mechanism is the corrective the reviewed documentation does not describe for this specific binding.
- Supports requirement
EP Authorization Receipts (EMILIA Protocol)
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Requirement Implementations MUST reject an approval request whose action hash does not match a locally recomputed hash of the presented Action Object
EMILIA's requirement that an approval be rejected unless the action hash matches a locally recomputed hash of the exact action object is the binding these cases lack, where an approved command's behaviour is decided by state the approval never inspected.
This record is the cited evidence for this relationship.
- Supports requirement
EP Authorization Receipts (EMILIA Protocol)
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Requirement Offline verification does not establish current revocation status, and the draft requires a relying party to apply current policy and current status inputs before any new reliance decision
UiPath Maestro's own default on Refresh schema before call setting keeps an MCP tool's technical interface current immediately before each call, but nothing in UiPath's own documented behavior establishes that the parameter authority a workflow's configuration granted against the original schema is re evaluated once a later schema changes underneath it. That gap, a technically current interface with no stated authority re evaluation behind it, is exactly the condition EMILIA's own requirement, that a relying party apply current status rather than historical acceptance before a new reliance decision, exists to close. UiPath's mechanism supports the need for that requirement rather than implementing it, the distinction this dataset already keeps between this property's two linked entries. A preprint posted to arXiv on 3 September 2026, 2609.03340, Fresh Memory, Stale Plans, restates the same distinction for a derived plan specifically: an executor that has read a superseding revision of a shared requirement into its own memory can still execute a plan derived from the earlier revision, since refreshing the executor's memory does nothing to a plan already computed from the state that memory has since moved past, so current state and current authorization for a pending action are two different facts. Read at the manual review evidence level, corroborated through convergent search rather than a direct read of the primary text, since arxiv.org and every mirror this record attempted were blocked at this session's network egress proxy; treated as further support for the requirement, not as an implementation of it.
- Supports requirement
N-AALP, Native Agentic Application Layer Protocol (draft-bubblefish-naalp)
BubbleFish, individual submission to the IETF
Requirement A signed-action-object model with a content-bound Approval and a single-use consume ledger is reported, not independently verified
This weakness's own response pattern calls for binding an approval to the exact action object, by hash or an equivalent identity, rather than to a name or a connection. The reported mechanism, an Approval bound under signature to the content id of the exact canonical argument object and, for an MCP call, a tool_id and args_id together, so a changed tool description or changed arguments yields a different approved call identity, would be a clean instance of exactly that pattern if it accurately reflects the draft's own filed text. This session could not independently verify that text through any reachable primary or secondary source, so this link is recorded conditionally: design evidence for the weakness's own already-established requirement, not confirmation that this specific draft implements it.
- Supports requirement
N-AALP, Native Agentic Application Layer Protocol (draft-bubblefish-naalp)
BubbleFish, individual submission to the IETF
Requirement A durable single-use consume ledger, and a stated limit that offline verification proves validity at issue, not current unspentness, are reported, not independently verified
This weakness's authorityGap states that authority attaches to what was presented for review, not automatically to whatever executes afterward; an approval a durable ledger has already recorded spent is not, in any meaningful sense, still attached to a further execution. The reported single-use consume ledger, and the reported statement that offline cryptographic verification proves validity at issue rather than current unspentness, would instantiate that gap precisely for a signed approval's own consumption state rather than its identity binding. Unverified by this session for the reason stated above; this record's own independent contribution is the additive extension it separately motivated to Moona's canonical Authority Resolution engine (an evidenced approval's singleUse/consumed state, consulted only when singleUse is evidenced true), which does not depend on this specific draft's own claims being confirmed.
- Supports requirement
The Missing Execution-Finality Protocol Layer of the Internet (draft-das-execution-finality-protocol-layer)
Sangram Das, individual submission to the IETF
Requirement A validated Candidate Act may produce a narrowly scoped, non-bearer Execution Handle bound to that one act and to the Finality Sink that will consume it
This weakness's own response pattern calls for binding an approval to the exact action object and recomputing that binding at the enforcement point rather than trusting possession of a credential. The non-bearer Execution Handle, corroborated through convergent search rather than a direct read of the filed text, generalizes exactly that principle to a credential class broader than one interface family: a validated Candidate Act may produce a handle scoped narrowly to that one act, and possessing the handle is not itself proof the currently presented act still matches the one it was issued for. Recorded as documented design evidence restating this weakness's own already-established requirement at a general level, not as independent confirmation that this specific umbrella draft's own mechanism is demonstrated running anywhere.
- Supports requirement
The Missing Execution-Finality Protocol Layer of the Internet (draft-das-execution-finality-protocol-layer)
Sangram Das, individual submission to the IETF
Requirement Formalizes Candidate Act, Non-Effective State, Protected Enforcement Domain, Execution Handle and Finality Sink as shared vocabulary for a family of domain-specific drafts
This weakness's own known examples had, before this addition, connected to draft-das-agentic-tool-binding-03 as though it were a freestanding architecture. Convergent search corroborates this draft as the umbrella that sibling instantiates: a Protected Enforcement Domain validates authority scoped to an act's purpose, destination, jurisdiction, freshness, revocation state, policy epoch, runtime integrity and effectuation-boundary identity together, a broader validation surface than the tool-binding draft's own two directly verified consequence classes. Recorded as design evidence for this weakness's own binding requirement at the general architecture level; this session located no reference implementation for this specific umbrella draft and does not treat any part of it as independently verified running code.
- Supports requirement
The Missing Execution-Finality Protocol Layer of the Internet (draft-das-execution-finality-protocol-layer)
Sangram Das, individual submission to the IETF
Requirement Fails closed on missing, stale, mismatched, replayed or unverifiable context
This weakness's own response pattern calls for rejecting execution when the action presented for review differs from the action about to run, rather than proceeding on a default allow. The signal that prompted this record carries a five-item fail-closed enumeration, missing, stale, mismatched, replayed or unverifiable context, consistent with the fail-closed behavior this weakness's own draft-das-agentic-tool-binding-03 known example already verified directly in running code for one narrower mechanism. This session's own independent search did not itself return that exact enumeration from a secondary source, so this link is recorded as documented design evidence consistent with corroborated evidence, not as independently re-confirmed word for word against the filed text.
- Supports requirement
tool_use Is Not invoke(): Binding Execution Finality to Agentic Tool Call Interfaces and MCP (agentic-tool-binding)
Sangram Das, individual submission to the IETF
Requirement Authority is scoped to one Candidate Act through a deterministic digest of its own exact arguments
This weakness's own response pattern calls for binding an approval to the exact action object by hash or an equivalent identity and recomputing that binding at the enforcement point rather than trusting the request. Act Bound Authority, confirmed directly this session from the draft's own reference implementation, is exactly that binding applied to tool dispatch: a deterministic digest computed over a Candidate Act's own exact arguments, so authority issued for one call cannot be presented for a different call bearing different arguments even under the same session or workload. Recorded as design evidence independently demonstrated in running reference code, not as a claim that this specific implementation is deployed anywhere.
- Supports requirement
tool_use Is Not invoke(): Binding Execution Finality to Agentic Tool Call Interfaces and MCP (agentic-tool-binding)
Sangram Das, individual submission to the IETF
Requirement A Finality Sink verifies authority atomically immediately before invoke() runs, fail closed on any failure
This weakness's own response pattern calls for recomputing an approval's binding at the enforcement point rather than trusting an earlier decision. The Finality Sink, confirmed directly this session from the reference implementation's own sink module, is that enforcement point positioned immediately before the underlying invoke() call, verifying authority atomically and blocking execution whenever verification does not succeed rather than proceeding on a default allow. Recorded as design evidence for the same requirement EMILIA's own action-hash rejection requirement already formalizes for payment operations, applied here to tool dispatch generally.
- Supports requirement
tool_use Is Not invoke(): Binding Execution Finality to Agentic Tool Call Interfaces and MCP (agentic-tool-binding)
Sangram Das, individual submission to the IETF
Requirement Each parallel tool call requires its own independently computed authorization
None of this weakness's own known examples had, before this addition, named independent authorization for concurrent tool calls specifically. The reference implementation's own test scenarios, read directly this session, decide a parallel search plus unauthorized payout case as two independent authorization decisions rather than one session-level trust judgment covering an entire batch, closing a gap this weakness's own binding requirement implies but had not yet evidenced concretely for parallel dispatch.
- Supports requirement
tool_use Is Not invoke(): Binding Execution Finality to Agentic Tool Call Interfaces and MCP (agentic-tool-binding)
Sangram Das, individual submission to the IETF
Requirement A retried or replayed call presenting already-consumed authority is denied
This weakness's own known examples document an approval or a cached decision surviving a state change it never accounted for; none had yet named a retried or replayed call presenting already-spent authority as its own distinct axis. The reference implementation's own replay store, read directly this session, marks authority consumed atomically on first use and denies a subsequent presentation of the same authority, with the implementation's own stated limitation that this protection is local rather than distributed. Recorded as design evidence for a property this weakness's own response patterns imply but had not yet evidenced at this level of precision.
- Implementation evidence
EP Authorization Receipts (EMILIA Protocol)
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Requirement Implementations MUST reject an approval request whose action hash does not match a locally recomputed hash of the presented Action Object
MoonPay's PayBox documents that any change to an operation's amount, merchant, destination, contract, function or secret name after submission forces a fresh approval request rather than letting the original one carry over. That is the same operation-bound approval EMILIA's action-hash rejection requirement formalizes cryptographically, arrived at independently in a live consumer product rather than a draft specification, which corroborates that the requirement is buildable outside a standards process.
- Implementation evidence
EP Authorization Receipts (EMILIA Protocol)
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Requirement Offline verification does not establish current revocation status, and the draft requires a relying party to apply current policy and current status inputs before any new reliance decision
Codex CLI's own merged fix binds a cached Guardian v2 classification to the exact authorization state it was scored against and refuses to let it approve an action once that state has moved, arrived at independently in a shipped product rather than a draft specification. That corroborates EMILIA's own requirement that a relying party apply current status inputs before a new reliance decision rather than treat historical acceptance as still current, the same binding failure this weakness already describes. OpenMAIC's own 1.0.1 fix, read directly by this dataset, applies the identical principle to a network destination rather than a cached score: fetchWithRedirectValidation re-runs validateUrlForSSRF against every redirect hop before following it, rather than treating the single validation performed against the caller's originally supplied bring your own key base URL as still current once an ordinary HTTP redirect substitutes a different destination. A third independent, shipped instance of the same requirement, this one at a network authority boundary rather than at an approval or a classification.
- Missing requirement
ChainIT Authority Protocol and Agent Subject Profile for pre execution authority validation
ChainIT
Requirement No canonicalization algorithm, serialization format or independent test of the transaction digest against a live or reference transaction was found
Naming the fields a digest binds is not the same fact as a demonstrated binding. No canonicalization algorithm, serialization format or independent test of the digest against a live or reference transaction was found, so whether an executed transaction can be proven identical to the one approved remains a missing requirement rather than a closed one.
- Missing requirement
Codex CLI 0.151.0, restored permission profiles and authorization bound Guardian classifications
OpenAI
Codex CLI's own shipped Guardian v2 fix binds a cached tool call classification to the exact authorization state it was scored against, refusing to let a stale classification approve a call once that state has moved. GitHub issue 43549, read through this session's own automated web fetch and summarization tool, reports a materially different gap this record's own reviewed material states nothing about: whether a tool call's own reported terminal status, here the literal status aborted following the caller's own interruption, is checked against the account level effect that call already produced before reporting that status. The reviewed protocol record binds a decision to the state it was made under; it does not, on the material available to this session, bind a call's own reported outcome to the state the call actually left behind.
- Missing requirement
tool_use Is Not invoke(): Binding Execution Finality to Agentic Tool Call Interfaces and MCP (agentic-tool-binding)
Sangram Das, individual submission to the IETF
Requirement The reference implementation ships under a restricted evaluation license, not open source
Demonstrating a binding mechanism in reference code is not the same fact as that mechanism being available for production adoption. This session's own direct read of the reference implementation's LICENSE.md confirms a source-available evaluation license, not open source, explicitly denying production deployment and commercial use and reserving patent rights outside evaluation. Recorded as a missing requirement for anyone evaluating this reference implementation as a buildable corrective rather than as design evidence, not as a claim against the underlying architecture the draft itself describes.
Protocol evidence related through AEV-2026-0002 Cursor terminal allowlist bypass via environment variables (CVE-2026-22708)
- Supports requirement
EP Authorization Receipts (EMILIA Protocol)
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Requirement A conforming signing client MUST render the human readable presentation from the exact Action Object covered by the action hash rather than from a separately supplied description
The Cursor allowlist bypass, where the approved command's behaviour was decided by unapproved state, supports EMILIA's requirement that the human readable presentation be rendered from the exact object the approval covers.
This record is the cited evidence for this relationship.