The User Was Authorized to Configure the MCP Server. They Were Not Authorized to Turn Rowboat Into a Route to Every Address It Could Reach.
CVE-2026-86122, published 5 September 2026 against Rowboat through version 0.9.1, describes two paths in the same product, a custom MCP server URL and a project webhook URL, that Rowboat's own server process later connects to or fetches with no check on the destination. This record read Rowboat's own affected source directly and confirmed something the primary issue already states plainly: the project action authorization policy runs first, and correctly. What runs after it, a function named validateHttpHttpsUrl, checks only that the value parses as an http or https URL. Nothing between that check and the later connection asks whether the destination itself was ever an authorized one. A proposed fix predates the issue by five weeks, has never been linked to it, and remains open and unmerged.
Event analysed: . This analysis was published on 6 September 2026.
Nothing, on the two paths this record could read directly. GitHub issue 621, opened against rowboatlabs/rowboat on 13 June 2026 by a reporter identified as geo-chen and still open as of this record, describes a server side request forgery reachable by any registered project member through two user configured URL fields: a custom MCP server URL and a project webhook URL. CVE-2026-86122, published 5 September 2026 against Rowboat through version 0.9.1, formally assigns the same mechanism. This record could not directly read a CVE Numbering Authority's own record for it, since cve.org, nvd.nist.gov, vulncheck.com and several other CVE aggregators this record attempted to fetch directly remained blocked by this session's network egress policy on both 6 and 7 September 2026, but a direct read on 7 September 2026 of GHSA-jmxm-qmrf-xrpp, the general GitHub Advisory Database's own mirror of this CVE, independently confirms the publication date, the through 0.9.1 affected range, the CWE-918 classification and a CVSS 4.0 vector scoring 5.3, all of which this record's earlier searches had already found through convergent search rather than a single primary record. That mirror is marked Unreviewed by GitHub, meaning NVD sourced rather than independently curated, and it is a general database entry rather than a security advisory rowboatlabs/rowboat's own maintainers published themselves, since this record confirmed on both dates that the repository's own security advisories page still lists none; a separately reported CVSS 3.1 score of 5.0 and the identity of the assigning CVE Numbering Authority remain unconfirmed by any primary record this session could reach. What this record read directly, at the v0.9.1 tag, removes any doubt about the mechanism itself. AddCustomMcpServerUseCase's execute method calls this.projectActionAuthorizationPolicy.authorize, then this.usageQuotaPolicy.assertAndConsumeProjectAction, then a locally defined function, validateHttpHttpsUrl, which constructs a URL object from the caller supplied value and throws only if its protocol is neither http: nor https:, then persists the result through projectsRepository.addCustomMcpServer. The order is not in question and the authorization call is real: a caller without standing on the project is stopped before the URL is ever inspected. What stops nowhere in this function, or anywhere else this record could read, is a check on the destination itself. A value satisfying validateHttpHttpsUrl includes http://127.0.0.1:6379/, http://169.254.169.254/ and http://10.0.0.5:8080/ exactly as readily as it includes a legitimate external MCP server, because the function never resolves the hostname and never asks whether the resulting address is loopback, link local, RFC 1918 private space or a cloud metadata endpoint. The stored value is later read back by Rowboat's own agent runtime. invokeMcpTool, in agent-tools.ts, reads project.customMcpServers[mcpServerName].serverUrl, checks only that it is present, and passes it unchanged to getMcpClient, which this record confirmed by direct reading opens the MCP session; this record could not independently read getMcpClient's own internal transport construction, since the file it is imported from returned a not found response on every attempted fetch, but the call site itself passes the stored, never validated URL straight through. invokeWebhookTool reads project.webhookUrl, checks only that it is present, and issues fetch(project.webhookUrl, { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-signature-jwt': jwt }, body }), where the JWT is Rowboat's own signature over the request, addressed to whatever destination the caller named, not a credential that independently constrains where the request may go. On a failed response the function throws Failed to call webhook: ${response.status}: ${response.statusText}, exposing exactly the kind of status and status text detail an internal port scan reads to distinguish an open service from a closed one from a filtered one; on success it returns the full parsed JSON response body, unfiltered, to the calling agent. A pull request, 547, titled by its own author fix(security): add SSRF protection for webhook and MCP server URLs, was opened 10 May 2026, five weeks before issue 621 existed, proposes destination validation rejecting private, loopback and link local ranges and cloud metadata addresses for both the MCP server URL and the webhook URL, and is not referenced by issue 621 or, on the evidence available to this record, aware of it. As of this record it remains open, unmerged, and carries no indication of maintainer review beyond its own description. Nothing available to this record establishes that CVE-2026-86122 has been exploited against a real Rowboat deployment.
Read Rowboat's own affected source and there is no ambiguity to resolve about whether an authorization check exists. It does, it runs first, and it runs correctly. The gap this record documents sits entirely after that check succeeds: a project member who was genuinely, correctly authorized to add a custom MCP server or configure a webhook could name almost any address as the destination, and nothing asked whether that specific destination was one the grant was ever meant to cover.
What the primary issue states, and what this record independently confirmed
GitHub issue 621 against rowboatlabs/rowboat, opened 13 June 2026 by a reporter identified as geo-chen and still open as of this record with no comments, no maintainer response and no linked pull request, states its own title plainly: server side request forgery via user configured custom MCP server URLs and webhook URLs, no private IP or metadata guard, reachable by any project member. The issue names two exact source locations, apps/rowboat/src/application/use-cases/projects/add-custom-mcp-server.use-case.ts and apps/rowboat/src/application/lib/agents-runtime/agent-tools.ts, and this record read both directly at the v0.9.1 tag rather than relying on the issue's own description of them alone.
An authorization check that works, immediately followed by one that does not ask the right question
It is worth being precise about what projectActionAuthorizationPolicy.authorize actually establishes, because the issue's own framing and this record's own reading agree on this point exactly. That call answers one question: is this caller, identified as a user or an API key, permitted to perform the configure custom MCP server action on this project. It is a genuine, working check, and a caller without standing on the project never reaches the URL at all. validateHttpHttpsUrl answers a completely different question, and answers only that one: does this string parse as a URL whose protocol is http or https. Between those two checks, and after both of them succeed, nothing asks a third question that the first two checks do not and cannot answer between them: is this specific destination one the authorized action was ever meant to reach. A project member authorized to add a custom MCP server is, on this code path, equally able to add http://127.0.0.1:6379/, http://169.254.169.254/latest/meta-data/, or an address inside whatever private network the Rowboat deployment itself sits on. Every one of those values is a well formed http URL. None of them is a URL any grant of authority named.
What happens after the URL is stored: two separate consequential connections
A stored, unvalidated URL is inert until something reads it back and acts on it. Rowboat's own agent runtime does exactly that, on two separate paths, and this record read both directly in agent-tools.ts at the v0.9.1 tag. invokeMcpTool reads project.customMcpServers[mcpServerName].serverUrl, checks only that the field is present, throwing if it is not, and then calls getMcpClient(mcpServerURL, mcpServerName), whose result's callTool method the function invokes immediately afterward. This record's own attempts to read getMcpClient's implementation directly, at the import path the call site names, returned a not found response on every attempt, so this record does not independently describe the transport construction inside that function. What this record does confirm directly is the call site itself: the URL reaching getMcpClient is the same value validateHttpHttpsUrl accepted at configuration time, with no intervening check.
invokeWebhookTool is the second path, and here this record read the complete function body directly. It reads project.webhookUrl, checks only that the field is present, builds a signed request body, a JWT whose payload names the request id, project id and a hash of the content, and calls fetch(project.webhookUrl, { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-signature-jwt': jwt }, body: JSON.stringify(request) }). The JWT is Rowboat's own signature, meant for the receiving endpoint to verify the request came from Rowboat; it is not a credential that constrains which endpoint the request is sent to, and it is sent to whatever address project.webhookUrl holds. If the response is not ok, the function throws an error whose message is built directly from response.status and response.statusText. If the response is ok, the function parses and returns the complete JSON body to the calling agent, unfiltered.
A proposed fix that predates the report it would answer, and has never been connected to it
Pull request 547, fix(security): add SSRF protection for webhook and MCP server URLs, opened by a contributor identified as JasonOA888 on 10 May 2026, describes adding destination validation that rejects private network ranges, loopback addresses, cloud metadata endpoints and reserved address space, applied to both the custom MCP server URL and the webhook URL. This record read the pull request's own description through this session's page fetch tool rather than its raw diff, so the account here is of what the pull request states it does, not an independently confirmed line by line read of its changed code, the same limitation this desk states plainly whenever a source is read through summarization rather than as raw text. What this record can state with more confidence is the timeline: pull request 547 was opened 10 May 2026, five weeks before issue 621 was opened on 13 June 2026, and nothing in either the issue or the pull request, on the material available to this record, connects the two. The issue does not reference pull request 547 as a proposed fix, and the pull request does not reference issue 621 as the report motivating it. As of this record, pull request 547 remains open and unmerged, and this record found no indication of maintainer review beyond the pull request's own self description.
The three questions an authorization decision actually has to answer
Rowboat's own architecture, read precisely, answers two authority questions correctly and leaves a third unaddressed. Who may configure a custom MCP server or a webhook for this project: projectActionAuthorizationPolicy.authorize answers this, and answers it before anything else runs. What may they configure: an http or https URL, no more and no less, is what validateHttpHttpsUrl actually establishes, a narrower answer than it might first appear, since it constrains form, not content. Which destination may the resulting connection or request actually reach: nothing in the code this record read answers this question at all. A grant to perform the configure action is not, by itself, a grant naming every address the authorized action might later be pointed at, and Rowboat's own code treats the first grant as though it settled the third question along with it, because nothing else was ever asked.
Where this sits in the pattern
OGX's own affected source showed a validation helper that existed, worked correctly on two sibling caller controlled URL paths, and was simply never connected to the MCP tool path that needed it; Rowboat's own code shows something starker still, since no destination validation function exists anywhere in the codebase this record could find for either the MCP server URL or the webhook URL to have been left disconnected from. Grafana's own advisory for CVE-2026-19516 documented a server whose credential binding had already been fixed once, only for a separate advisory to establish that destination binding had never been addressed at all; Rowboat's own authorization call plays a comparable role to Grafana's caller authentication, a genuine, working check answering who may act, that this record confirms was never paired with an equivalent check on where the resulting action may reach. AgentScope's own add_skill method showed a destination confinement check that worked, paired with a source argument that received only a content shaped check and no location check at all, a two sided operation where one side was genuinely authorized and the other was not; Rowboat's own case is one sided in comparison, a single outbound connection whose only checks are who may configure it and whether it is syntactically a URL, with no destination side ever built to check at all. The broader argument this desk has made since its own launch, that execution authority has to be evaluated at the moment of the consequential action rather than assumed from an earlier admission, holds here in an unusually clean form: Rowboat's own admission decision, the authorize call, is real, correct and confirmed by this record's own reading of the source, and the consequential action, the server's own outbound MCP session or webhook request, still runs with no independent check on the one dimension, the destination, that the admission decision never claimed to settle.
A one day refresh, and what it changed
A refresh of this record on 7 September 2026, one day after its own initial publication, found issue 621 still open with no new comments, pull request 547 still open and unmerged, and a further pre release, v0.9.4, published 6 September 2026, whose equivalent file paths this record attempted and failed to read directly, exactly as v0.9.2 and v0.9.3 already had. The one new fact this refresh adds is GHSA-jmxm-qmrf-xrpp, the general GitHub Advisory Database's own mirror of CVE-2026-86122, readable directly where cve.org and nvd.nist.gov remained blocked, which independently corroborates the CVE's publication date, affected range, CWE-918 classification and CVSS 4.0 score without changing anything else this record already concluded. That mirror is marked Unreviewed by GitHub and sourced from NVD rather than published by rowboatlabs/rowboat's own maintainers, whose own security advisories page this record confirmed again still lists none; the two facts sit together rather than in tension, since a general database mirror and a maintainer's own advisory are different things.
What this record does not establish
This record does not claim CVE-2026-86122 has been exploited against a real Rowboat deployment, that pull request 547 has merged or shipped in any released version, that pull request 547's own code matches its description in every particular, since this record read that description through a page summarization tool rather than the raw diff, that Rowboat's v0.9.2, v0.9.3 or v0.9.4 pre releases changed the specific functions this record read at v0.9.1, since this record's attempts to read the equivalent files at those tags all returned not found responses rather than confirming either an unchanged or a fixed state, that getMcpClient's own internal transport construction contains or lacks any destination check beyond what the call site this record read passes into it, or which body served as the CVE Numbering Authority assigning CVE-2026-86122, since neither a primary CNA record nor the GHSA mirror this record read directly states one. Where the evidence available to this record does not establish a fact, this record states it as unknown rather than inferring it from how the pattern has resolved elsewhere.
Sources
This analysis interprets third-party reporting, research and announcements. Moona is not the original reporter of the underlying events.
Protocol evidence
This record does not assess these architectures. The connection runs through the Risk Registry requirement each one bears on, and these published authority architectures are what the evidence says about that requirement.
Protocol evidence related through AEW-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.