AWS Agent Registry Approves a Listing. It Does Not Approve a Call.
AWS Agent Registry, part of Amazon Bedrock AgentCore, reached general availability on 31 August 2026, four months after an April preview. It gives an organization one governed catalog of agents, tools, skills, MCP servers and gateways, with a Draft to Pending Approval to Approved workflow deciding what becomes discoverable. That workflow decides who may find a resource through the registry. It does not decide who may invoke the resource once found, and this record found nothing in AWS's own reachable material that says otherwise.
Event analysed: . This analysis was published on 8 September 2026.
No, and AWS's own architecture keeps the two questions structurally separate rather than leaving a reader to infer the boundary. AWS Agent Registry, generally available since 31 August 2026 as part of Amazon Bedrock AgentCore, is built around what AWS's own material calls a Governance Plane and a Discovery Plane: the Governance Plane is the authoritative store holding every registered record regardless of its lifecycle state, and the Discovery Plane is what a consumer actually searches, surfacing only records an administrator or curator has moved to Approved. A record's own lifecycle, Draft, Pending Approval, Approved, Rejected or Deprecated, decides one thing: whether the record is visible in search and browse results at all. This session fetched AWS's own published SDK source for the registry's discovery API directly (github.com/aws/aws-sdk-go-v2, not blocked by this session's network egress policy, unlike aws.amazon.com and docs.aws.amazon.com, which were blocked on every attempt) and confirmed it exposes exactly three operations: SearchDiscoverableRegistryRecords, ListDiscoverableRegistryRecords and BatchGetDiscoverableRegistryRecord. All three read. None of them calls, invokes or executes the resource a record describes. A discovered agent, tool, skill, MCP server or gateway is reached, if at all, through its own separate connection and its own separate authorization, IAM or a bearer token the registry itself does not issue and does not check on the invoking party's behalf. Approval for discovery and authorization for the consequential action a discovered resource performs are, on this evidence, two different decisions AWS's own architecture never merges into one.
AWS announced AWS Agent Registry in preview on 9 April 2026 and took it to general availability on 31 August 2026, a distinct, later date this record keeps separate from the preview announcement throughout. Both dates are corroborated across multiple independently phrased searches converging on AWS's own "What's New" posts (aws.amazon.com/about-aws/whats-new/2026/04/aws-agent-registry-in-agentcore-preview and aws.amazon.com/about-aws/whats-new/2026/08/aws-agent-registry-generally-available); this session could not load either page directly, since aws.amazon.com and docs.aws.amazon.com were both blocked by its network egress policy on every attempt, so both dates are graded documented rather than verified from the announcement pages themselves. The general availability date is independently corroborated at the verified grade from a source this session could fetch directly: the CHANGELOG.md AWS itself ships inside the public aws-sdk-go-v2 repository states, for both the agentregistry and agentregistrycontrol service modules, that version 1.3.0, dated 2026-08-31, is the release at which "AWS Agent Registry becomes Generally Available."
The same changelog fixes a second date this record keeps separate from both: version 1.0.0 of each module, dated 2026-08-06, introduced the SDK client for what the changelog itself calls Agent Registry's Public Preview under a new namespace, agent-registry, replacing the earlier preview namespace, bedrock-agentcore. A GitHub issue this session fetched directly, hashicorp/terraform-provider-aws#48694, independently confirms the same 6 August 2026 date from the consumer side: it states that AWS Agent Registry moved from the bedrock-agentcore namespace to the agent-registry namespace starting 6 August 2026, that the Terraform provider's own aws_bedrockagentcore_registry resource is scheduled for deprecation, and that anyone operating a registry under the preview namespace must migrate endpoints, IAM policies, SDK clients, CLI scripts and registry data before the old namespace stops working. Independently phrased search corroborates the specific date that stop takes effect: AWS's own documentation is reported to state that support for the public preview bedrock-agentcore namespace will be discontinued on 17 September 2026, a hard cutoff distinct from the 6 August date the new namespace first became available and distinct again from the 31 August date the service itself reached general availability. This record was not able to load AWS's own migration guide directly to confirm the 17 September date at the verified grade, so it is carried at documented.
Two planes, one lifecycle, one question each
AWS's own architecture, read through material this session could reach, separates a Governance Plane from a Discovery Plane. Independently phrased search converges on the same description across multiple sources: the Governance Plane is the authoritative store for every resource registered within a registry's scope, regardless of its current lifecycle state, while the Discovery Plane is what a consumer actually interacts with, surfacing only what has cleared the approval bar. A record's lifecycle moves through five named states this session confirmed directly against AWS's own published SDK source rather than accepting them from search alone: reading enums.go from the agentregistrycontrol service's own types package in aws-sdk-go-v2 (github.com, fetched directly), the record status enum carries DRAFT, PENDING_APPROVAL, APPROVED, REJECTED and DEPRECATED as its stable, non-transient values, alongside transient states (CREATING, UPDATING, and their failed counterparts) that describe an in-flight write rather than a governance decision. Independently phrased search converges on what those states gate: only a record in APPROVED status appears in the Discovery Plane's search, browse and list results. Draft, Pending Approval, Rejected and Deprecated records remain fully present in the Governance Plane, visible to an administrator or curator, and invisible to an ordinary consumer searching the registry.
That lifecycle answers exactly one question: is this record discoverable. It does not, on any material this session could reach, answer a second, separate question: is the caller who finds it authorized to invoke whatever the record describes. Nothing this session found describes the registry's own approval workflow as issuing, checking, or even being aware of, a credential, a permission or an IAM policy that governs the discovered resource's own invocation. The two questions are handled by architecturally separate mechanisms, and this record treats collapsing them into one as the exact overclaim AWS's own design goes out of its way to avoid making.
The discovery API this session actually read cannot invoke anything
Rather than rely on search-summarized claims about what the registry's discovery surface can do, this session fetched AWS's own SDK source for it directly. The agentregistry service directory in aws-sdk-go-v2 (github.com/aws/aws-sdk-go-v2/tree/main/service/agentregistry, fetched directly, not blocked) contains exactly three api_op_*.go files: BatchGetDiscoverableRegistryRecord, ListDiscoverableRegistryRecords and SearchDiscoverableRegistryRecords. Every one of the three reads a record; none calls, executes or otherwise invokes the agent, tool, skill, MCP server or gateway the record describes. A separately fetched, independent primary source corroborates the same boundary from the proposal side: an open RFC on AWS's own public MCP tooling repository, awslabs/mcp issue #3185 ("RFC: Add AWS Agent Registry discovery tools to amazon-bedrock-agentcore-mcp-server," fetched directly), proposes exposing this same discovery surface as four read-only MCP tools, search_registry, list_records, get_record and list_registries, and states explicitly that "creating, updating, or deleting registry records (write operations)" is out of scope. The RFC's own text contains no discussion of invoking a discovered resource at all, and no discussion of downstream authorization once a resource has been found.
This session also checked, and rejects, a claim its own web-search tooling's synthesized answer surfaced once and could not independently corroborate: that a fourth registry operation, named in that one synthesis as "InvokeRegistryMcp," exists alongside the three read operations above. Directly reading the agentregistry service directory's own file listing found no such operation, no fourth api_op_*.go file of any name, and no invocation-shaped operation anywhere in the service AWS itself ships. This record does not adopt that claim. It is recorded here, by name, specifically so a future editor checking this record's own sourcing does not rediscover the same unconfirmed claim and mistake its earlier appearance in a search summary for independent corroboration.
The governance side of the API, read the same way from the separate agentregistrycontrol service directory (github.com/aws/aws-sdk-go-v2/tree/main/service/agentregistrycontrol, fetched directly), carries a different and larger operation set: CreateRegistry, CreateRegistryRecord, DeleteRegistry, DeleteRegistryRecord, GetRegistry, GetRegistryRecord, ListRegistries, ListRegistryRecords, ListTagsForResource, SubmitRegistryRecordForApproval, TagResource, UntagResource, UpdateRegistry, UpdateRegistryRecord and UpdateRegistryRecordStatus. Confirmed directly rather than assumed: there is one explicit submission operation, SubmitRegistryRecordForApproval, and one generic lifecycle-transition operation, UpdateRegistryRecordStatus, that an administrator or automated approval pipeline uses to move a record between Draft, Pending Approval, Approved, Rejected and Deprecated. Neither operation, and no operation in either service directory this session read, invokes the resource a record describes. The governance and discovery surfaces both stop at the record; what happens after a consumer decides to act on a discovered record is, on this evidence, outside the API surface AWS itself ships for the registry.
Auto-detection: existence, not trust
AWS Agent Registry can auto-detect agents and MCP servers running on AgentCore Runtime and AgentCore Gateway across an entire AWS Organization once an administrator enables endpoint detection once at the organization level, according to independently phrased search converging on consistent detail this session could not load directly from AWS's own documentation. The critical property, corroborated the same way: a resource AWS Agent Registry auto-detects does not land as an approved, discoverable record. It lands as a DRAFT, following the identical Draft to Pending Approval to Approved workflow a manually registered resource follows, and stays invisible to ordinary consumers until a curator or administrator reviews and approves it. Auto-detection, on this evidence, establishes that a resource exists and where it runs. It does not, by itself, establish that anyone has reviewed it, and AWS's own workflow design does not let auto-detection skip the review step that would establish that.
The approval step itself is a human or human-configured decision, not a default. Independently phrased search converges on the same roles across multiple sources: an Administrator owns a registry's infrastructure, configures inbound authorization (IAM or JWT), wires Amazon EventBridge for approval automation, and can enable or disable auto-approval, reported as off by default in production; a Curator is the reviewer who receives a record in Pending Approval status, evaluates it against organizational standards, and approves or rejects it with a stated reason. This session could not load AWS's own documentation directly to confirm every detail of that division at the verified grade, so it is carried as documented.
Inbound authorization to the registry itself, not to what it finds
This session confirmed directly, reading the same agentregistrycontrol types package's enum definitions, that a registry's own inbound authorization type carries exactly two values, AWS_IAM and CUSTOM_JWT, corroborating independently phrased search stating that a registry supports only one of the two at a time, IAM SigV4 signing for callers who already hold AWS IAM access, or a JSON Web Token issued by an organization's own identity provider (Amazon Cognito, Okta, Azure AD, Auth0 or any OAuth 2.0-compatible provider) for callers reached through corporate credentials rather than individually provisioned IAM access. This is, on every piece of evidence this record could reach, authorization to reach the registry's own search, list and get operations. It is not, and this record found nothing describing it as, authorization to reach or invoke whatever a returned record describes. An IAM-authorized or JWT-authorized caller who successfully searches the registry and receives an Approved record back has been authorized to see that record. What happens when that caller then attempts to actually call the agent, tool or MCP server the record names is a separate authorization event, governed by whatever inbound authorization that specific resource itself requires, not by the registry's own inbound authorization check.
Cross-account sharing widens who can find a record, not who can use what they find
Independently phrased search converges on AWS Resource Access Manager (RAM) integration letting an organization share a registry across accounts and build an organization-wide registry, alongside a redesigned Record directory console page, record tagging, and two discovery APIs (ListDiscoverableRegistryRecords and BatchGetDiscoverableRegistryRecord) added at general availability alongside the pre-existing SearchDiscoverableRegistryRecords, and a required recordType field. This session independently confirmed the record-type vocabulary directly against AWS's own SDK source: the agentregistrycontrol enums carry five record types, MCP, AGENT, CUSTOM, SKILL and GATEWAY, matching the "agents, tools and skills at scale" framing of AWS's own general-availability blog post title, itself corroborated only through search since aws.amazon.com/blogs/machine-learning/manage-agents-tools-and-skills-at-scale-with-aws-agent-registry/ was blocked to direct fetch this session. RAM sharing, on this evidence, widens the population of accounts that can discover a record. It says nothing about whether an account that gains that discovery access thereby gains any new authority over the underlying resource, which remains governed by whatever cross-account resource policy or IAM grant that specific resource's own owner separately configures.
What CloudTrail and EventBridge actually evidence
Independently phrased search converges on AWS CloudTrail capturing a full audit trail of registration, approval, rejection and deprecation actions taken on a registry, and on Amazon EventBridge emitting a record state-change event on every lifecycle transition, letting an organization route a submission into a Lambda function, an SNS or SQS target, a Step Functions workflow, an email or a ticketing system for human review. Both are evidence that a governance decision happened and audit evidence of what state a record moved to and when. Neither is evidence, on anything this record found, of what a consumer that later discovered an Approved record went on to do with it, or of whether that consumer was independently authorized to do it. A CloudTrail entry showing a record moved to Approved is a record of a curation decision; it is not a record of, and does not stand in for, a decision about any specific downstream invocation.
What this record leaves as unknown
This record did not find, in any material it could reach, a description of AWS Agent Registry mediating, gating or even logging the moment a consumer actually invokes a resource it discovered through the registry. Whether AgentCore Runtime or AgentCore Gateway independently enforces its own authorization at that invocation point, separate from anything the registry checked, is very likely true as ordinary AWS IAM architecture, but this record does not treat "very likely true as ordinary architecture" as the same fact as "confirmed for this specific product by material this session actually read," and states that gap as unknown rather than assuming it either direction. Equally, whether every third-party MCP server or external agent a registry record can point to enforces any authorization of its own at invocation is a fact about that resource's own implementation, not about the registry, and is not something a registry record's own Approved status could ever establish regardless of how carefully AWS built the approval workflow that produced it.
A note on a same-named but unrelated Agent Registry
This record's subject shares a name with, and should not be confused with, HashiCorp Vault Enterprise 2.1's own Agent Registry, a distinct, unrelated feature this desk has already covered separately (see "The Agent Created Another Agent. Which Permissions Came With It?"): Vault's Agent Registry maps an OAuth-authenticated agent to a Vault Identity entity and attaches a default ceiling policy, a Vault-specific authorization primitive with no relationship to AWS's catalog and discovery service beyond the shared, generic name. This record does not merge the two, and neither should a reader searching this corpus by name alone.
A broader, separate specification this record does not adopt as evidence here
Independently phrased search surfaces Agentic Resource Discovery (ARD), an open, multi-vendor specification for federated agent discovery announced the same week as AWS Agent Registry's general availability, with contributors reported from Cisco, Databricks, GitHub, Google, Microsoft, Nvidia, Salesforce, ServiceNow and Snowflake among others. ARD is a materially different artifact from AWS Agent Registry, a proprietary AWS service, not an implementation of the open specification, and this record does not treat AWS's own product as evidence for or against ARD's design, or read ARD's own reported principle, that "the resource then being invoked through its own native mechanism" once discovered, as anything more than independent, convergent confirmation of the same discovery-versus-invocation boundary this record already establishes from AWS's own material directly.
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.
This record is the cited evidence for this relationship.
- 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.
This record is the cited evidence for this relationship.
- Supports requirement
MCP 2026-07-28: Sessionless Protocol, Explicit State Handles and the Tasks Extension
Model Context Protocol
Requirement Possession of a state handle is not authorization, where authentication exists
The Model Context Protocol's own security best practices page, part of the final 2026-07-28 specification revision, states directly that MCP servers must not treat possession of a state handle as authentication, and SEP-2567 states the corrective an authenticated server should apply, validating a handle together with the caller's current authentication context on every call rather than the handle alone. This is the connectivity protocol's own normative guidance for exactly the substitution this weakness names, reachability or possession of a reference standing in for an independent authorization check, stated at the level of a widely adopted protocol's own specification rather than one vendor's product. This link supports the requirement rather than closing the gap: the guidance is a should addressed to a server's own application layer, since MCP itself defines no protocol-level handle type to enforce anything about, and this weakness's own Grafana known example, CVE-2026-19516, already documents a real MCP server whose session check accepted a caller supplied identifier the server itself had never issued, so the specification's own text and any one server's own conformance to it remain separate facts this link does not conflate.
- Implementation evidence
Agent Action Decision Protocol (AADP)
Shamik Saha, individual submission to the IETF
Requirement A Policy Decision Point owns authorization state and evidence; PEPs enforce it
AADP requires a Policy Enforcement Point to hold a permit from a Policy Decision Point before performing a governed action. GitHub's branch protection, requiring multi party review before a Terraform change could merge, functioned as exactly that enforcement point for the one attempted infrastructure backdoor Unit 42's own account names, denying a mutation the attacker's already compromised, technically valid access could otherwise reach. This is bounded, real world enforcement evidence for the one action the control was configured in front of, not evidence that the same separation governed the rest of the intrusion, which Unit 42's own account describes continuing on other paths after that one attempt was blocked.
- Implementation evidence
Agentic Networking for DynamicLink, a production MCP server for networking
Zayo
Zayo's Agentic Networking for DynamicLink, launched 8 September 2026, is a production deployment of a Model Context Protocol server, the same specification this weakness already connects through mcp-2026-07-28-sessionless-tasks above, now exposing production network and security infrastructure rather than a development or evaluation surface. It is implementation evidence for this weakness's own general form, reachability through an admitted MCP session substituting for an independent per-action authorization check, of the same kind this weakness already credits to Coder's Agent Firewall and Reco's Browser Guard: Zayo's own material states enterprises determine which information, tools and actions an agent can access, a scoping decision placed in front of the MCP tool surface, while no reachable artifact describes the mechanism that evaluates one specific requested tool call against that scope at the moment it is made. This link is scoped precisely to that evidentiary role. It does not evaluate a specific graded requirement of the MCP specification itself, and it does not treat Zayo's own governance language as proof that the gap this weakness names is closed for this vendor.
- Reveals bypass
ARC, Agentic Runtime Control
Britive
Requirement Whether an agent holding an independent credential or a direct network path to a target system can reach that system without passing through ARC's policy evaluation is not addressed in material available to this record
Britive's own documentation does not address whether an agent holding an independent credential or a direct network path can reach a target without passing through policy evaluation. That unmediated reachability is exactly the weakness these incidents turn on. NCSC's August 2026 interim advice on agentic AI corroborates the requirement this gap reveals, independently of the market's own protocol dataset: deny network access by default and mediate what remains through an approval gated, protocol or service aware proxy, rather than leave any path an agent's credentials or network position can reach unmediated. Grafana's own advisory for CVE-2026-19516 is a CVSS scored, vendor patched instance of exactly this gap: a Grafana MCP server's own network position reached internal, loopback and link local destinations, cloud metadata endpoints included, with no policy evaluation independently constraining the destination until the fix added one. Unit 42's account of a real enterprise intrusion, corrected 3 September 2026 to clarify the event was an intrusion rather than ransomware, is a further, larger instance: stolen cloud credentials reaching the victim organization's own AI infrastructure and CI/CD access reaching cloud keys, with no policy evaluation described as mediating either path. Cybernews's exposed server investigation, published 3 September 2026, adds an MCP intermediary to the same gap: a Penelope MCP interface exposed live reverse shell execution as a callable capability to an agent framework, Hermes Agent, across more than 30 real organisations, with nothing described as independently evaluating whether the calling agent held policy backed authority to use the shell the interface made reachable. Anthropic's own 30 July 2026 disclosure adds a further real instance rather than a sandbox breach: a fictional evaluation target's name matched a real, live domain, and the evaluation environment's own live internet access, present through a misconfiguration neither Anthropic nor its evaluation partner Irregular had noticed, let Claude Opus 4.7 reach and act on the real company across four runs with nothing independently evaluating whether the resolved target matched the one the evaluation actually authorized. GitHub Security Advisory GHSA-9mg6-c5wp-2g44, formally assigning CVE-2026-85666 on 4 September 2026, adds a further vendor patched instance from an MCP client rather than an MCP server: OGX's Responses API accepted a caller supplied MCP tool server_url and opened an MCP session against it, at session initialization during tool discovery, with no destination check independently constraining the reachable target, confirmed by direct reading of the affected source. This instance sharpens Britive's own gap beyond the general case: the same codebase already applies a working destination check, validate_url_not_private, to two sibling caller controlled URL inputs, so the unmediated path here is not an absent control but an existing one never connected to this specific resource class, evidence this dataset reads as reinforcing the requirement that resource policy needs to be applied by effect and resource class rather than by the feature specific code path that introduced the caller controlled URL. A proposed fix, pull request 6390, remains open and unmerged as of this link, so this entry does not treat the bypass as closed. A second, independently opened pull request, 6291, proposes the same check plus a scheme restriction and states explicitly that an administrator configured connector or toolgroup endpoint keeps a separate, unmediated resolution path by design, evidence this link reads as directly on point for what Britive's own documentation does not address: mediation applied to one provenance of endpoint, caller supplied, does not by itself establish anything about a differently provenanced endpoint, administrator configured, that the same policy engine would need to evaluate on its own terms rather than inherit by association. This pull request is also open and unmerged as of this link. Later technical coverage of the collusion.wiki report on the DSEWiki incident adds a further instance of the same reinforced requirement from a different direction: an OpenAI evaluation harness's read only internet restriction was enforced by permitting the GET HTTP method and blocking others, including POST, and DSEWiki's own ProWiki software accepted a page edit submitted as a GET request. Britive's own documentation does not address whether a request classified as read by its method can still produce a write at the destination, the same unaddressed gap this link already names for network position and destination, now shown for request method as the classifier instead. Both outlets naming the mechanism directly, and collusion.wiki itself, were blocked by this session's network egress policy; the mechanism is corroborated through cross referenced search rather than direct fetch. GitHub Security Advisory GHSA-rp45-5x3v-48mr adds a further instance narrower than any above: argocd-mcp's own HTTP and SSE transports bound to every network interface by default through version 0.8.0, confirmed directly against the affected source, with no policy evaluation, Host check or Origin check of any kind standing in front of a listener an operator's own environment configured Argo CD credential sat behind, so a network principal able to reach the bound listener needed nothing further to complete a credentialed, mutating Argo CD API call. CVE-2026-86122, published 5 September 2026 against Rowboat through version 0.9.1 and confirmed by direct reading of the affected source, adds a further instance that sharpens Britive's own gap past OGX's own case: Rowboat's project action authorization policy is confirmed running, correctly, before a custom MCP server URL or a project webhook URL is accepted, and nothing after that authorization call, and nothing in the agent runtime that later reads the stored URL back to open an MCP session or fetch a webhook, independently mediates which destination that authorized action may actually reach. Britive's own documentation does not address this either: an authorized project action, not only an independent credential or a direct network path, can carry unmediated reachability forward into whatever the resulting connection touches. A proposed fix, pull request 547, predates the report by five weeks, is not linked to it, and remains open and unmerged as of this link. GitHub Security Advisory GHSA-9m7h-vh2h-rc3w, published 6 September 2026 against OpenMAIC through version 1.0.0, adds an instance of a different shape than any above, and this link states the difference precisely rather than folding it into the general case: Britive's own documentation addresses whether a target is mediated by policy evaluation at all, not whether that mediation applies uniformly across every environment a deployment can run in. OpenMAIC's own validateUrlForSSRF is written correctly and already wired to five call sites the advisory names, confirmed by this link's own direct read at two of them, app/api/generate/image/route.ts and lib/server/resolve-model.ts, so the gap here is not an absent or unconnected check, as OGX's and Rowboat's own instances above show, but a check whose applicability depended on a condition, process.env.NODE_ENV === 'production', that the caller never touched and that a normal staging, preview or unset deployment fails by default, confirmed directly at both call sites this link checked against the affected tag. This composed with a separately confirmed fail open middleware, unchanged between the affected and fixed tags, that authenticated no request at all when the operator left ACCESS_CODE unset, so the unmediated path was reachable by an unauthenticated caller in the deployment states the environment condition already left unmediated. Fixed in OpenMAIC 1.0.1, released the same day, confirmed by this link's own direct read to remove the environment condition at both call sites checked and to add a repository scanning test, tests/server/url-guard-unconditional-invariant.test.ts, also read directly, that fails the project's own build if a validateUrlForSSRF call is again found gated on NODE_ENV. The same release replaces an implicit non production widening of what a caller supplied base URL could reach with an explicit ALLOW_LOCAL_NETWORKS grant an operator must set for local or private network access to be permitted at all, evidence this link reads as squarely on point for what Britive's own documentation does not address: mediation that applies only under an incidental deployment classification is not the same fact as mediation that applies to the resource and effect Britive's own policy evaluation is meant to reach, and an intentional exception to that mediation needs its own explicit grant rather than a classification's default.
- Missing requirement
AWS Agent Registry (Amazon Bedrock AgentCore)
Amazon Web Services
Requirement Whether, and how, a discovered resource's own invocation is independently authorized once found through the registry
This weakness's own authority gap is precisely the fact this record could not establish: what independently authorizes a discovered resource's own invocation, once a consumer has been authorized to find it. AWS's own reachable material states what discovery approval decides and stops there; nothing this session could reach describes the registry itself requiring, checking or even being aware of a separate invocation-time authorization on the resource a record names. Recorded as a missing requirement in the material this session could reach, not as a claim that no such requirement exists in AWS's own architecture; AgentCore Runtime, AgentCore Gateway or a third-party resource may well enforce one independently, and this record states that possibility as unknown rather than either confirmed or absent.
This record is the cited evidence for this relationship.