The Shell Was Approved Once. Everything Typed Into It Was Not.
GHSA-g29h-pfmp-qp9r, published 16 July 2026 against the open source terminal coding agent CodeWhale, assigns CVE-2026-75857 to a gap between two sibling tools. exec_shell, which opens an interactive process such as a REPL, database console or privileged shell, is correctly gated behind a human approval prompt. exec_shell_interact, which sends further model chosen input into that same already open process, declared ApprovalRequirement::Auto in every affected version and reached no approval check at all. A single human decision to open an interpreter for a stated purpose was, in the affected source, treated as standing authority for whatever the model later chose to type into it.
Event analysed: . This analysis was published on 8 September 2026.
No, and the affected source never claimed otherwise; it simply never checked. This record independently fetched GitHub Security Advisory GHSA-g29h-pfmp-qp9r, published 16 July 2026 and reviewed by the GitHub Advisory Database on 4 September 2026, which assigns CVE-2026-75857, CWE-269, Improper Privilege Management, against the npm codewhale and cargo codewhale-tui packages, versions 0.8.41 up to but excluding 0.8.64, and against the predecessor deepseek-tui packages CodeWhale itself states it began as and still preserves configuration and session compatibility with, while stating plainly that it is now provider neutral and independently maintained, not affiliated with any model provider. The advisory's own text states that exec_shell, which starts a shell or interactive process, is correctly gated behind a human approval prompt, and that its sibling, exec_shell_interact, which sends further input into an already running process, returned ApprovalRequirement::Auto rather than Required, so CodeWhale's own approval policy was never consulted for that later input at all. The advisory's own stated proof of concept: a user approves the agent opening python3 -i for a stated purpose; later, content the model reads from an untrusted source instructs it to send a payload; the model calls exec_shell_interact with that payload as input; no approval dialog appears; the code executes. The advisory's own text extends the same mechanism to any interactive process a user might approve opening for a narrower reason, a database console, an SSH session, a privileged shell, since stdin is that process's own command surface once a session is open, and the model reaches whatever privilege that process already holds. This record independently fetched the fixing commit, 57f3c89471e27ac4032d9791f6885e5d4408c381 as stated in the advisory and confirmed directly against the repository's own commit listing, titled fix(tui), require approval for interactive execution tools, which changes ShellInteractTool's own approval_requirement method in crates/tui/src/tools/shell.rs from ApprovalRequirement::Auto to ApprovalRequirement::Required, adds ToolCapability::RequiresApproval to its declared capabilities, and adds a regression test confirming the change, with the identical fix applied in the same commit to a second, sibling interactive execution tool, RlmEvalTool, in crates/tui/src/tools/rlm.rs, whose own gap CodeWhale's maintainers separately assigned GHSA-wrj3-vj8c-784f the same day. This record independently fetched the v0.8.64 release, dated 22 June 2026, roughly three and a half weeks before the advisory's own 16 July 2026 publication, a gap consistent with a coordinated disclosure embargo, and confirmed its own release notes state plainly that interactive execution surfaces require approval among a list of several other security fixes shipped in the identical release. GitHub's own security advisories page for the affected repository lists nine advisories published the same day, 16 July 2026, alongside GHSA-g29h-pfmp-qp9r: SSRF DNS pinning bypass, GHSA-6v2g-fpxh-pmmh; the sibling RLM auto-approval RCE, GHSA-wrj3-vj8c-784f, named above; a project config instructions override enabling arbitrary file read, GHSA-62f5-cp2p-vq95; a project config allow_shell override enabling arbitrary shell execution, GHSA-gx45-xrj5-g6c4; argument injection in git_blame allowing arbitrary file read without approval, GHSA-c6mw-8xh8-gpq6; argument injection in git_show allowing arbitrary file write without approval, GHSA-7j5w-7r7x-9v27, rated Critical; a workspace symlink follow in image_analyze, GHSA-w7wx-5q49-r59w; and a parent environment leak in js_execution, GHSA-h539-c7r8-3xq4. This record treats that batch as the same coordinated disclosure and the same shipped release, not as nine independent occurrences of this one advisory's own mechanism, and does not adopt any of the other eight advisories' own distinct mechanisms as part of what GHSA-g29h-pfmp-qp9r itself establishes.
An interactive shell is not one action. It is a channel a process keeps open, and every line sent into it afterward is a fresh decision about what that process should do next. CVE-2026-75857 is what happens when a coding agent's own approval system treats opening the channel and using it as the same decision, because one of its two tools that touch that channel checks for approval and the other, by declaration rather than by oversight, does not.
What the advisory states
This record fetched GitHub Security Advisory GHSA-g29h-pfmp-qp9r directly. It is titled exec_shell_interact sends LLM controlled input to a running shell without an approval prompt, privilege escalation, rated High, published 16 July 2026 against the npm codewhale package and the cargo codewhale-tui package, versions 0.8.41 up to but excluding 0.8.64, fixed in 0.8.64, and against the cargo and npm deepseek-tui packages, the predecessor project name CodeWhale's own repository states it began as. This record separately fetched the GitHub Advisory Database's own mirror of the same advisory, which states it was reviewed and its record last updated 4 September 2026, and carries the formally assigned identifier CVE-2026-75857, classified CWE-269, Improper Privilege Management, with a stated CVSS 4.0 vector of AV:L/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N and a base score of 7.3.
Two tools, one process, one of them never checked
The advisory's own description states the mechanism precisely. exec_shell is the tool that starts a shell or another interactive process, and the advisory states this tool is correctly gated, an approval prompt stands in front of it. exec_shell_interact is a separate, sibling tool whose job is to send further input into a process exec_shell already started and that is still running, addressed by the running task's own identifier. The advisory's own stated defect is that exec_shell_interact's own declared approval_requirement returned ApprovalRequirement::Auto rather than Required, so whatever CodeWhale's approval policy would otherwise have required for a consequential action was never reached for this one at all. The advisory's own quoted framing states the consequence directly: inside those processes, stdin is the command surface, so the model gets to run commands at whatever privilege that process holds.
The advisory's own stated proof of concept walks the gap in four steps. A user asks the agent to open a REPL for a stated purpose, and the agent's call to exec_shell with a command such as python3 -i receives the user's own approval, exactly as the tool's correct gating requires. Later in the same session, content the model reads from an untrusted source instructs it to send a specific payload into that same, still open interpreter. The model calls exec_shell_interact, naming the running task and supplying the payload as input. No approval dialog appears, because the tool's own declared requirement was Auto rather than Required. The payload executes as Python code, at whatever privilege the interpreter process itself already held. The advisory's own text extends the identical shape to any interactive process a user might legitimately approve opening for a narrower stated reason, a database console authenticated as an administrative user, an active SSH session to a remote host, a privileged shell opened for one specific diagnostic command, since stdin is that process's own command surface for as long as the session stays open, and nothing about approving the session's own opening constrains what a later, model chosen line sent into it can do.
The fix, read directly against the commit that shipped it
This record fetched commit 57f3c89471e27ac4032d9791f6885e5d4408c381, as the advisory itself names it, directly, titled fix(tui), require approval for interactive execution tools. The commit's own changes are narrow and precisely targeted: in crates/tui/src/tools/shell.rs, ShellInteractTool's own approval_requirement method changes from returning ApprovalRequirement::Auto to returning ApprovalRequirement::Required, and ToolCapability::RequiresApproval is added to the tool's own declared capabilities vector, the same metadata surface CodeWhale's own approval engine reads to decide whether a call needs a prompt at all. A companion test file, crates/tui/src/tools/shell/tests.rs, adds direct coverage confirming the interactive shell tool now declares an approval requirement through both its capability metadata and its approval_requirement check. The identical shape of fix lands in the same commit for a second, separate interactive execution tool, RlmEvalTool, in crates/tui/src/tools/rlm.rs, whose own capabilities vector and approval_requirement method are changed the same way, with its own added test confirming it. CodeWhale's own maintainers assigned that second tool's gap a separate advisory the same day, GHSA-wrj3-vj8c-784f, rlm_eval auto approves arbitrary Python execution, bypassing the user's approval policy, RCE. This record treats the two as evidence of the identical underlying authority gap, an interactive execution tool's own declared approval requirement left at Auto rather than Required, reached independently for two different tools and fixed by the identical one line change applied twice in the identical commit, rather than treating either as a second, independent occurrence of the other's own advisory.
Shipped roughly three and a half weeks before disclosure
This record fetched the v0.8.64 release directly and confirmed its own stated release date, 22 June 2026, roughly three and a half weeks before GHSA-g29h-pfmp-qp9r's own 16 July 2026 publication date, a gap consistent with a coordinated disclosure embargo rather than with any uncertainty about whether the fix was ready. The release's own notes, read directly, state a short list of security fixes shipped in the identical release, among them interactive execution surfaces require approval, matching this advisory's own mechanism exactly, alongside separate fixes this record does not fold into this advisory's own claim: project local config can no longer loosen user owned shell or instruction file policy, file edits now require fresh file reads and git history inputs reject problematic revisions, local tool paths are validated through workspace and root checks before access, TLS verification bypass requests now fail closed, fleet alert webhooks require HTTPS, and runtime tokens, session identifiers and webhook URLs are redacted from logs.
What one approval was never established to cover
Nothing in the advisory's own text, or in this record's own reading of the fixing commit, shows that CodeWhale's own approval prompt for exec_shell was ever documented, designed or claimed to extend past the one decision it actually presented, whether to start the named process for the stated purpose. The advisory's own proof of concept turns entirely on a second, later decision, what to send into that process once it is open, being a materially different action from the first: a different tool, a different call, a different payload chosen after the first approval had already been granted and acted on, in the concrete case chosen specifically because untrusted content the model encountered afterward is what selected it. exec_shell_interact's own declared ApprovalRequirement::Auto did not misread an approval that covered this later action; it treated the later action as needing no approval decision from CodeWhale's own policy engine at all, because nothing in the tool's own declared metadata told that engine a decision was called for. This desk's wider argument that execution authority has to be evaluated against the action a system actually takes, not the action a principal was nominally authorized for, holds here in a shape this desk has already named once through a differently structured mechanism: a field's own authority defining role does not automatically extend to a materially different, more consequential role a downstream interpreter can derive from the identical position, the same collapse this desk's own reading of Amazon CodeCatalyst's blueprints SDK already documented for a project file's own owner field, evidenced here instead at the level of two sibling tool declarations sharing one running process rather than one field carrying two meanings.
What this record does not establish
This record does not claim CVE-2026-75857 was exploited against a real user's own session before the fix shipped, that every CodeWhale or deepseek-tui installation still pinned to an affected version remains reachable by an attacker able to place instructions in content the model reads, that the eight other advisories GitHub's own listing dates to the same 16 July 2026 disclosure share this advisory's own exact mechanism beyond the one, rlm_eval, this record independently confirmed through the identical fixing commit, or that CodeWhale's own current approval engine, beyond the two tools this record's own reading of the fix directly examined, correctly declares an approval requirement for every other interactive or consequential tool it exposes. Where the evidence available to this record does not establish a fact, this record states it as unknown rather than inferring it from the pattern this weakness class shows elsewhere.
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.
- 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.