Argo CD Knew Who the Server Was. It Still Did Not Know Who Asked the Server to Act.
argoproj-labs/mcp-for-argocd 0.8.0 could accept an MCP tool call over its HTTP transport from any network reachable caller, present no requirement that the caller hold anything at all, and still complete the call against Argo CD's own API, authenticated as the operator's own configured ARGOCD_API_TOKEN. Argo CD's own authentication and RBAC evaluated that token honestly. Nothing upstream of the tool call had ever evaluated the caller. Fixed in 0.9.0, which binds to loopback by default and adds a separate inbound bearer credential an operator must set before widening that bind, a shared secret rather than a per caller identity.
Event analysed: . This analysis was published on 6 September 2026.
The server's own, standing in for authority the caller never held or presented. GitHub Security Advisory GHSA-rp45-5x3v-48mr, published by argoproj-labs on 11 August 2026 against argocd-mcp, the Model Context Protocol server for Argo CD, states that versions through 0.8.0 start their HTTP and SSE transports on every network interface and, in the advisory's own words, accept the environment token when the request contains no token, letting an unauthenticated network caller invoke tools including application creation and sync, executed with the credentials the operator configured. This record read the affected source directly at the 0.8.0 tag. Both transports call Express's listen with no host argument, which binds every interface by default. The credential check gating a request, resolveCredentials, requires that some token be available from one of three sources, a caller supplied x-argocd-api-token header, the operator's own ARGOCD_API_TOKEN environment variable, or a configured token registry, and rejects a request only when none of the three resolves to anything at all. In the deployment shape the project itself documents as ordinary, an operator setting ARGOCD_API_TOKEN so the server can reach Argo CD, that check is satisfied by the environment variable alone, regardless of what the request itself presented. A request supplying nothing passes exactly as one supplying a valid caller token would. The token that then reaches Argo CD, read directly from the HTTP client class the server's own ArgoCDClient wraps, is built from an apiToken constructor parameter traced back to serverInfo.argocdApiToken, the operator's configured ARGOCD_API_TOKEN, attached as an ordinary Bearer Authorization header on every outbound request the tool call produces. Argo CD's own authentication and RBAC then evaluate that header honestly, because it is a genuine, validly issued Argo CD token. What Argo CD never had the opportunity to evaluate, because nothing upstream of it ever asked the question, is who or what actually made the call. This record could not verify the specific CVE and GHSA identifiers named in the brief commissioning it. CVE-2026-82456 returned no NVD record in search and no confirmation from any CVE authority reachable in this session. GHSA-p2x5-x87w-v2xj returns a genuine 404 both on the repository's own advisory path and on GitHub's general advisories mirror. The repository's own security advisories page lists exactly one advisory covering this vulnerability, GHSA-rp45-5x3v-48mr, which this record uses instead, and which itself states no CVE is currently known. Every other technical claim in the commissioning brief, the affected and fixed versions, the fixing commit, the transport and credential mechanism, and the 0.9.0 remediation, matched what this record independently confirmed against the project's own source.
Read argocd-mcp's own fix for this vulnerability and one design decision explains almost everything that went wrong before it: the check that was supposed to stand between a network caller and Argo CD's own API asked whether a token was available anywhere the server knew to look, not whether the caller in front of it had presented one. An operator's own configured credential, present so the server could reach Argo CD at all, was one of the places the check looked. It was also, absent anything from the caller, the only place it needed to look.
What argocd-mcp actually does
argocd-mcp is argoproj-labs's own Model Context Protocol server for Argo CD, the continuous delivery tool that manages what a Kubernetes cluster runs by reconciling it against a Git repository. Running the server lets an MCP client, an agent or an operator's own tooling, call tools that read Argo CD's state, applications, clusters, managed resources, workload logs and events, and, when the server is started in write mode, tools that change it: creating, updating, syncing and deleting Argo CD Applications, and running resource level actions Argo CD itself exposes. The server needs its own credential to talk to Argo CD, ARGOCD_API_TOKEN, because Argo CD's own API requires one. That is an entirely ordinary shape for an intermediary to take.
The check that answered the wrong question
The vulnerability sits in what the server's own HTTP and SSE transports did before creating an MCP session for an incoming request. This record read src/server/transport.ts directly at the 0.8.0 tag. Both transports call Express's own app.listen with no host argument, which binds the listener to every available network interface by default, a fact the fixing commit's own change confirms by name: it introduces a DEFAULT_BIND_ADDRESS constant set to loopback, replacing whatever the previous, unstated default actually was. Before a session begins, a function this record read directly, resolveCredentials, checks whether an Argo CD API token is available from any of three places: a caller supplied x-argocd-api-token request header, the ARGOCD_API_TOKEN environment variable the operator configured for the server's own use, or a token registry mapping multiple Argo CD instances to their own tokens. The check's own rejection path, read directly from the source, fires only when none of the three produces anything: its message states plainly that the header, the environment variable, or a configured registry must supply a token, with no distinction drawn between where that token came from.
Tracing one consequential call end to end
This record traced sync_application, one of the mutating tools the server registers only when started in write mode, from its MCP registration through to the Argo CD API request it produces, reading src/server/server.ts, src/argocd/client.ts and src/argocd/http.ts directly at the 0.8.0 tag rather than inferring the path from the advisory's own prose. The tool resolves an ArgoCDClient, either the server's own default instance, built once at startup as new ArgoCDClient(serverInfo.argocdBaseUrl, serverInfo.argocdApiToken), or a per request instance built from a caller supplied base URL paired only with a token the request itself or a configured registry actually supplied, a pairing rule the source enforces specifically to stop a caller directed base URL from ever being paired with the server's own default token. Absent a caller supplied base URL, the request reaches the default client, carrying serverInfo.argocdApiToken, which this record confirmed traces to the operator's own ARGOCD_API_TOKEN. ArgoCDClient's syncApplication method calls through to an HttpClient instance whose constructor takes that same apiToken and builds every outbound request's headers as Authorization: Bearer followed by it. The resulting request, a POST against Argo CD's own /api/v1/applications/{name}/sync endpoint, carries the operator's configured credential regardless of what, if anything, the original MCP request carried. Argo CD receives a request bearing its own, genuinely valid token and authenticates and authorizes it exactly as it would any other request presenting that same token, because from Argo CD's own position, that is precisely what the request is.
The same trace applies to create_application, update_application and delete_application, the write mode tools this record confirmed registered in src/server/server.ts alongside sync_application and run_resource_action, each wired to the corresponding ArgoCDClient method and each reaching Argo CD through the identical default client construction when a request supplies no caller specific base URL and token of its own. This record does not extend the finding past the Argo CD Application and resource action surface the server itself exposes: what a created or synced Argo CD Application is then permitted to deploy into a cluster is a further question Argo CD's own project scoping and RBAC decide, on evidence this record did not independently verify for any specific deployment, and this record does not claim a specific Kubernetes level effect beyond the Argo CD API calls it confirmed directly.
What the advisory states and what this record independently confirmed
GitHub Security Advisory GHSA-rp45-5x3v-48mr, published 11 August 2026, rates the vulnerability CVSS 3.1 base 10.0, Critical, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, under three CWEs: CWE-306, Missing Authentication for Critical Function, CWE-346, Origin Validation Error, and CWE-1327, Binding to an Unrestricted IP Address. Its own description states that the server starts its HTTP transport on every network interface and accepts the environment token when the request contains no token, that an attacker can exploit this to create and execute malicious Argo CD Applications using the stored credential, and that the server lacked both Origin and Host validation, which the advisory names as enabling DNS rebinding against a listener bound to every interface. Affected versions run through 0.8.0; the advisory names 0.9.0 as the patched release. This record's own reading of the source at both tags confirms every one of these claims independently rather than repeating the advisory's own prose: the all interfaces bind, the credential check's own indifference to the request's own contents, the absence of any Host or Origin check in 0.8.0, and their addition in 0.9.0.
What 0.9.0 actually changes
The fixing commit, 28d15ca69b0c31387cc6ec73d201fd13c5d22b6a, the tag target for the 0.9.0 release published the same day as the advisory, adds a new module this record read directly, src/server/security.ts, and this record confirmed every property below against that source rather than against the release notes alone. The listener's default bind address becomes DEFAULT_BIND_ADDRESS, set to 127.0.0.1, loopback only, reversing the prior unstated default of every interface. Widening the bind beyond loopback now requires an operator to set a new environment variable, MCP_AUTH_TOKEN, or to pass an explicit --allow-unauthenticated flag; absent either, the server refuses to start against a non loopback bind address, with an error this record read directly stating it is refusing to bind without inbound authentication. Where MCP_AUTH_TOKEN is set, an inbound request's Authorization: Bearer header is compared against it using a constant time comparison this record confirmed reads secretsMatch(a, b) as timingSafeEqual applied to the SHA-256 hash of each value, rather than a direct string comparison a timing side channel could exploit. The server also gained Host header validation, hostHeaderValidation applied against an operator configured allowlist, and Origin header validation, originValidation, which this record confirmed rejects a request whose Origin header is not on a configured allowlist with an HTTP 403. A GET to /healthz remains exempt from all of this, registered ahead of the new security middleware in the server's own request handling order, so a liveness probe still succeeds without a token; this record reads that exemption as deliberate rather than an oversight, since the same commit adds every other check.
Two things this record keeps separate from crediting the fix with more than it does. First, MCP_AUTH_TOKEN is a single, shared secret, not a caller specific identity: the project's own documentation states that when it is set, every request must carry the same Authorization: Bearer value, with nothing in the source or the documentation this record read describing a mechanism by which two different callers holding that same token would be distinguished from one another once past the check. Any holder of the configured MCP_AUTH_TOKEN can exercise whatever Argo CD capability the server's own ARGOCD_API_TOKEN carries, exactly as any caller previously could exercise it with no token at all; what changed is who counts as a holder, not whether holding is a shared or an individual fact. Second, --allow-unauthenticated is documented, in text this record read directly, as intended for a deployment where something in front of the server, a service mesh or a reverse proxy, already authenticates callers before a request reaches this server at all. This record did not independently verify any specific deployment's use of that flag, and does not treat the flag's existence as evidence that every, or even most, widened deployment pairs it with an equivalent upstream control.
Two identities that were never allowed to collapse, and one that was
Three distinct facts sit inside this one vulnerability, and the fix's own shape, a new and separate inbound credential rather than a new rule about the existing one, is itself evidence that the project came to see them as three rather than one. There is the party making the network request to argocd-mcp, whom nothing in 0.8.0 ever asked to establish an identity at all. There is argocd-mcp itself, the intermediary, whose own process is what actually executes the tool call. And there is the credential principal Argo CD's own authentication and RBAC evaluate, the service identity ARGOCD_API_TOKEN represents, which is genuinely, validly authenticated at every step, and which is not, and was never claimed by anyone to be, the same principal as whoever sent the request. Argo CD did its job. It authenticated a real token and authorized a real, permitted principal to perform a real, permitted action. What it could not do, because the question never reached it, is confirm that the party who caused that authenticated principal to act was ever entitled to cause it.
Where this sits against what this desk has already argued
Grafana's own advisory for CVE-2026-19516 showed an MCP server's stored credential and network position reaching destinations a caller was never independently authorized to direct it toward, evidence this desk already reads as an intermediary's own standing functioning as authority a caller did not bring with it. argocd-mcp sharpens that same finding at an earlier stage: Grafana's gap opened after a caller had, at minimum, presented something the server's own session check accepted. Here, in the ordinary configuration the project itself documents, nothing needed to be presented at all, because the check that would have asked for it was satisfied by the operator's own downstream credential before the caller's own request was examined at all.
LiteLLM's patched MCP authentication bypass showed a caller's credential failing validation and a fallback path converting that failure into an accepted, empty identity, a check that ran, failed, and was then discarded. argocd-mcp's own gap precedes that shape entirely: no check ever failed here, because the check in front of the tool call was never built to evaluate the caller at all, only to confirm the server itself had something to work with.
Your Bourse's Trade Server connection lets a connected assistant inherit whatever Trade Server permissions the authenticated employee who connected it already holds, permission inheritance from one identified, authenticated human principal. argocd-mcp's own case has no principal on that side of the inheritance at all; what an unestablished caller inherited was not a human's own narrower permission, but the intermediary's own standing service credential, in full, with nothing to narrow it against.
This desk's own broader argument, that technical admission and execution authority are separate facts evaluated independently, holds here in a form the corpus had not yet isolated this precisely: a downstream system's own valid authentication of a service credential is not, and was never claimed to be, a substitute for an intermediary independently establishing that the party who caused the credential to be used was entitled to cause it.
What this record does not establish
This record does not claim CVE-2026-82456 or GHSA-p2x5-x87w-v2xj name a real, independently confirmable record; it treats GHSA-rp45-5x3v-48mr as the canonical identifier for the underlying vulnerability instead, for the reasons stated above. It does not claim any specific deployment of argocd-mcp 0.8.0 was reachable from the public internet; the correct precondition the evidence supports is a network principal able to reach wherever the operator bound the listener, which the default made every interface rather than only a private network. It does not claim any Argo CD token affected by this vulnerability carried administrative Argo CD or Kubernetes privileges; that depends on how each operator scoped their own token and their own Argo CD projects, which this record did not verify for any specific deployment. It does not claim this vulnerability was exploited against a real deployment before the fix shipped; no source available to this record states that, and this record records that as unknown rather than assumed. It does not claim 0.9.0 provides per caller Argo CD authorization; MCP_AUTH_TOKEN is documented, in the project's own words, as one shared secret, and this record treats per caller downstream authorization as unaddressed by this fix rather than delivered by it.
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-006 Delegated authority inherited without attenuation
- Supports requirement
Agent Flight Recorder
Laurent Bindschaedler, Quentin Botha, Christoph Siebenbrunner (independent research, arXiv preprint)
Requirement Delegation provenance (the requesting agent's identity, the parent event's hash, and the delegated scope) is recorded per event, but attenuation of that scope is not itself enforced
This weakness names authority spreading past its granted boundary because a delegated grant is not checked for narrowing, expiry, or revocability against its parent. Agent Flight Recorder's own delegation provenance field records a requesting agent's identity, a parent event's hash, and a delegated scope per event, which would let an investigator reconstruct after the fact whether a given delegation ever attenuated relative to its parent. That is evidence supporting the need for an attenuation check, not an attenuation check itself: nothing in the material available to this record describes the construction rejecting, narrowing, or expiring a delegated scope at the point delegation happens, only recording what was claimed about 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 The draft keeps a Delegation Record's existence separate from the delegatee's current effective authority
This weakness's own corrective principle states that a delegated grant must not exceed its parent's scope, must not outlive its parent's expiry, and must be revocable together with it. The draft's own separation of a Delegation Record, which states that a delegation occurred, from an Authorization Transition Record, which states the delegated scope's current standing, is structural support for exactly that principle: evidence that authority was delegated is kept apart from evidence of the delegatee's currently effective authority, rather than one record class being asked to carry both facts. Recorded as design evidence for the attenuation principle this weakness names, not as a claim that any implementation of it exists outside the draft's own text.
- Supports requirement
ARC, Agentic Runtime Control
Britive
Requirement Elevated privilege is documented as minted directly in a target system through its own native API and revoked automatically when a task ends, with credential brokering as a separate path for systems that require one
Britive's own documented model brokers or mints credentials ephemerally and scoped to a task, rather than leaving a standing credential ambiently reachable by whatever caller happens to connect. argocd-mcp's pre fix ARGOCD_API_TOKEN is the failure that principle answers, made concrete at an MCP server rather than at the CI or SSH targets Britive's own material names: a standing, environment configured credential, reachable in full by any network caller whose request the server's own credential check would accept regardless of what, if anything, the request itself supplied. The shipped fix, a separate MCP_AUTH_TOKEN, narrows who can reach the server at all rather than narrowing or brokering the ARGOCD_API_TOKEN itself, which remains one long lived, ungraded credential shared across every holder of the new inbound token.
This record is the cited evidence for this relationship.
- Supports requirement
Cross App Access (XAA), Okta Agent SSO and MCP Enterprise-Managed Authorization
Okta
Requirement Enterprise Managed Authorization governs the cross app connection, not the individual action an agent later attempts
Cross App Access places the decision of which requesting identity may open a connection to a resource application with the enterprise identity provider and an administrator's own configured policy, independent of whether that resource application, or a server fronting it, is separately reachable inside the same environment. That connection level, principal specific decision is the same corrective github/gh-aw's own merged fix applies to a dynamically registered GitHub MCP backend: a backend's registration for one principal's delegated use is deliberately not read as a connection grant for a different principal, which must clear its own independent check.
- Supports requirement
Grantex and the Delegated Agent Authorization Protocol (DAAP)
Sanjeev Kumar, Grantex
Requirement Child scopes MUST be a subset of the parent's scopes, and a child may hold exactly the parent's scopes
Grantex enforces that a child grant's scope is a subset of its parent's and its expiry the earlier of the two, which is the attenuation these inheritance and shared credential failures lack. 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 longer instance of the same missing attenuation: credentials a reconnaissance and repository search step discovered reached a secrets manager, then CI/CD and cloud identity, with no subset or expiry check narrower than what each step happened to find described at any hop.
- Supports requirement
Verifiable Attenuated Delegation for AI Agent Chains (draft-asor-wimse-agent-delegation-chain)
Rafael Asor, Attenu
Requirement A child's authority must be a verifiable subset of its immediate parent's: scopes under the wildcard containment rule, every parent constraint present and equal or narrower in the child, and expiry and delegation depth no greater than the parent's
The draft requires a child's scopes, ceilings, constraints and expiry to be a verifiable subset of its immediate parent's, cryptographically checkable offline through a parent hash, which is the attenuation these inheritance and shared credential failures lack. OpenCode issue 47819 documents the same missing subsumption check at the level of a single agent's own permission configuration: the merge composing a custom agent's frontmatter block against the platform's own defaults is a union of the two rather than a verified subset of the wider one.
- Supports requirement
Verifiable Attenuated Delegation for AI Agent Chains (draft-asor-wimse-agent-delegation-chain)
Rafael Asor, Attenu
Requirement Revision 01 adds a min constraint type whose safe attenuation direction is upward, a floor that can only rise as authority narrows
Revision 01's own min constraint, and its explicit statement that a maximum narrows downward while a minimum narrows upward, makes precise a point this weakness otherwise leaves implicit: narrowing is not one direction for every dimension of authority, and a delegation mechanism that only checks subset and shorter expiry can miss a floor that widened rather than a ceiling that loosened.
- Reveals bypass
Agent Identity and Agent Identity Auth Manager
Google
Requirement Agent identities are not shared by multiple workloads by default, cannot be impersonated, and do not allow long lived keys
Google's own comparison states that an agent identity, unlike a service account, is not shared by multiple workloads by default, cannot be impersonated and does not allow long lived keys. argocd-mcp's own ARGOCD_API_TOKEN is exactly the shape this property contrasts against: one long lived, environment configured credential, shared by construction across every caller able to reach the server, with nothing this entry's own reading of the affected source found narrowing which caller could exercise it. This does not fault Google's own architecture, which the property itself only describes rather than mandates elsewhere; it evidences why the comparison the property draws is the attenuation this weakness's own known examples keep missing.
This record is the cited evidence for this relationship.
- Reveals bypass
AI Agent Identity Certificate (AIC) extension for X.509 v3
Jijie Wei, individual submission to the IETF
Requirement Authority can go stale after issuance
AIC's authorized mode locks the permission set into the certificate at issuance, so authority can go stale: a change to the principal's grants after issuance does not reach an already issued certificate, a delegation gap the inheritance failures illustrate.
- Reveals bypass
Verifiable Attenuated Delegation for AI Agent Chains (draft-asor-wimse-agent-delegation-chain)
Rafael Asor, Attenu
Requirement Nothing in the token profile establishes that the root token holder was actually entitled to grant the authority the root token represents
A verified chain proves lineage forward from a trusted root key, not that the root holder was ever entitled to the authority it represents, so a mistaken or illegitimate grant at the root produces a chain every hop of which still narrows correctly, an inheritance failure the subsumption check alone does not reach.
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.
This record is the cited evidence for this relationship.
- 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.
Protocol evidence related through AEV-2026-0034 argocd-mcp 0.8.0 let an unestablished network caller act as Argo CD's own configured credential (GHSA-rp45-5x3v-48mr)
- 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. argocd-mcp 0.9.0's own MCP_AUTH_TOKEN check, confirmed directly against the fixed source, sits ahead of every tool call once a bind is widened beyond loopback, and the server refuses to start against a widened bind at all without that token configured or an explicit override. This is real, shipped enforcement evidence for a permit gating governed action, distinct from the pre fix state this vulnerability describes, in which no such enforcement point existed at all and the operator's own downstream Argo CD credential stood in for one.
This record is the cited evidence for this relationship.
- Contradicts requirement
Agent Identity and Agent Identity Auth Manager
Google
Requirement With Agent Gateway and Gemini Enterprise, end user credentials are encrypted by Auth Manager and decrypted only at the gateway, so the agent never sees the raw credential
Google's own stronger architecture keeps a raw third party credential from ever reaching the calling agent at all, decrypting it only at a mediating gateway. argocd-mcp 0.8.0 is the direct opposite of that property: the server's own ArgoCDClient attaches its configured ARGOCD_API_TOKEN to every outbound Argo CD request on behalf of any caller whose request the credential check accepted, which this entry confirmed included a caller who presented nothing at all. This entry does not read Google's property as a claim about MCP servers specifically; it reads argocd-mcp's own pre fix design as evidence contradicting the requirement wherever an intermediary attaches its own standing credential to a caller's request with no mediation narrower than the caller reaching the intermediary at all.
This record is the cited evidence for this relationship.