The Caller Had Access to the Tool. The Server Had Access to Everything Behind It.
Grafana's own advisory for CVE-2026-19516 states plainly what a caller supplied X-Grafana-URL header let a Grafana MCP server do: reach internal, loopback and link local network services, cloud metadata endpoints included, and read back the response. Pillar Security separately reported that a caller could reach those same tools without ever holding a session the server actually issued. Neither finding is new in kind. Together they are a clean, documented case of a pattern Moona Intelligence has tracked since agents began sitting behind MCP servers: the intermediary's own credentials and its own place on the network are a form of authority the caller never independently earned.
Event analysed: . This analysis was published on 3 September 2026.
The server's, and that is the finding worth keeping past the patch. Grafana Labs published CVE-2026-19516 on 11 August 2026, rated CVSS 9.1 Critical under CWE-918, Server Side Request Forgery. Grafana's own advisory, mirrored on GitHub as GHSA-fr94-7cqc-vjrq and read directly there, states that a caller supplied X-Grafana-URL request header, used together with the grafana_api_request tool, let a caller control the destination, HTTP method, path and body of mcp-grafana's outbound request. Because the destination was not restricted to the Grafana instance the server was configured against, a caller could direct requests at internal, loopback and link local network services, cloud metadata endpoints included, and read the responses. Grafana's advisory is explicit that a prior fix, CVE-2026-15583, published 15 July 2026 as GHSA-7cfp-pmw3-4j7r, closed a narrower gap: it stopped the server's environment configured Grafana service account token, and other credential material, from being sent to a caller specified host, but it did not restrict the destination itself. That is the gap CVE-2026-19516 closes: mcp-grafana v1.1.0, released 10 August 2026, one day before the CVE's own publication, is the version this record treats as fixed, on the strength of Grafana's own advisory and of GitHub's mirrored record of it, GitHub itself being directly readable in this session even where grafana.com was not. Separately, and on Moona Intelligence's own reading a genuinely distinct finding rather than a restatement of the same one, Pillar Security reported that the MCP server accepted a caller generated, session shaped identifier it had never actually issued, because the server validated the value's format rather than checking it against a real, previously granted session. Reporting on Pillar's research, corroborated across multiple independently phrased searches after direct access to pillar.security remained blocked in this session, describes those two findings paired into what Pillar calls a killchain: an unauthenticated caller able to reach the server's tools through a spoofed session identifier, then able to use the SSRF to reach whatever the server's own network position could reach. The same reporting describes Pillar demonstrating an IMDSv2 style two step request, a PUT carrying a TTL header to obtain a metadata service token, then a second request using that token, in what this record understands from that reporting to be a controlled test rather than an attack against a real cloud account; Moona Intelligence could not read Pillar's own page directly to confirm that framing in Pillar's exact words, and states plainly that it has not independently confirmed whether any live metadata service was actually reached in that demonstration. No source available to this record claims the vulnerability was exploited against a real deployment before it was fixed, and this record does not infer exploitation in the wild from a disclosed, patched flaw and a controlled proof of concept. What the two sources together establish, read narrowly, is not primarily a story about one vendor's SSRF bug. It is a documented case of an MCP server's own credentials and its own place on the network functioning as authority a caller could reach without ever being independently granted it, the same pattern this desk has already read in Salesforce's Headless 360 MCP Server and in TrueFoundry's MCP Gateway, here evidenced by a CVE with a CVSS score attached rather than by documentation of an access control working as designed.
Read Grafana's own advisory for CVE-2026-19516 and the sentence that matters is short and specific: a header the caller supplies decides where the server's next request goes. Everything else, the CVSS 9.1 score, the CWE-918 classification, the internal and link local and metadata destinations named as reachable, follows from that one design fact. This record is about what that fact means once it is generalised past Grafana, because it is not a Grafana specific fact. It is what happens whenever a caller is allowed to invoke a tool that a server operates with its own credentials and from its own place on the network, and nothing separately asks whether the caller was ever entitled to exercise that credential or that network position for the destination it is now choosing.
What Grafana's own advisory establishes
Grafana Labs published CVE-2026-19516 on 11 August 2026. Moona Intelligence read the advisory's content directly through its GitHub mirror, GHSA-fr94-7cqc-vjrq, since grafana.com itself was blocked to direct fetch in this session on every attempt; GitHub's own advisory page states plainly that it draws from Grafana's official advisory, cited there and here as the primary source. The vulnerability carries a CVSS 3.1 score of 9.1, Critical, vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L, and CWE-918, Server Side Request Forgery. The mechanism, in Grafana's own words as mirrored in the advisory: a caller supplied X-Grafana-URL request header controls the destination of mcp-grafana's outbound requests, and the grafana_api_request tool lets the same caller also choose the HTTP method, path and body of that request. Because the destination was not restricted to the Grafana instance the server was configured to talk to, a caller could direct the server's own outbound requests at internal, loopback and link local network services, explicitly including cloud metadata endpoints, and read back whatever those services returned.
The gap the previous fix left open
Grafana's own advisory is explicit that this is not the first patch touching X-Grafana-URL. CVE-2026-15583, published 15 July 2026 and mirrored as GHSA-7cfp-pmw3-4j7r, describes an earlier, narrower flaw: a confused deputy condition in which an unauthenticated caller could exfiltrate the server's environment configured Grafana service account token by supplying a crafted X-Grafana-URL header, since the server would forward that credential to whatever host the header named. Grafana fixed that by binding the environment configured credential to the server's own configured Grafana URL, so a caller supplied destination no longer receives the service account token, deprecated API key, basic auth credential or extra headers meant for the real Grafana instance. That fix, read directly from the mcp-grafana changelog on GitHub, is real and it worked for what it targeted. What Grafana's own CVE-2026-19516 advisory states directly, and what this record treats as the single most important sentence in the whole disclosure, is that the earlier fix stopped the credential from following a caller chosen destination. It never restricted the destination itself. A caller could no longer walk off with the Grafana service account token by naming an external host, but the server would still dutifully send a request, without that credential, to wherever the header named, internal and cloud metadata destinations included, and hand the response back. Credential binding and destination binding are two different controls, and Grafana's own two advisories, read together, are a rare case of a vendor documenting the exact sequence by which fixing the first one revealed that the second one was still missing.
Grafana's fix for CVE-2026-19516 shipped in mcp-grafana v1.1.0, released 10 August 2026, one day ahead of the CVE's own publication, a release Moona Intelligence read directly from the project's GitHub releases page. That same release adds optional bearer token caller authentication, through a new --server-auth-token flag: when an operator sets it, a caller must present a matching Authorization: Bearer header or receive a 401. This record treats that authentication addition and the SSRF's destination restriction as two separately necessary controls shipped in the same release, not as one fix serving both purposes, because a caller who is genuinely authenticated is a different question from a caller whose request is allowed to reach an unrestricted destination once admitted.
What Pillar Security's research adds, and where it is distinct
Pillar Security separately reported a second finding concerning the same server: that mcp-grafana would accept a caller generated session identifier the server had never actually issued. Reporting on Pillar's research, corroborated across several independently phrased searches after direct access to pillar.security remained blocked to this session on every attempt, describes the mechanism as a format check standing in for a credential check: the server validated that a supplied session identifier looked like one of its own, rather than confirming it against a session the server had genuinely created and handed out. A caller able to construct a session shaped value could reach the server's tools without ever having been through whatever process was meant to establish that a legitimate caller was on the other end.
Moona Intelligence treats this as evidence distinct from CVE-2026-19516 rather than a second description of the same flaw, and keeps the two apart deliberately. Grafana's own advisory for CVE-2026-19516 is about where an already admitted caller's request is allowed to go. Pillar's session finding is about whether the caller was ever genuinely admitted in the first place. Reporting on Pillar's research describes the two paired into what Pillar itself calls a killchain: a caller who could reach the server's tools through a spoofed session, then use the SSRF to reach whatever the server's own network position made reachable. That composition is exactly why this record separates the two rather than treating either alone as the whole picture. A caller who was never genuinely authenticated, reaching a tool whose outbound destination was never independently constrained, is a caller exercising two different pieces of the intermediary's own standing at once: the server's admission of the call, and the server's place on the network once the call is admitted.
The same reporting on Pillar's research describes a controlled demonstration built on the well known AWS Instance Metadata Service v2 two step pattern: a PUT request carrying a TTL header to obtain a metadata service session token, then a second request presenting that token to retrieve the credentials the metadata endpoint would otherwise hand back. This record understands that demonstration, from the reporting available to it, to have been run in a test setting rather than against a live cloud account, but states plainly that it could not read Pillar's own page directly to confirm the exact scope of that demonstration in Pillar's own words, and does not claim to have independently verified whether a real metadata service was ever actually reached. Nothing available to this record states that the vulnerability was exploited against a production deployment before Grafana's fix shipped, and this record does not infer exploitation in the wild from a disclosed, patched CVE and a researcher's own controlled proof of concept.
Why this is not, at bottom, a story about Grafana
Every MCP server that runs with its own credential and its own network reachability, rather than acting purely as a transparent relay of a caller's own identity and a caller's own network position, is carrying authority the caller did not bring with it. That is not a flaw in the architecture. A server holding a service account token so a caller does not have to manage one directly, or a server sitting inside a private network a caller could not otherwise reach, is often exactly the point of running an MCP server at all. The question this record keeps returning to, across every intermediary this desk has examined, is narrower and more specific than whether the intermediary should hold that authority. It is whether admitting a caller to the intermediary's tools was ever meant to be the same decision as authorizing that caller to exercise every credential and every network path the intermediary happens to carry.
Grafana's own architecture answers that question two different ways for two different resources, and the CVE record shows both answers clearly. For the configured Grafana instance itself, the intended answer was narrow: a caller invoking grafana_api_request was meant to reach that one instance, through that one credential, and nothing else. For the destination named in a caller supplied header, before the fix, there was no independent answer at all. Nothing checked whether an admitted caller reaching an internal service, a loopback address or a cloud metadata endpoint through the server's own network position was a capability that caller was ever meant to have. The caller had access to the tool. The server had access to everything behind it, and until v1.1.0 that was close enough to the same thing.
Where this sits in the pattern
Moona Intelligence has read this same shape of gap in more than one MCP architecture this month. Salesforce's Headless 360 MCP Server binds every call to the authenticated user's own Salesforce permissions rather than to a server held credential, a deliberate design choice that avoids exactly the failure mode CVE-2026-19516 documents, and this record reads Grafana's incident as evidence for why that choice matters rather than as a criticism of Salesforce's different architecture. TrueFoundry's MCP Gateway places a human approval decision at the network boundary an agent's traffic has to cross, a different answer to a related problem: neither TrueFoundry's Human Gate nor Grafana's own service account model removes an intermediary's own standing from the picture, they each decide differently what independently constrains what that standing can be used for. This desk has already argued, following NCSC's own August 2026 interim advice on agentic AI, that a reachable resource functions as an authorized one wherever nothing independently checks reachability against authorization, and CVE-2026-19516 is a documented instance of exactly that substitution: internal, loopback and metadata destinations were reachable from the server's own network position, and reachability was, until the destination binding fix shipped, doing the work authorization should have done. This desk has also tracked how a shared credential lets one actor inherit another's authority without any narrowing attached to the inheritance, and a server side service account token reachable by any admitted caller, before bearer token authentication existed as an option, is that same failure with the intermediary itself as the party the authority was inherited from. The broader argument this desk has made since its own launch, that technical admission and execution authority are not the same fact, holds here in one of its clearest documented forms yet: Grafana's own advisory does not describe a caller doing anything the server was not, in some narrow technical sense, willing to do on its own reachable network. It describes a caller directing where that willingness pointed, unconstrained, because nothing had yet made the destination itself part of what required authorization.
The Authority Provenance ledger
Moona Intelligence separates what the documented mechanism technically permitted from what the available evidence establishes about who was entitled to grant that permission, the same discipline this desk applies to every intermediary architecture it reviews.
Authority grantor. The operator who deploys and configures a Grafana MCP server, who chooses whether to enable the bearer token authentication v1.1.0 introduced, and who configures the environment held Grafana service account credential the server carries. Neither Grafana's advisory nor reporting on Pillar's research names an organizational principal, beyond the deploying operator, who separately decided that a caller reaching the server's tools should be able to direct its outbound requests anywhere the server's own network position could reach.
Caller identity. Documented differently for the two findings. Grafana's own CVSS vector for CVE-2026-19516 specifies PR:L, low privileges required, consistent with an authenticated caller for the SSRF path itself. Pillar's separately reported session finding describes an unauthenticated caller able to reach the server's tools at all, by supplying a session shaped identifier the server never issued. This record does not collapse those two into one caller identity claim, since Grafana's own advisory and Pillar's research describe different points in the chain.
Caller mandate. Whatever mandate admitted a caller to invoke the server's tools at all, documented on Grafana's own architecture as ordinarily requiring at least the low privileges CVE-2026-19516's own vector specifies, or, on Pillar's separately reported finding, potentially nothing more than a correctly shaped session identifier. Neither source states that this mandate was ever understood, by the operator or by Grafana's own documentation, to extend to choosing the destination of the server's outbound requests.
Intermediary. mcp-grafana, the Grafana MCP server itself, documented in both advisories as the party actually issuing the outbound request under attack.
Intermediary credential. The environment configured Grafana service account token, deprecated API key, basic auth credential or extra headers the server carries to reach its own configured Grafana instance, the exact material CVE-2026-15583's fix stopped from following a caller chosen destination.
Intermediary network authority. Whatever internal, loopback, link local and cloud metadata destinations were reachable from wherever the operator deployed the server, documented in Grafana's own advisory as the class of destination CVE-2026-19516 made reachable to a caller through the server's own network position.
Downstream target. Either the Grafana instance the server was configured to reach, the intended and sole target before this vulnerability, or, once a caller supplied the X-Grafana-URL header, any internal, loopback, link local or cloud metadata destination the server's own network position could reach.
Failed limit. Destination was not independently constrained to the configured Grafana instance, documented directly in Grafana's own advisory as the specific gap CVE-2026-19516 closes.
Inherited assumption. That a caller admitted to invoke grafana_api_request was thereby entitled to direct the server's outbound request to any destination the server itself could reach, rather than only to the one Grafana instance the tool was built to serve.
Credential binding. Addressed by the earlier fix, CVE-2026-15583: the server's own credential material no longer follows a caller specified destination.
Destination binding. Left unaddressed by that earlier fix, and the specific gap this record's central finding turns on; addressed by CVE-2026-19516's own fix in mcp-grafana v1.1.0, on the evidence this record could verify.
Challenge authority. Bearer token caller authentication became available, as an operator configured option, in v1.1.0. Neither advisory nor the reporting on Pillar's research describes a server side check, independent of caller authentication, over which destinations a given caller or a given tool call may target once authenticated.
Revocation or modification. Undocumented in the material available to this record. Neither advisory describes a mechanism for revoking a bearer token once issued, distinct from whatever the deploying operator's own infrastructure provides.
Recovery path. Undocumented as a distinct mechanism. Both CVEs describe a shipped code fix as the remedy; neither describes a remediation process for a request that may have reached an unintended destination before the fix was applied to a given deployment.
Exploitation. Unknown. No source available to this record states that either vulnerability was exploited against a production deployment before it was fixed. Pillar's demonstrated request sequence is understood from reporting on Pillar's own research to have run in a controlled setting; this record could not confirm that framing by reading Pillar's own page directly, and makes no claim either way about whether an actual cloud metadata service was reached in the course of that demonstration.
Provenance evidence quality. Strong for the SSRF mechanism itself, the CVSS score, the CWE classification and the relationship to the prior CVE, all read directly from GitHub's mirror of Grafana's own advisories rather than from secondary reporting. Weaker, and dependent on convergent search corroboration rather than a direct read, for Pillar's own session validation finding, its killchain framing and the specifics of its demonstrated request sequence, since pillar.security itself was not reachable in this session. This record keeps that distinction visible rather than presenting both bodies of evidence at the same confidence.
What remains unknown
This record does not establish, and states plainly that it cannot establish from the material available to it, how many production Grafana MCP deployments ran with the vulnerable configuration before the fix, whether any deployment was actually reached through the SSRF or the session finding by a party other than Pillar's own researchers, what specific downstream systems, beyond the general classes of internal, loopback, link local and cloud metadata destinations Grafana's advisory names, were reachable in any particular real deployment, or whether a live cloud metadata service was ever actually queried in the course of Pillar's own demonstration rather than in a setting constructed to resemble one. Where the evidence does not establish a fact, this record states it as unknown rather than filling the gap with what the pattern would predict.
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.
- 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.
This record is the cited evidence for this relationship.
- 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.
- 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.