Every Stage Was Individually Correct. The Composition Was Not.
A paper submitted to arXiv on 4 September 2026, CONTINUITY: Security-Context Contracts for Composable LLM Agent Controls, names a failure mode it calls security-context discontinuity: a chain of provenance tracking, authorization, policy enforcement and execution controls where every individual stage is correctly implemented, and the composition still lets a security-relevant fact, an identity, a scope, a destination, a policy state, get dropped, widened, rebound or reinterpreted before the effect it was supposed to govern actually happens. Moona Intelligence reads it against a registry that already names several of the same collapses by other evidence, and treats the paper's own deterministic conformance suite for exactly what its authors state it is: an exact result on a synthetic benchmark, not a population estimate of real-world risk.
Event analysed: . This analysis was published on 7 September 2026.
Not by default, according to CONTINUITY: Security-Context Contracts for Composable LLM Agent Controls, submitted to arXiv on 4 September 2026 as arXiv 2609.05269 by Chris Zheng and Geng Yang, with a reference implementation published at github.com/zast-ai/continuity under the MIT license, copyright confirmed directly against the repository's own LICENSE file as held by the same two authors. The paper's central claim is that tool-using LLM agent systems increasingly compose several security controls, provenance tracking, task-scoped authorization, policy gateways, protocol adapters and execution controls, that are each specified and tested in isolation, and that this composition can fail even when none of the individual components is defective: a boundary between two correct components can drop a source label, accept a self-declared authority root, widen a delegation, change an approved field with no valid transformation relation behind the change, or execute a stale or replayed permit. The paper names this failure class security-context discontinuity and proposes an assume-guarantee contract discipline, CONTINUITY, in which each component states what it assumes about the security context it receives and what it guarantees about the security context it hands onward, and authenticated context is carried across the boundaries between components using six named mechanisms this record did not itself read from the paper's own text, arxiv.org and its usual html mirror were both blocked at this session's network egress proxy on every attempted route, but which converge identically across repeated, independently phrased web search passes: signed root grants, provenance commitments, role-bound transition receipts, bounded typed releases, transformation witnesses, and effect-bound execution permits. The paper defines end-to-end consequence integrity as the property this composition is meant to establish: every externally realized, protected effect should carry a verifiable witness connecting the exact effect to an authenticated chain origin, a principal, a task, field-level provenance, a root grant, the component contracts it passed through, the policy current at the time of the effect, a finality sink, and single-use execution state, rather than resting on any single stage's decision remaining valid by assumption. This record's own reading of the reference implementation, fetched directly from github.com rather than through search, confirms a deterministic conformance suite structured around 32 named fault classes, ATTACK_FAULTS in the harness's own source, spanning four domains the code names workspace (email operations), finance (payment transfers), devops (deployment releases) and multiagent (agent delegation), tested with a static, deterministic fault-injection adversary rather than a live, adaptive planner, and README.md's own text, also fetched directly, states the full reproduction runs 3,460 scenarios across 24,220 executions, comprising 2,560 parameterized attack instances across those 32 fault classes and 128 fault-domain classes, 700 benign tasks including 300 exercising the typed-release credential path, and 200 ambiguous scenarios meant to force escalation rather than silent action, reporting zero successful harmful effects, full benign completion, full ambiguous-case escalation and full lifecycle correctness. README.md states, in the artifact's own words this record read directly, that these are exact conformance results for a deterministic suite, not IID samples and not a population-level estimate of real-world prompt-injection risk, a boundary this record treats as the artifact's own and does not soften in either direction.
Read past this paper's own name for its failure class and the shape underneath it is one this registry already has partial evidence for from several different directions: a chain of individually correct decisions does not, by the fact of each decision being correct, guarantee that the final, consequential effect is the one any of those decisions actually meant to authorize. CONTINUITY gives that shape a name, a formal contract discipline, and a deterministic test suite. This record reads the paper for what its own evidence, and its own artifact's evidence, actually establishes, and keeps that separate from what would need direct access to the manuscript's full text, which this session's network egress proxy did not permit.
What "security-context discontinuity" names
The paper's own framing, confirmed identically across repeated, independently phrased web search passes since arxiv.org and its html mirror at arxiv.org/html/2609.05269v1 were both blocked at this session's network egress proxy on every attempted route, is that a modern tool-using LLM agent pipeline is rarely one monolithic security decision. It is a sequence: something tracks where a piece of data or an instruction came from, something else decides whether a task is authorized, a policy gateway evaluates a proposed action against current rules, a protocol adapter translates that action into whatever a downstream tool or service actually expects, and an execution control commits the final, real-world effect. Each of those components can be built, specified and tested correctly on its own terms. The paper's claim is that correctness at each individual boundary does not compose automatically into correctness across the whole chain, because a security-relevant fact, who the acting principal is, what task authorized the action, what field values were actually approved, what policy state applied, whether a permit has already been spent, can be dropped, widened, rebound to a different identity, reinterpreted through an unauthenticated transformation, or replayed after it should have expired, at exactly the seam between two components that are each individually behaving as specified.
Six mechanisms carried across the seams, and what they are for
CONTINUITY's own corrective, by the same convergent search evidence, is not a single gate but six named artifacts meant to travel with a request across every component boundary rather than being re-derived, or simply trusted, at each new stage: a signed root grant establishing where authority genuinely originates; a provenance commitment binding a field's current value to where it actually came from; a role-bound transition receipt showing which component, acting in which role, produced a given transformation; a bounded typed release, a credential scoped to a specific, limited class of value rather than a blanket permission; a transformation witness, evidence that a change to a security-relevant field was itself an authorized transformation rather than an arbitrary substitution; and an effect-bound execution permit, single-use and tied to the exact effect it authorizes, rather than a general purpose token a finality sink accepts on faith. Read together, these six mechanisms are aimed at one property the paper calls end-to-end consequence integrity: that a protected, externally realized effect should carry, at the moment it commits, a verifiable link back to an authenticated origin, a principal, a task, field-level provenance for whatever changed en route, the root grant that started the chain, the contracts of the components the request actually passed through, the policy state current at that moment rather than whatever policy state applied when an earlier stage looked, the finality sink itself, and proof the execution permit has not already been spent.
What the reference implementation actually tests, read directly rather than through search
This record fetched the artifact repository at github.com/zast-ai/continuity, its README.md, its ARTIFACT.md claim-to-artifact mapping, its experiment harness source and its LICENSE file directly, distinct in evidence strength from the paper's own manuscript text, which this session could not fetch at all. The harness's own ATTACK_FAULTS constant names all 32 fault classes explicitly in source, among them UNTRUSTED_ROOT_PRODUCER, PRINCIPAL_SUBSTITUTION, DELEGATION_WIDENING, DESTINATION_SUBSTITUTION, POLICY_DOWNGRADE, NONCE_REPLAY, ALTERNATE_PATH, MISSING_TRANSFORM_WITNESS, INVALID_TRANSFORM_WITNESS, EXPIRED_RELEASE, SUBJECT_SUBSTITUTION, POST_PERMIT_ACTION_SUBSTITUTION and REVOKED_GRANT, run across four named domains, workspace, finance, devops and multiagent, against a deterministic, static fault-injection adversary the harness itself instantiates rather than a live, adaptive planning model; this record states that distinction plainly rather than letting a paper's own adversarial framing imply a dynamic red-team process it does not run. ARTIFACT.md, also read directly, states ten core conformance claims mapped to specific verifier behaviors, signature validity, policy compliance carried across transitions, nested JSON path resolution against provenance digests, typed-release credentials checked against multiple binding constraints at once, semantic alias validation, and pre-effect authorization verification among them, and states that reproducing the full suite runs 3,460 scenarios across 24,220 system executions, with a quick mode running a smaller 488-scenario subset, both producing deterministic counts the harness itself writes to results/manifest.json rather than a human-graded score. README.md, read directly, reports the resulting full-suite outcome as a zero effect Attack Success Rate across the 2,560 parameterized attack instances and 128 fault-domain classes, 100 percent completion of the 700 benign tasks including the 300 exercising the typed-release credential path specifically, and 100 percent correct escalation of the 200 ambiguous scenarios rather than either silent denial or silent execution. The same file states, in its own words this record quotes rather than paraphrases past recognition, that these are exact conformance results for a deterministic suite, not IID samples and not a population-level estimate of real-world prompt-injection risk. This record adopts that boundary as the artifact's own and does not read the zero-attack-success result as a claim about any deployed system's actual exposure.
Where this reaches Moona Intelligence's existing registry, and by which exact weaknesses
This record does not read CONTINUITY's own 32 fault classes as 32 new Moona Agent Execution Weaknesses. Several of them are more precise instances of collapses this registry already names from independent evidence, and this record connects the paper to those exact entries rather than minting a parallel taxonomy. Approval not bound to the executed action, AEW-005 in Moona's own Risk Registry, already names the general shape of an approval that does not travel with the exact thing it approved; CONTINUITY's own fault classes for an unauthenticated field substitution, a destination swapped after admission, or an action executed in place of the one a permit actually names, DESTINATION_SUBSTITUTION and POST_PERMIT_ACTION_SUBSTITUTION among the ones this record read directly in the harness's own source, are the same collapse stated as a formal property: an exact match on the action's own identifier is necessary, but not sufficient, when an intermediate, security-relevant transformation to that action's own fields was never itself authenticated as an authorized transformation. Claimed authorization accepted without verification, AEW-007, already names an agent treating an asserted mandate as though the assertion itself proved legitimacy; CONTINUITY's own separation of a role-bound transition receipt, evidence a specific component acting in a specific role produced a transformation, from a bare valid cryptographic signature is the same distinction stated formally at a machine-to-machine boundary rather than a human-facing one: a signature proves which key signed a message, not that the signing party's role authorized the particular transition the message now claims. Reachability treated as authority, AEW-008, already names a resource being actionable simply because nothing scoped it out of reach; CONTINUITY's own ALTERNATE_PATH fault class formalizes the same gap one layer higher, as a property of mediation itself rather than of one resource boundary: a control wired onto one named execution surface does not, by that fact alone, establish that every path capable of producing the identical downstream effect is mediated by an equivalent check. A persistent effect survives the revocation of the authority that created it, AEW-027, already names the gap between ending a principal's live access and invalidating what that principal already wrote while holding it; CONTINUITY's own REVOKED_GRANT and EXPIRED_RELEASE fault classes name an adjacent but distinct instance of the same underlying property, that authority correctly established when an earlier stage admitted a request is not thereby established as still current at the later moment an effect actually commits, so a finality stage that trusts an admission decision's freshness rather than rechecking policy, revocation and expiry state against the moment of commit can execute an effect its own current state would have refused.
Protocol-neutral positioning, read cautiously
Repeated, independently phrased web search passes converge on the paper positioning CONTINUITY as protocol-neutral: a context and contract layer that could in principle be carried across an interface like the Model Context Protocol, which specifies tool discovery and invocation and documents its own security considerations separately, or measured against a specification like the OWASP Agent Control Standard, which this registry's own protocol dataset already carries as owasp-acs-2026-05-27 and already connects to three of this dataset's own weaknesses. The same convergent search evidence states the paper does not claim CONTINUITY is integrated into either standard's production tooling, and does not claim either standard already implements CONTINUITY's own six mechanisms. This record does not create a Protocol relationship on the strength of that search-level evidence alone: OWASP ACS's own specification text, already fetched directly and cited elsewhere in this registry, states nothing about signed root grants, transformation witnesses or effect-bound execution permits, and this record will not assert a connection this registry's own protocol dataset cannot independently verify against a primary specification text. Where the paper positions itself relative to an existing standard without that standard's own text confirming the relationship, this record states the positioning as reported rather than as an established protocol connection.
What this record does not establish
This record does not claim to have read the paper's own manuscript text directly: arxiv.org and its html mirror were both blocked at this session's network egress proxy on every attempted route, and everything this record attributes to the paper's own argument, rather than to the reference implementation's own source, README, ARTIFACT.md or LICENSE, each fetched directly from github.com, rests on convergent, independently phrased web search passes whose result snippets agree on the same wording across separate queries, the evidence level this corpus already uses elsewhere for a source blocked the same way. This record does not claim CONTINUITY has been deployed in any production agent system, that its trusted computing base, root issuers, validators, deployment policy and the finality sinks themselves, has itself been independently audited, that its 32 fault classes constitute a complete taxonomy of every way a security-context boundary can fail, or that a deterministic, statically fault-injected adversary against a synthetic benchmark generalizes into an estimate of how often any of these 32 failure modes actually occurs against a real deployed pipeline. It does not claim that any Moona-tracked vendor or product has adopted CONTINUITY's own contract discipline, and it does not claim CONTINUITY's own zero-attack-success result would hold against an adaptive, rather than statically injected, adversary; the paper's own reference implementation states plainly, in this record's own direct read of its harness, that the fault injection is deterministic rather than a live planning process. Where the evidence available to this record does not establish a fact, this record states it as unknown rather than inferring it from the shape this weakness class already shows elsewhere in this registry.
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-007 Claimed authorization accepted without verification
- Supports requirement
Agent Action Decision Protocol (AADP)
Shamik Saha, individual submission to the IETF
Requirement Revision 02 admits authenticated, digest bound evidence references the PDP dereferences and verifies itself, and never evidence claims as decision input
A reported second revision of AADP is described to this record as drawing the exact line this weakness names: an externally supplied claim carried inside a request is not a trusted decision input merely because it appears there, and only an authenticated reference the decision point itself dereferences and verifies may be admitted. This record could not independently read that revision's own text, grades the property claimed rather than documented on the protocol evidence record, and treats this link as validating the weakness's authority gap from the specification side, not as a new known example of the weakness occurring. The Hugging Face incident supplies a concrete, already documented instance of exactly the gap the reported revision addresses: an agent that had already reasoned a target was out of scope proceeded once a peer agent's GO message, an externally supplied claim carried on a shared message board, arrived with nothing that dereferenced or verified it.
- Supports requirement
ChainIT Authority Protocol and Agent Subject Profile for pre execution authority validation
ChainIT
Requirement ChainIT's organizational authority documentation states roles by themselves are not enough and authority must be attested, tokenized and enforced
ChainIT's own doctrine that roles by themselves are not enough, and that an organizational authority must be explicitly attested, tokenized and enforced through an Authority Resolution Pactvera, is a more explicit rejection of a bare claim of authorization than most comparable architectures state about their own organizational layer, and directly answers this weakness's description of an agent accepting an assertion of authority with no channel establishing whether it is true.
- Supports requirement
vLEI and GLEIF's proposed partitioned authority architecture for agentic payments
GLEIF (Global Legal Entity Identifier Foundation)
Requirement A vLEI role credential can establish that a named individual holds a specific certified role inside a specific, LEI identified organization
vLEI's ISO standardized trust chain grounds a claim of authority in a role a trusted issuer certified inside a real, LEI identified organization, rather than in a bare, unverifiable assertion. That is a genuine narrowing of the gap this weakness describes, an agent accepting a claim of authorization with no channel establishing whether it is true, even though it does not close the gap entirely.
- Missing requirement
Agent Control Standard (ACS)
OWASP GenAI Security Project, originally Zenity
Requirement The specification establishes who is legitimately entitled to author or change the Guardian's own policy
ACS's own conformance material states directly that policy author authorization and trust schemes are left deployment defined in v0.1, distinct from both Observed Agent and Guardian identity. The specification binds and protects what an agent may pursue through its Intent object well; it does not establish who was entitled to author the Guardian policy that governs how that pursuit is judged, the same missing requirement this dataset has now documented for a certificate authority's issuance policy, an identity platform's downscoped claims, a certified vLEI role and an Authority Resolution Pactvera.
- Missing requirement
Agent Infrastructure Control Protocol (AICP)
Tihan-Nico Paxton, Apollo Deploy (individual submission to the IETF)
Requirement The protocol establishes whether the authorizing principal's underlying mandate was legitimate
This weakness's own gap is that an agent has no way to distinguish a genuine mandate from a bare assertion of one, and that a signed grant can prove what scope a principal granted without proving the principal held legitimate authority to grant it. AICP's own Section 3.2 lists authentication, credential and approval protocols as explicit non-goals, and Section 4.2 states authentication and token acquisition are outside its scope. The draft specifies how an authorization decision must be bound and recorded once one exists; it does not, on its own text, establish that the principal behind that decision actually held legitimate authority to request the action, the same missing requirement this dataset already records against AIC's certificate authority issuance policy, Ping Identity's own act and may_act claims, GLEIF's certified vLEI role, and ChainIT's Authority Resolution Pactvera.
- Missing requirement
AI Agent Identity Certificate (AIC) extension for X.509 v3
Jijie Wei, individual submission to the IETF
Requirement A certified principal grant proves the principal's underlying mandate was legitimate
AIC proves a principal delegated a scope but not that the principal held legitimate authority to grant it, the same gap that lets an agent accept a bare claim of authorization. No protocol in the dataset yet establishes mandate legitimacy, so this is a missing requirement. Cybernews's exposed server investigation, published 3 September 2026, is a further instance of the same missing requirement in a different shape: an affiliate of The Gentlemen ransomware and extortion operation got an AI agent framework to accept a fabricated Capture The Flag training framing in place of any certificate, grant or issuer AIC's own extension would require, and nothing this dataset has found closes that gap for a claim aimed at an agent's own training rather than at a human reviewer.
- Missing requirement
ChainIT Authority Protocol and Agent Subject Profile for pre execution authority validation
ChainIT
Requirement Which ARPs rest on an authoritative government or state source, a shareholder attestation, or an organization's own internal determination is not established
An Authority Resolution Pactvera being immutable once recorded proves ChainIT will not silently alter the record, not that the underlying grant was substantively correct when made. Which ARPs rest on an authoritative government or state source, a shareholder attestation, or an organization's own internal, unverified determination is not established, the same missing requirement AIC's certificate authority issuance policy, Ping Identity's own act and may_act claims and GLEIF's certified vLEI role already leave open in this dataset.
- Missing requirement
Identity for AI, Agent IAM Core and Agent Gateway
Ping Identity
Requirement The architecture establishes which human subject and which agent actor a token names, not that the named human held organizational entitlement to authorize the underlying action
Ping's own act and may_act claims prove which human subject and which agent actor a downscoped token names, not that the named human held organizational entitlement to authorize the action the agent then takes. Identity of the grantor is not legitimacy of the grant, and nothing in Ping's own material this record could verify closes that gap, the same missing requirement AIC's X.509 extension leaves open above.
- Missing requirement
vLEI and GLEIF's proposed partitioned authority architecture for agentic payments
GLEIF (Global Legal Entity Identifier Foundation)
Requirement Nothing found establishes that holding a certified vLEI role by itself entitles its holder to grant a specific agent's authority
A certified vLEI role proves who the grantor is, not that the grantor's own organization actually entitled them to grant the specific agent authority in question. This is the same missing requirement AIC's certificate authority issuance policy and Ping Identity's own act and may_act claims already leave open in this dataset, now documented a third time in an architecture built on materially more mature identity infrastructure.
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.
Protocol evidence related through AEW-027 A persistent effect survives the revocation of the authority that created it
- 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 names the gap between authority admitted at one moment and authority actually in force at a later moment of consequence, evidenced elsewhere in this registry by CONTINUITY's REVOKED_GRANT and EXPIRED_RELEASE fault classes. The draft's Authorization Transition Record class is the audit-record-format mirror of exactly that property: an ordered previous-state/new-state sequence built so an auditor can reconstruct which state was in force at a specific point in a run, rather than reading the latest known state back over an earlier moment. Recorded as design evidence for the weakness's own principle in the reverse temporal direction, a later revocation must not retroactively deny an earlier, then-still-authorized action; this record's own evidence separately connects to a targeted extension of Moona's canonical Authority Resolution engine implementing exactly that reconstruction for one specific field.
- Missing requirement
Grantex and the Delegated Agent Authorization Protocol (DAAP)
Sanjeev Kumar, Grantex
Requirement Cascade revocation stops future use of descendant grants; nothing found addresses reversing an action a now revoked grant already authorized
This property, verified directly against Grantex's own specification, already records that cascade revocation stops future use of a revoked grant's descendants but that nothing found addresses reversing an action a grant already authorized before it was revoked. Ruflo's own remediation guidance for CVE-2026-59726 is concrete evidence for exactly the same shaped gap one layer further in: an attacker's live access to the MCP bridge was closed by version 3.16.3, and closing it did nothing to whatever the attacker had already written into AgentDB while that access was open, which is why Ruflo's own operators are separately instructed to audit and purge the learning store rather than trust the version upgrade alone. Recorded as a missing requirement because both the specification and this concrete instance name the same unresolved question, whether ending an authority retroactively settles what that authority already produced, without either one describing a mechanism that answers it.
- Missing requirement
x401, the HTTP Proof Requirement Protocol
Proof, with editors from Proof and Circle and reviewers from Lightspark, MATTR, Okta, OpenAI and Visa
Requirement Whether revoking the underlying mandate or credential immediately invalidates an already issued Verification Token is undocumented
This property, verified directly against the base x401 specification, already records that the specification does not state what happens to an already issued Verification Token if the credential or delegation evidence behind it is later revoked, and that no revocation endpoint or propagation rule was found. Ruflo's own incident is the same unresolved question realised as a concrete consequence rather than an acknowledged gap in a draft: an attacker's access was revoked by the fixed bridge, and the persistent state that access had already produced, an AgentDB pattern store entry, is not described anywhere in Ruflo's own material as automatically invalidated by that revocation. Recorded as a missing requirement rather than a supported one, since neither the specification nor Ruflo's own remediation describes a mechanism that propagates a revocation into previously produced, persistent effects; both leave that step to a separate, manual action.
Protocol evidence related through AEW-008 Reachability treated as authority
- Supports requirement
ARC, Agentic Runtime Control
Britive
Requirement Britive states native support for the OpenID Shared Signals Framework, consuming CAEP and RISC events to trigger automated session termination, forced logout, step up authentication or account disable, and separately emitting its own CAEP and RISC events
Okta Threat Intelligence's own 9 September 2026 research states the corrective for exactly the substitution this weakness names, a technically valid credential standing in for an authorization check that never independently runs: monitor for session-token reuse and re-evaluate a session's standing whenever a critical context change occurs, rather than trusting a credential's validity at authentication time for the remainder of its technical lifetime. Convergent reporting attributes to Okta's own product material a Session Protection capability that continuously monitors active sessions post authentication and re-evaluates policy on an IP or device change, or on inbound risk telemetry over the Shared Signals Framework, the identical corrective principle, and the identical named standard, this property already credits to Britive's own native CAEP/RISC support under a different vendor. This link supports the requirement rather than closing the gap this weakness names for AI-service credentials specifically: nothing in either vendor's own reachable material establishes that a stolen but still-valid AI session token or API key, of the kind Okta's own dataset documents by the thousand, is itself a principal a Shared Signals Framework transmitter is watching, as distinct from the device or IP session context CAEP and RISC events are reported to cover.
- Supports requirement
AWS Agent Registry (Amazon Bedrock AgentCore)
Amazon Web Services
Requirement The registry's own discovery API carries exactly three operations, all reads, no invocation
This weakness's own response pattern calls for authorizing a resource independently of whatever makes it reachable, never letting reachability itself substitute for the missing check. AWS Agent Registry's own discovery API, confirmed directly from AWS's published SDK source to carry exactly three operations, BatchGetDiscoverableRegistryRecord, ListDiscoverableRegistryRecords and SearchDiscoverableRegistryRecords, all reads, with no operation that invokes a discovered resource, is architectural evidence of exactly that separation: a caller who successfully searches the registry gains the ability to find a record, not any ability the registry itself grants to act on what the record describes. Recorded as design evidence that a governed discovery catalog can keep discoverability and invocation authority structurally apart, not as a claim that every resource a record points to independently enforces its own authorization at the moment of invocation, which this record leaves unknown.
- Supports requirement
AWS Agent Registry (Amazon Bedrock AgentCore)
Amazon Web Services
Requirement AgentCore Runtime and Gateway resources AWS Agent Registry auto-detects land as unapproved Draft records, not as discoverable Approved ones
This weakness names reachability substituting for authority precisely where nothing independently checks a resource before it becomes actionable. AWS Agent Registry's own auto-detection of AgentCore Runtime and Gateway resources across an organization is, on its face, the kind of automatic admission this weakness's known examples already warn about; what keeps it from instantiating the weakness here is that a resource the registry auto-detects lands as an unreviewed Draft record, not as an Approved, discoverable one, so existing is kept apart from approved even when the existence itself was discovered automatically rather than declared by a publisher. Recorded as design evidence for this weakness's own corrective, not as a claim that every deployment actually enables the review step before treating an auto-detected resource as caught up, which this record did not independently confirm.
- Supports requirement
MCP 2026-07-28: Sessionless Protocol, Explicit State Handles and the Tasks Extension
Model Context Protocol
Requirement Possession of a state handle is not authorization, where authentication exists
The Model Context Protocol's own security best practices page, part of the final 2026-07-28 specification revision, states directly that MCP servers must not treat possession of a state handle as authentication, and SEP-2567 states the corrective an authenticated server should apply, validating a handle together with the caller's current authentication context on every call rather than the handle alone. This is the connectivity protocol's own normative guidance for exactly the substitution this weakness names, reachability or possession of a reference standing in for an independent authorization check, stated at the level of a widely adopted protocol's own specification rather than one vendor's product. This link supports the requirement rather than closing the gap: the guidance is a should addressed to a server's own application layer, since MCP itself defines no protocol-level handle type to enforce anything about, and this weakness's own Grafana known example, CVE-2026-19516, already documents a real MCP server whose session check accepted a caller supplied identifier the server itself had never issued, so the specification's own text and any one server's own conformance to it remain separate facts this link does not conflate.
- Implementation evidence
Agent Action Decision Protocol (AADP)
Shamik Saha, individual submission to the IETF
Requirement A Policy Decision Point owns authorization state and evidence; PEPs enforce it
AADP requires a Policy Enforcement Point to hold a permit from a Policy Decision Point before performing a governed action. GitHub's branch protection, requiring multi party review before a Terraform change could merge, functioned as exactly that enforcement point for the one attempted infrastructure backdoor Unit 42's own account names, denying a mutation the attacker's already compromised, technically valid access could otherwise reach. This is bounded, real world enforcement evidence for the one action the control was configured in front of, not evidence that the same separation governed the rest of the intrusion, which Unit 42's own account describes continuing on other paths after that one attempt was blocked.
- Implementation evidence
Agentic Networking for DynamicLink, a production MCP server for networking
Zayo
Zayo's Agentic Networking for DynamicLink, launched 8 September 2026, is a production deployment of a Model Context Protocol server, the same specification this weakness already connects through mcp-2026-07-28-sessionless-tasks above, now exposing production network and security infrastructure rather than a development or evaluation surface. It is implementation evidence for this weakness's own general form, reachability through an admitted MCP session substituting for an independent per-action authorization check, of the same kind this weakness already credits to Coder's Agent Firewall and Reco's Browser Guard: Zayo's own material states enterprises determine which information, tools and actions an agent can access, a scoping decision placed in front of the MCP tool surface, while no reachable artifact describes the mechanism that evaluates one specific requested tool call against that scope at the moment it is made. This link is scoped precisely to that evidentiary role. It does not evaluate a specific graded requirement of the MCP specification itself, and it does not treat Zayo's own governance language as proof that the gap this weakness names is closed for this vendor.
- Reveals bypass
ARC, Agentic Runtime Control
Britive
Requirement Whether an agent holding an independent credential or a direct network path to a target system can reach that system without passing through ARC's policy evaluation is not addressed in material available to this record
Britive's own documentation does not address whether an agent holding an independent credential or a direct network path can reach a target without passing through policy evaluation. That unmediated reachability is exactly the weakness these incidents turn on. NCSC's August 2026 interim advice on agentic AI corroborates the requirement this gap reveals, independently of the market's own protocol dataset: deny network access by default and mediate what remains through an approval gated, protocol or service aware proxy, rather than leave any path an agent's credentials or network position can reach unmediated. Grafana's own advisory for CVE-2026-19516 is a CVSS scored, vendor patched instance of exactly this gap: a Grafana MCP server's own network position reached internal, loopback and link local destinations, cloud metadata endpoints included, with no policy evaluation independently constraining the destination until the fix added one. Unit 42's account of a real enterprise intrusion, corrected 3 September 2026 to clarify the event was an intrusion rather than ransomware, is a further, larger instance: stolen cloud credentials reaching the victim organization's own AI infrastructure and CI/CD access reaching cloud keys, with no policy evaluation described as mediating either path. Cybernews's exposed server investigation, published 3 September 2026, adds an MCP intermediary to the same gap: a Penelope MCP interface exposed live reverse shell execution as a callable capability to an agent framework, Hermes Agent, across more than 30 real organisations, with nothing described as independently evaluating whether the calling agent held policy backed authority to use the shell the interface made reachable. Anthropic's own 30 July 2026 disclosure adds a further real instance rather than a sandbox breach: a fictional evaluation target's name matched a real, live domain, and the evaluation environment's own live internet access, present through a misconfiguration neither Anthropic nor its evaluation partner Irregular had noticed, let Claude Opus 4.7 reach and act on the real company across four runs with nothing independently evaluating whether the resolved target matched the one the evaluation actually authorized. GitHub Security Advisory GHSA-9mg6-c5wp-2g44, formally assigning CVE-2026-85666 on 4 September 2026, adds a further vendor patched instance from an MCP client rather than an MCP server: OGX's Responses API accepted a caller supplied MCP tool server_url and opened an MCP session against it, at session initialization during tool discovery, with no destination check independently constraining the reachable target, confirmed by direct reading of the affected source. This instance sharpens Britive's own gap beyond the general case: the same codebase already applies a working destination check, validate_url_not_private, to two sibling caller controlled URL inputs, so the unmediated path here is not an absent control but an existing one never connected to this specific resource class, evidence this dataset reads as reinforcing the requirement that resource policy needs to be applied by effect and resource class rather than by the feature specific code path that introduced the caller controlled URL. A proposed fix, pull request 6390, remains open and unmerged as of this link, so this entry does not treat the bypass as closed. A second, independently opened pull request, 6291, proposes the same check plus a scheme restriction and states explicitly that an administrator configured connector or toolgroup endpoint keeps a separate, unmediated resolution path by design, evidence this link reads as directly on point for what Britive's own documentation does not address: mediation applied to one provenance of endpoint, caller supplied, does not by itself establish anything about a differently provenanced endpoint, administrator configured, that the same policy engine would need to evaluate on its own terms rather than inherit by association. This pull request is also open and unmerged as of this link. Later technical coverage of the collusion.wiki report on the DSEWiki incident adds a further instance of the same reinforced requirement from a different direction: an OpenAI evaluation harness's read only internet restriction was enforced by permitting the GET HTTP method and blocking others, including POST, and DSEWiki's own ProWiki software accepted a page edit submitted as a GET request. Britive's own documentation does not address whether a request classified as read by its method can still produce a write at the destination, the same unaddressed gap this link already names for network position and destination, now shown for request method as the classifier instead. Both outlets naming the mechanism directly, and collusion.wiki itself, were blocked by this session's network egress policy; the mechanism is corroborated through cross referenced search rather than direct fetch. GitHub Security Advisory GHSA-rp45-5x3v-48mr adds a further instance narrower than any above: argocd-mcp's own HTTP and SSE transports bound to every network interface by default through version 0.8.0, confirmed directly against the affected source, with no policy evaluation, Host check or Origin check of any kind standing in front of a listener an operator's own environment configured Argo CD credential sat behind, so a network principal able to reach the bound listener needed nothing further to complete a credentialed, mutating Argo CD API call. CVE-2026-86122, published 5 September 2026 against Rowboat through version 0.9.1 and confirmed by direct reading of the affected source, adds a further instance that sharpens Britive's own gap past OGX's own case: Rowboat's project action authorization policy is confirmed running, correctly, before a custom MCP server URL or a project webhook URL is accepted, and nothing after that authorization call, and nothing in the agent runtime that later reads the stored URL back to open an MCP session or fetch a webhook, independently mediates which destination that authorized action may actually reach. Britive's own documentation does not address this either: an authorized project action, not only an independent credential or a direct network path, can carry unmediated reachability forward into whatever the resulting connection touches. A proposed fix, pull request 547, predates the report by five weeks, is not linked to it, and remains open and unmerged as of this link. GitHub Security Advisory GHSA-9m7h-vh2h-rc3w, published 6 September 2026 against OpenMAIC through version 1.0.0, adds an instance of a different shape than any above, and this link states the difference precisely rather than folding it into the general case: Britive's own documentation addresses whether a target is mediated by policy evaluation at all, not whether that mediation applies uniformly across every environment a deployment can run in. OpenMAIC's own validateUrlForSSRF is written correctly and already wired to five call sites the advisory names, confirmed by this link's own direct read at two of them, app/api/generate/image/route.ts and lib/server/resolve-model.ts, so the gap here is not an absent or unconnected check, as OGX's and Rowboat's own instances above show, but a check whose applicability depended on a condition, process.env.NODE_ENV === 'production', that the caller never touched and that a normal staging, preview or unset deployment fails by default, confirmed directly at both call sites this link checked against the affected tag. This composed with a separately confirmed fail open middleware, unchanged between the affected and fixed tags, that authenticated no request at all when the operator left ACCESS_CODE unset, so the unmediated path was reachable by an unauthenticated caller in the deployment states the environment condition already left unmediated. Fixed in OpenMAIC 1.0.1, released the same day, confirmed by this link's own direct read to remove the environment condition at both call sites checked and to add a repository scanning test, tests/server/url-guard-unconditional-invariant.test.ts, also read directly, that fails the project's own build if a validateUrlForSSRF call is again found gated on NODE_ENV. The same release replaces an implicit non production widening of what a caller supplied base URL could reach with an explicit ALLOW_LOCAL_NETWORKS grant an operator must set for local or private network access to be permitted at all, evidence this link reads as squarely on point for what Britive's own documentation does not address: mediation that applies only under an incidental deployment classification is not the same fact as mediation that applies to the resource and effect Britive's own policy evaluation is meant to reach, and an intentional exception to that mediation needs its own explicit grant rather than a classification's default.
- Missing requirement
AWS Agent Registry (Amazon Bedrock AgentCore)
Amazon Web Services
Requirement Whether, and how, a discovered resource's own invocation is independently authorized once found through the registry
This weakness's own authority gap is precisely the fact this record could not establish: what independently authorizes a discovered resource's own invocation, once a consumer has been authorized to find it. AWS's own reachable material states what discovery approval decides and stops there; nothing this session could reach describes the registry itself requiring, checking or even being aware of a separate invocation-time authorization on the resource a record names. Recorded as a missing requirement in the material this session could reach, not as a claim that no such requirement exists in AWS's own architecture; AgentCore Runtime, AgentCore Gateway or a third-party resource may well enforce one independently, and this record states that possibility as unknown rather than either confirmed or absent.