Slack Put the Approval Where the Conversation Is. It Did Not Put the Enforcement There.
Slack Code launched on 20 August 2026 on every Slack plan. Coding agents now get their own channel, their own diffs and their own live preview, and Slack says that for high stakes moves the agent packages its work for an expert to sign off on. Read that sentence again. The verb is packages, not blocks.
Event analysed: . This analysis was published on 21 August 2026.
On the published evidence it is a described workflow, and Slack does not document an enforcement mechanism behind it. Slack, a Salesforce company, launched Slack Code on 20 August 2026, available on any Slack plan, with founding partner agents reported consistently as Claude Code from Anthropic, Devin from Cognition, GitHub Copilot and the Vercel agent. A partner agent creates a code channel through a Slack API when it is tagged, and the channel carries a plan, the repository and branch, code diffs and a live preview across dedicated tabs. Slack documents three real controls: anyone in the channel can pause, redirect or stop an agent mid task; agents in code channels inherit Slack's permissions and admin controls, so no new identities are provisioned; and when the task ends the channel archives itself and the record survives as a searchable audit log. On production, Slack's own wording is that for high stakes moves, like pushing code to production, the agent packages its work for an expert to sign off on, right in the channel, which keeps people in control without slowing things down with separate IT approvals. Packages is a preparation verb. Nothing published states that the agent is prevented from proceeding, who is eligible to be the expert, whether a sign off is bound to a specific diff, commit or deployment, whether an approval can be reused, or what happens if nobody responds. Slack states that Slack Code is not a coding model, a harness or an agent runtime, and that it built an API for partner agents to create and manage the channel type, so the code executes and the deployment happens in the partner agent's own infrastructure and the customer's own pipeline, not in Slack. That places the enforcement point outside the product that describes the approval, and Slack publishes no mechanism binding the two. Moona Intelligence records this as documented product behaviour for the channel mechanics and the interruption controls, a vendor claim for the sign off, no demonstrated enforcement, and no independently established production adoption one day after launch. Updated 28 August 2026: AlpacaX, which sells an AI native privileged access product called Alpacon, published an article arguing that an approval channel must be structurally separate from whatever channel an agent used to request the action, so a requesting credential can never also clear its own hold. Moona Intelligence could not fetch that article directly, alpacax.com sits behind the same kind of egress block that already affects this record's other sources, so its argument is recorded here as a vendor position rather than an independently confirmed one. What is independently verifiable, read directly from Alpacon's own open source command line client on GitHub, is narrower: that client has no approve or reject subcommand at all, a held command can only be cleared from a separate web console or Slack, and a session's own requester can cancel a pending request but not approve it. That is a real, checkable instance of channel separation in a different vendor's tooling. It does not close Slack Code's own open questions about who counts as an approver, what an approval binds to, or where enforcement sits, which remain exactly as open as they were on 21 August 2026.
The most quoted sentence from the Slack Code launch is the one about production. It is worth putting on the page exactly as Slack wrote it, because almost every summary of it since has quietly upgraded the verb.
The agent packages its work. It does not say the agent is stopped, blocked, held, gated or prevented. It says the agent finishes preparing something and hands it over. Whether anything in the world compels the handover is a separate question, and Slack does not answer it.
What actually shipped
Slack, a Salesforce company, launched Slack Code on 20 August 2026. It is available on any Slack plan from the day of launch, and Slack charges nothing additional for creating or operating code channels, though a customer still needs its own access to whichever partner agent it wants to use.
The mechanism is a new channel type. Tag a supported coding agent from an ordinary conversation, and if the agent judges the request a fit it opens a code channel scoped to that task. The channel is not a normal channel with a bot in it. It has dedicated tabs: a Conversation feed, a Plan showing the agent's task breakdown, Code Diffs showing the lines it changed, and a Live Preview rendering HTML output as it goes. It carries the repository and branch the agent is working in and the pull request information. When the task ends, the channel archives itself and stays searchable.
The founding partner agents reported consistently across the launch material are Claude Code from Anthropic, Devin from Cognition, GitHub Copilot and the Vercel agent. Some accounts of the launch add OpenAI's ChatGPT to that list and others do not, so we are recording the four consistent names and leaving the fifth open rather than resolving a discrepancy we cannot check. Access to the code channel APIs is limited to the launch partners for now, with Slack saying it intends to open them more widely later.
Three controls Slack does document
It would be unfair to read this launch as marketing with nothing behind it. Three things Slack states are concrete, checkable claims about product behaviour, and they matter.
The first is interruption. Anyone in a code channel can pause, redirect or stop an agent mid task. That is a real control and it is unusually broad: not the person who started the task, not an admin, anyone in the channel.
The second is identity. Agents in code channels inherit Slack's permissions and admin controls, and Slack's framing is that IT provisions no new identities. Whatever else is true, the agent is not arriving with a fresh credential nobody has inventoried, which is a genuinely better default than most agent deployments manage.
The third is the record. The channel archives itself when the work is done and the record survives as an audit log. The plan, the diffs, the conversation and the sign off, if one happened, all sit in one searchable place afterwards.
Slack is not where the code runs
This is the part that decides the whole question, and Slack says it plainly itself: Slack Code is not a coding model, a harness or an agent runtime. What Slack built is an API that lets partner agents create and manage the new channel type.
Follow that through. The agent executes somewhere else, on Anthropic's or Cognition's or GitHub's or Vercel's infrastructure. The repository lives somewhere else. The deployment, when it happens, is performed by the partner agent's own systems or the customer's own pipeline. Slack is the surface where the work is shown and discussed. It is not the thing that runs the deploy, which means it is not positioned to refuse one.
So when Slack says an expert signs off in the channel, the sign off is a message in Slack and the consequential action is an event in a system Slack does not operate. For that message to function as an authorization rather than a courtesy, something on the far side has to be listening for it, has to require it, and has to refuse to proceed without it. Slack publishes no such mechanism. Neither, as far as we can find, does any partner. That does not prove the link is absent. It means nobody has shown it exists.
What an expert is not
One trap is worth flagging because it is easy to fall into. Slack separately ships a product called Channel Expert, which is a prebuilt AI agent that answers questions in a channel. The expert in the Slack Code sentence is not that. It reads as an ordinary English word meaning a person who knows the system, and Slack defines no role, permission, group or designation to go with it.
That leaves the eligibility question completely open. In a code channel where anyone can pause the agent, can anyone also sign off? Is it the person who assigned the task? A repository owner? Somebody who happens to be in the channel at the time? Nothing published says. An approval whose approver is undefined is a workflow convention, not an access control.
What the sign off is not bound to
The other half of the question is binding. A meaningful authorization answers: approval of what, exactly, and good for how long.
Nothing in the launch material states whether a sign off attaches to a specific diff, so that a later change to the same branch would need a fresh one. Nothing states whether it attaches to a specific commit. Nothing states whether it attaches to a specific deployment, or whether one approval covers everything the agent does afterwards in that channel. Nothing states whether an agent that receives no answer waits indefinitely, times out, or proceeds. Nothing states whether an agent can reach production by any path that does not pass through the channel at all.
Each of those is the difference between an approval and the appearance of one, and all of them are currently unanswered.
Where the evidence actually sits
Four levels are worth keeping apart here, because collapsing them is how a launch post becomes a security claim.
Documented product behaviour. The channel type, the tabs, the diffs and preview, pause, redirect and stop, permission inheritance, self archiving into an audit log, availability on all plans. Described by the vendor, consistent across the launch material, and specific enough to be checked by anyone with a Slack workspace.
Public implementation. Thin. The code channel API exists, because partner agents are using it, but it is restricted to launch partners and we found no public technical documentation of it. There is nothing published for an outside engineer to read and evaluate.
Demonstrated enforcement. None. No artifact shows a deployment being refused for want of a sign off, and Slack does not operate the systems where a deployment would be refused.
Production adoption. Not established. Slack's account is that its launch partners run code channels internally, and there is a launch day claim that some of them do most of their coding in Slack. That is the vendor's characterisation of its own partners on the day the product shipped. It is not adoption evidence and one day is not a track record.
A different vendor answers part of the question
One week after Slack Code shipped, AlpacaX, which sells an AI native privileged access product called Alpacon, published an article dated 28 August 2026 arguing for a specific design rule: an approval channel has to be structurally separate from whatever channel an agent used to request the action, so the credential doing the asking is never also the credential that can clear the hold. Moona Intelligence could not fetch that article directly. alpacax.com sits behind the same kind of egress block that already affects other sources in this record, and repeated search retrieval returned only fragments rather than text reliable enough to quote in full, so its argument is recorded here as a vendor position rather than an independently confirmed one.
What we could verify directly, by reading Alpacon's own open source command line client on GitHub rather than its marketing, is narrower and does not depend on trusting that article. The client, which is what an engineer, an AI coding agent or a CI pipeline uses to execute commands against a managed server, ships no approve or reject subcommand. Its own documentation states that approving or rejecting a session happens in the Alpacon console, described as web or Slack, not in the command line client, and a held privileged command returns a distinct pending approval exit code rather than a refusal. A session's own requester can cancel a pending request, which withdraws it, but nothing in the same documentation gives that requester a path to approve it. Taken together, that is channel separation built into the tool rather than only claimed about it: the surface an execution credential runs through structurally lacks the operation a hold requires.
The same documentation records that a pending approval can settle without being granted in several distinct ways, listed as rejected, expired, revoked, cancelled or completed, evidence that an approval request is not a standing grant, though nothing found states whether a granted approval is single use or can be replayed against a command other than the one shown. It also documents that gated commands run inside a work session carrying a declared purpose, and that a command can be refused for reading as off purpose for that session, a pattern this record treats the same way it treats Slack's own permission inheritance: a real default, not proof that the declared purpose itself was legitimate. A service or personal API token bypasses the work session gate entirely and is instead checked against that token's own access rules, a separate containment mechanism rather than an approval path.
None of that closes the questions this record opened about Slack Code. Alpacon is a different product with a console rather than a group chat channel, and nothing found here establishes who is eligible to approve inside that console, whether an approval binds to the exact command a person saw, or whether the same separation holds between two channels controlled by the same person rather than between two classes of credential; that question is outside what we independently confirmed here. What the client's code and documentation establish on their own, independent of any marketing language, is that at least one vendor has shipped a tool where the credential used to ask cannot also be the thing used to answer. Slack's own launch material, a week earlier, still does not say whether the same is true of Slack Code.
Why this is still worth recording
Moona Intelligence's read is not that Slack overpromised. It is that Slack has moved something interesting, and the interesting thing is location rather than strength.
The agent is allowed to do the whole job. It plans, writes, opens the branch, produces the diff, renders the preview and assembles the change into something a person could ship. All of that is preparation, and preparation is where agent capability has been heading for a year. What Slack has done is put the moment where that preparation is supposed to become a real production effect onto the surface where the team already talks, in front of everyone, with the diff and the plan and the history attached to it.
That is a genuine structural claim about agent authority: an agent may be permitted to prepare a consequential production change while the decision to make it real is reserved for a person. It is the same distinction we have drawn between what an agent can reach and what it should be authorized to do with it, and the same one AWS drew when it separated permission to call a submission tool from authority to submit the decision.
What Slack has not done is make that reservation binding. The distinction between an action you can see and an action you can still prevent is exactly the one a control assessment of frontier developers was built around, and a code channel is a very good instrument for seeing. Where an approval is actually enforced turns out to be a question about which boundary the request has to pass through, and Slack is not on the path between the agent and production. And once approval is a message rather than a mechanism, the question of who is authorized to give it becomes load bearing, which is the problem a GitHub experiment ran into from the other direction when it let an agent request approvals of its own.
None of that makes Slack Code a weaker product. It makes it a collaboration surface that has taken on the vocabulary of an authorization system. The two converge only if something outside Slack is built to honour the sign off, and on 21 August 2026 nobody has published evidence that anything is.
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-011 Evidence after the fact mistaken for authorization before it
- Supports requirement
A Black Box for Agentic Processes
Arslan Bromme (independent research, arXiv preprint)
Requirement The paper's own evidence model separates temporal anchoring and artifact integrity from event ordering, capture authenticity, authorized anchoring and causal traceability
This weakness's own authority gap states that evidence made after an action is not the authorization decision made before it. This paper's own evidence model draws a closely related separation from a different starting point, stating directly that digest verification establishes only that a retained artifact matches a prior commitment, not that the underlying event was captured completely or faithfully, occurred in the order a chain of anchors implies, was anchored by an authorized party, or is true. It supports the requirement that a Moona reasoning surface never let evidence integrity alone stand in for authorization or captured truth, rather than implementing an enforced version of that separation, since the paper itself proposes no mechanism that checks these properties against each other.
- Supports requirement
A Black Box for Agentic Processes
Arslan Bromme (independent research, arXiv preprint)
Requirement Anchoring or timestamp order between two committed events is explicitly not treated as proof of causal or workflow order
This weakness already treats a record made after an action as distinct from authorization of that action; this property extends the same discipline to a narrower claim this weakness's own known examples had not yet named directly, that the order in which two events are anchored or timestamped reflects anchoring and confirmation mechanics rather than the causal order of the underlying workflow. It supports requiring an explicit dependency link before an anchored or timestamped order is read as proof that one recorded action caused or authorized another.
- Supports requirement
A Black Box for Agentic Processes
Arslan Bromme (independent research, arXiv preprint)
Requirement The paper frames its use for governance, risk and compliance evidence, incident reconstruction and regulatory reporting readiness, not as a preventive control
This property frames blockchain anchored agent evidence as governance, risk and compliance and regulatory reporting readiness infrastructure, not a preventive control, the same record versus gate separation this weakness already states as its own authority gap. Gartner's Audit AI: A Practical Guide for CAEs, published 9 September 2026, is independent, non technical, practitioner side evidence that the internal audit profession names the identical need from its own side: it reports a gap between audit leaders who name AI governance a 2026 priority (83 percent) and those confident they can address it (34 percent), names limited visibility into deployed AI as the assurance risk underneath that gap, and recommends audit ready evidence generated during work rather than reconstructed afterward. That recommendation supports this property's own post hoc, not preventive framing without establishing that any specific construction satisfies it.
- Supports requirement
Agent Infrastructure Control Protocol (AICP)
Tihan-Nico Paxton, Apollo Deploy (individual submission to the IETF)
This weakness's own corrective principle keeps a decision record produced before execution separate from a log produced after it, and forbids treating prose as the control. AICP's own Section 5.5 states directly that a client must not treat prose as authorization, executable instructions, a replacement for a stable code, or a reason to violate a structured constraint, and Section 12.1 restates the same discipline for a Problem's own human readable detail member specifically, stating that a client bases retry and recovery decisions on the stable code and structured fields, not the prose. Section 11.3 extends the same separation to evidence itself: access to an Evidence Reference must be independently authorized and must not be granted merely because a client can read an Outcome. Recorded as design evidence for the requirement this weakness already states across its whole object model, 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 Auditability is built from four separate record classes rather than one undifferentiated log
This weakness's own corrective principle requires a decision record produced before execution to be kept separate from a log produced after it, and treats audit evidence and authorization as separate obligations. The draft's own four record classes are exactly that separation made structural rather than left to convention: an Action Record documents that a tool or service call took effect, and an Authorization Transition Record, a distinct class with its own ordered previous-state/new-state sequence, is what actually tracks whether that effect was authorized. Recorded as design evidence for the weakness's own principle, not as a claim that any implementation of this record model exists outside the draft's own 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 The draft states directly that this architecture is post-hoc auditing, not session management and not enforcement
This weakness names the confusion between an audit record and a pre-execution control directly: presenting an after-the-fact record as if it governed the decision leaves the actual decision ungoverned. Revision 01 of the draft states, in its own words, that the architecture it describes is post-hoc and is not a session or context-management mechanism, a first-party statement of exactly this weakness's own boundary rather than an implicit assumption a reader has to supply.
- Supports requirement
EP Authorization Receipts (EMILIA Protocol)
Iman Schrock, EMILIA Protocol, Inc., individual submission to the IETF
Requirement The draft states directly that a receipt is evidence, not authorization, and that it does not treat a local human interaction as an authorization decision
EMILIA states directly that a receipt is evidence, not authorization, and that the decision remains with the authorization server. That is the exact line this weakness says products blur when they present an audit archive as a control.
This record is the cited evidence for this relationship.
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 AEW-003 Execution authority collapsed into capability to prepare
- Supports requirement
Agent Infrastructure Control Protocol (AICP)
Tihan-Nico Paxton, Apollo Deploy (individual submission to the IETF)
Requirement Capability discovery is explicitly separated from an authorization grant
This weakness names the collapse of capability to prepare into authority to enact. AICP's own Section 6.3 states the corrective directly for the discovery stage specifically: a capability listing indicates discoverability, not a durable authorization grant, and policy is evaluated again when planning and immediately before execution. Section 4.2 restates the same boundary as a provider obligation, that authority must be derived from authenticated server side context rather than granted because a request body claims it. Recorded as design evidence for the requirement this weakness already states, not as a claim that any provider has implemented this draft's text.
- Reveals bypass
Slack Code, code channels and expert sign off for high stakes actions
Slack, a Salesforce company
Requirement Slack itself is the point at which the production decision is enforced
Slack Code carries a change to the edge of production and describes an expert sign off, but Slack is not the point at which the deployment is enforced, and no artifact binds the sign off to a refusal on the far side. The weakness names exactly that gap.
This record is the cited evidence for this relationship.