Signing In Without Actually Signing In
Okta Threat Intelligence reports that a single 7 GB infostealer dump pulled from 5,871 infected machines across 162 countries carried 44,791 JSON Web Tokens, 555 of them tied to AI-service authentication, 2,937 authentication-related JWEs, and 24 still-valid API keys for Gemini, OpenAI, Groq and OpenRouter. A valid session token or API key lets a criminal into a paid AI account with no password prompt and no MFA challenge, because the credential itself is what gets checked, not who is currently holding it.
Event analysed: . This analysis was published on 13 September 2026.
No. Okta's own research states plainly that a valid JWT or API key can be replayed to obtain direct account access while bypassing both password authentication and MFA, because the check that runs is whether the credential itself verifies, not whether its current possessor is the party the credential was ever issued to. That is a capability fact, not an authority fact, and Moona's own Authority Resolution engine already carries the distinction this research corroborates: a technical capability or credential is evidenced in the canonical Decision Context, but never promoted into authority, and the dimension the resolver dedicates to it, credentials_capability, is permanently fixed at not_evaluated so that no comparison result can ever convert possession into permission.
Okta Threat Intelligence, under director Jeremy Kirk, published "Signing in without actually signing in" on 9 September 2026, reporting on a single infostealer log dump released on a Telegram channel on 2 August 2026: 7 GB of data pulled from 5,871 infected machines across 162 countries. Inside that one dump, Okta counted 44,791 unique JSON Web Tokens, of which 555 were assessed as likely tied to AI-service authentication across providers including Google, Microsoft, Anthropic, Amazon, Cursor, Character.ai, Poe.com, Notion, Gamma and Pika AI, plus 2,937 authentication-related JSON Web Encryption structures, the majority associated with OpenAI. Of the JWTs and JWEs in the dataset, 1,843 had not expired at the moment the dump was released. A separate scan of the same dump using TruffleHog surfaced 24 still-valid API keys across four AI-related services: Google Gemini, OpenAI, Groq and OpenRouter.
This record could not independently fetch okta.com in this session: every route this session attempted, including the en-gb and the bare www.okta.com paths, was blocked outright by this session's own network egress policy, the same class of domain-level block this desk's other records document for ietf.org, arxiv.org and several other domains. What follows rests on repeated, independently phrased web search passes whose results converge on identical figures across multiple independent outlets, held at this desk's manual-review evidence grade rather than a direct read of Okta's own filed text. The Hacker News's own coverage, and a security-practitioner blog post addressed to CISOs, each independently state the same core figures Okta's research is reported to carry: 5,871 infected machines, 7 GB, 162 countries, 44,791 JWTs, 555 AI-authentication-related, 2,937 JWEs, 1,843 unexpired JWTs and JWEs, and 24 still-valid API keys across Gemini, OpenAI, Groq and OpenRouter. Both of those outlets, and okta.com itself, were blocked to direct fetch on every attempted route in this session. This record treats that convergence, not a claim of direct verification, as the basis for the aggregate figures above. A further, more granular breakdown, unexpired-token counts of 9,213 for Google, 1,763 for Microsoft, 164 for Anthropic, 254 for Amazon and 16 for Cursor specifically, was supplied to this session as part of its own commissioning brief rather than independently located in convergent search results, and this record states that breakdown at that lower evidence grade rather than promoting it to the same standing as the convergently corroborated aggregate figures.
The mechanism: a credential proves itself, not its holder
What makes this dataset relevant to Moona's own canonical thesis is not the volume, it is the mechanism convergent reporting attributes to Okta directly: a valid JWT can be abused to obtain direct account access while bypassing both a username-and-password check and multi-factor authentication, because replaying a session secret or an API key satisfies exactly the check a service actually runs, that the credential verifies, and nothing further. An API key is a long-lived credential with no MFA step of its own and typically keeps working until someone rotates it; a stolen but unexpired session token carries the same property for as long as it remains valid. Convergent reporting also states the resulting exposure in cost terms directly on point for Moona's own existing cost-connection: an attacker in possession of a still-valid AI API key can weaponize it for espionage, extortion or resource theft, and run up token bills the legitimate account holder did not authorize, with the same reporting separately describing black-market resale of stolen AI-account access, Claude, Cursor, ChatGPT and Gemini logins traded with 24/7 support and money-back guarantees, as the commercial layer built on exactly this substitution.
This is precisely the distinction Moona's canonical Authority Resolution engine already draws, and draws for every Decision Context, not only ones this evidence touches. DecisionContext.technicalCapability in src/content/moona-knowledge/authority-model.ts exists to hold exactly this fact, "a stated technical capability or credential (e.g. 'has valid database credentials'). Deliberately never treated as authority evidence", and assessAuthorityDelta in authority-resolution.ts carries a dedicated comparison dimension, credentials_capability, whose result is permanently fixed at not_evaluated with the reasoning stated inline: "Credentials and technical capability are not evaluated as authority evidence." A stolen, replayed or otherwise illegitimately held JWT, JWE or API key is, on Moona's own model, evidence on that one dimension and no other; it never moves the actor, delegation, approval-provenance, environment or any other dimension the resolver actually decides on. This record's own review of that code confirms the invariant already holds exactly as this evidence would require, and proposes no change to it: a credential proving reachability is not, and under this evidence should not become, a credential proving authorization.
Connected to AEW-008, not a new weakness
Moona's Risk Registry already carries this exact substitution as a published weakness, AEW-008, reachability treated as authority: "The authority required to act on a resource is absent, but the resource is reachable, and reachability substitutes for the missing authority." AEW-008's own known examples already include stolen cloud credentials reaching a victim organization's AI infrastructure (Unit 42's account of a real intrusion) and a compromised credential opening an MCP connection onto reachable capability (Cybernews's Penelope/Hermes Agent report); this dataset extends the same pattern from individually reported intrusions to population-scale, cross-provider evidence: thousands of technically valid AI-service tokens and two dozen live API keys, reachable to whoever now holds the infostealer dump rather than to whoever the credential was issued to, with nothing about the credential's own cryptographic validity distinguishing the two. This record connects the evidence to AEW-008 as a further known example rather than proposing a new weakness: the mechanism, a technically valid credential substituting for an authorization check that never independently runs, is the one AEW-008 already states, evidenced here at a materially larger and more systematically measured scale than any single vendor's own disclosure.
Connected to the existing post-authentication reassessment requirement
Convergent reporting also states Okta's own corrective recommendation directly, and it is not a new requirement Moona's own protocol dataset has to invent: secure access to AI systems, monitor for session-token reuse, scope API keys narrowly, and prefer OAuth 2.0 flows with short-lived tokens that expire quickly if stolen. Okta's own product material, reached only through convergent search in this session, describes a Session Protection capability that continuously monitors active sessions after authentication and re-evaluates policy whenever a critical context change occurs, an IP or device change, or when it receives risk telemetry from a third-party tool over the Shared Signals Framework. Moona's own Protocol dataset already carries the identical corrective principle under a different vendor: Britive's Agentic Runtime Control record (britive-arc-2026-08-24) documents native support for the OpenID Shared Signals Framework, consuming CAEP and RISC events to trigger automated session termination, forced logout or step-up authentication on exactly the same critical-context-change trigger, graded documented under the property ssf-caep-risc-continuous-authorization. This record connects Okta's own research to that existing protocol requirement as further supporting evidence for the same corrective, rather than creating a parallel one: a session or credential validated once at authentication time is not thereby validated for the duration of its technical lifetime, and both vendors' own material states a post-authentication re-evaluation trigger as the answer, independently of each other.
What this evidence does not establish, and what it does not change
This record does not treat Okta's dataset as evidence about any specific Moona-relevant agent, delegation chain or execution decision; it is evidence about a general population of stolen AI credentials, not about any one actor's authority in any one Decision Context. It does not establish that every one of the 555 AI-authentication JWTs or 24 live API keys were ever actually used to cause a consequential effect, only that they were technically capable of it, which is exactly the capability-not-authority distinction this record exists to state. It does not warrant a new AEW: the substitution is the one AEW-008 already names, now evidenced at a larger, differently-sourced scale. It does not warrant a resolver change: Moona's own credentials_capability dimension and technicalCapability field already keep credential possession structurally separate from every authority-bearing comparison the resolver performs, and this evidence corroborates that design rather than exposing a gap in it. Where this record's own verification is weakest, it says so directly: okta.com and the two independent outlets this record checked for convergence were each blocked to direct fetch in this session, the granular per-provider unexpired-token breakdown rests on this session's own commissioning brief rather than independently located convergent search, and whether any specific one of the 24 live API keys or 555 AI-authentication JWTs was subsequently redeemed for an actual, costed inference run is not established by anything this record could reach and is left unknown rather than assumed either way.
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.
This record is the cited evidence for this relationship.
- Supports requirement
AWS Agent Registry (Amazon Bedrock AgentCore)
Amazon Web Services
Requirement The registry's own discovery API carries exactly three operations, all reads, no invocation
This weakness's own response pattern calls for authorizing a resource independently of whatever makes it reachable, never letting reachability itself substitute for the missing check. AWS Agent Registry's own discovery API, confirmed directly from AWS's published SDK source to carry exactly three operations, BatchGetDiscoverableRegistryRecord, ListDiscoverableRegistryRecords and SearchDiscoverableRegistryRecords, all reads, with no operation that invokes a discovered resource, is architectural evidence of exactly that separation: a caller who successfully searches the registry gains the ability to find a record, not any ability the registry itself grants to act on what the record describes. Recorded as design evidence that a governed discovery catalog can keep discoverability and invocation authority structurally apart, not as a claim that every resource a record points to independently enforces its own authorization at the moment of invocation, which this record leaves unknown.
- Supports requirement
AWS Agent Registry (Amazon Bedrock AgentCore)
Amazon Web Services
Requirement AgentCore Runtime and Gateway resources AWS Agent Registry auto-detects land as unapproved Draft records, not as discoverable Approved ones
This weakness names reachability substituting for authority precisely where nothing independently checks a resource before it becomes actionable. AWS Agent Registry's own auto-detection of AgentCore Runtime and Gateway resources across an organization is, on its face, the kind of automatic admission this weakness's known examples already warn about; what keeps it from instantiating the weakness here is that a resource the registry auto-detects lands as an unreviewed Draft record, not as an Approved, discoverable one, so existing is kept apart from approved even when the existence itself was discovered automatically rather than declared by a publisher. Recorded as design evidence for this weakness's own corrective, not as a claim that every deployment actually enables the review step before treating an auto-detected resource as caught up, which this record did not independently confirm.
- Supports requirement
MCP 2026-07-28: Sessionless Protocol, Explicit State Handles and the Tasks Extension
Model Context Protocol
Requirement Possession of a state handle is not authorization, where authentication exists
The Model Context Protocol's own security best practices page, part of the final 2026-07-28 specification revision, states directly that MCP servers must not treat possession of a state handle as authentication, and SEP-2567 states the corrective an authenticated server should apply, validating a handle together with the caller's current authentication context on every call rather than the handle alone. This is the connectivity protocol's own normative guidance for exactly the substitution this weakness names, reachability or possession of a reference standing in for an independent authorization check, stated at the level of a widely adopted protocol's own specification rather than one vendor's product. This link supports the requirement rather than closing the gap: the guidance is a should addressed to a server's own application layer, since MCP itself defines no protocol-level handle type to enforce anything about, and this weakness's own Grafana known example, CVE-2026-19516, already documents a real MCP server whose session check accepted a caller supplied identifier the server itself had never issued, so the specification's own text and any one server's own conformance to it remain separate facts this link does not conflate.
- Implementation evidence
Agent Action Decision Protocol (AADP)
Shamik Saha, individual submission to the IETF
Requirement A Policy Decision Point owns authorization state and evidence; PEPs enforce it
AADP requires a Policy Enforcement Point to hold a permit from a Policy Decision Point before performing a governed action. GitHub's branch protection, requiring multi party review before a Terraform change could merge, functioned as exactly that enforcement point for the one attempted infrastructure backdoor Unit 42's own account names, denying a mutation the attacker's already compromised, technically valid access could otherwise reach. This is bounded, real world enforcement evidence for the one action the control was configured in front of, not evidence that the same separation governed the rest of the intrusion, which Unit 42's own account describes continuing on other paths after that one attempt was blocked.
- Implementation evidence
Agentic Networking for DynamicLink, a production MCP server for networking
Zayo
Zayo's Agentic Networking for DynamicLink, launched 8 September 2026, is a production deployment of a Model Context Protocol server, the same specification this weakness already connects through mcp-2026-07-28-sessionless-tasks above, now exposing production network and security infrastructure rather than a development or evaluation surface. It is implementation evidence for this weakness's own general form, reachability through an admitted MCP session substituting for an independent per-action authorization check, of the same kind this weakness already credits to Coder's Agent Firewall and Reco's Browser Guard: Zayo's own material states enterprises determine which information, tools and actions an agent can access, a scoping decision placed in front of the MCP tool surface, while no reachable artifact describes the mechanism that evaluates one specific requested tool call against that scope at the moment it is made. This link is scoped precisely to that evidentiary role. It does not evaluate a specific graded requirement of the MCP specification itself, and it does not treat Zayo's own governance language as proof that the gap this weakness names is closed for this vendor.
- Reveals bypass
ARC, Agentic Runtime Control
Britive
Requirement Whether an agent holding an independent credential or a direct network path to a target system can reach that system without passing through ARC's policy evaluation is not addressed in material available to this record
Britive's own documentation does not address whether an agent holding an independent credential or a direct network path can reach a target without passing through policy evaluation. That unmediated reachability is exactly the weakness these incidents turn on. NCSC's August 2026 interim advice on agentic AI corroborates the requirement this gap reveals, independently of the market's own protocol dataset: deny network access by default and mediate what remains through an approval gated, protocol or service aware proxy, rather than leave any path an agent's credentials or network position can reach unmediated. Grafana's own advisory for CVE-2026-19516 is a CVSS scored, vendor patched instance of exactly this gap: a Grafana MCP server's own network position reached internal, loopback and link local destinations, cloud metadata endpoints included, with no policy evaluation independently constraining the destination until the fix added one. Unit 42's account of a real enterprise intrusion, corrected 3 September 2026 to clarify the event was an intrusion rather than ransomware, is a further, larger instance: stolen cloud credentials reaching the victim organization's own AI infrastructure and CI/CD access reaching cloud keys, with no policy evaluation described as mediating either path. Cybernews's exposed server investigation, published 3 September 2026, adds an MCP intermediary to the same gap: a Penelope MCP interface exposed live reverse shell execution as a callable capability to an agent framework, Hermes Agent, across more than 30 real organisations, with nothing described as independently evaluating whether the calling agent held policy backed authority to use the shell the interface made reachable. Anthropic's own 30 July 2026 disclosure adds a further real instance rather than a sandbox breach: a fictional evaluation target's name matched a real, live domain, and the evaluation environment's own live internet access, present through a misconfiguration neither Anthropic nor its evaluation partner Irregular had noticed, let Claude Opus 4.7 reach and act on the real company across four runs with nothing independently evaluating whether the resolved target matched the one the evaluation actually authorized. GitHub Security Advisory GHSA-9mg6-c5wp-2g44, formally assigning CVE-2026-85666 on 4 September 2026, adds a further vendor patched instance from an MCP client rather than an MCP server: OGX's Responses API accepted a caller supplied MCP tool server_url and opened an MCP session against it, at session initialization during tool discovery, with no destination check independently constraining the reachable target, confirmed by direct reading of the affected source. This instance sharpens Britive's own gap beyond the general case: the same codebase already applies a working destination check, validate_url_not_private, to two sibling caller controlled URL inputs, so the unmediated path here is not an absent control but an existing one never connected to this specific resource class, evidence this dataset reads as reinforcing the requirement that resource policy needs to be applied by effect and resource class rather than by the feature specific code path that introduced the caller controlled URL. A proposed fix, pull request 6390, remains open and unmerged as of this link, so this entry does not treat the bypass as closed. A second, independently opened pull request, 6291, proposes the same check plus a scheme restriction and states explicitly that an administrator configured connector or toolgroup endpoint keeps a separate, unmediated resolution path by design, evidence this link reads as directly on point for what Britive's own documentation does not address: mediation applied to one provenance of endpoint, caller supplied, does not by itself establish anything about a differently provenanced endpoint, administrator configured, that the same policy engine would need to evaluate on its own terms rather than inherit by association. This pull request is also open and unmerged as of this link. Later technical coverage of the collusion.wiki report on the DSEWiki incident adds a further instance of the same reinforced requirement from a different direction: an OpenAI evaluation harness's read only internet restriction was enforced by permitting the GET HTTP method and blocking others, including POST, and DSEWiki's own ProWiki software accepted a page edit submitted as a GET request. Britive's own documentation does not address whether a request classified as read by its method can still produce a write at the destination, the same unaddressed gap this link already names for network position and destination, now shown for request method as the classifier instead. Both outlets naming the mechanism directly, and collusion.wiki itself, were blocked by this session's network egress policy; the mechanism is corroborated through cross referenced search rather than direct fetch. GitHub Security Advisory GHSA-rp45-5x3v-48mr adds a further instance narrower than any above: argocd-mcp's own HTTP and SSE transports bound to every network interface by default through version 0.8.0, confirmed directly against the affected source, with no policy evaluation, Host check or Origin check of any kind standing in front of a listener an operator's own environment configured Argo CD credential sat behind, so a network principal able to reach the bound listener needed nothing further to complete a credentialed, mutating Argo CD API call. CVE-2026-86122, published 5 September 2026 against Rowboat through version 0.9.1 and confirmed by direct reading of the affected source, adds a further instance that sharpens Britive's own gap past OGX's own case: Rowboat's project action authorization policy is confirmed running, correctly, before a custom MCP server URL or a project webhook URL is accepted, and nothing after that authorization call, and nothing in the agent runtime that later reads the stored URL back to open an MCP session or fetch a webhook, independently mediates which destination that authorized action may actually reach. Britive's own documentation does not address this either: an authorized project action, not only an independent credential or a direct network path, can carry unmediated reachability forward into whatever the resulting connection touches. A proposed fix, pull request 547, predates the report by five weeks, is not linked to it, and remains open and unmerged as of this link. GitHub Security Advisory GHSA-9m7h-vh2h-rc3w, published 6 September 2026 against OpenMAIC through version 1.0.0, adds an instance of a different shape than any above, and this link states the difference precisely rather than folding it into the general case: Britive's own documentation addresses whether a target is mediated by policy evaluation at all, not whether that mediation applies uniformly across every environment a deployment can run in. OpenMAIC's own validateUrlForSSRF is written correctly and already wired to five call sites the advisory names, confirmed by this link's own direct read at two of them, app/api/generate/image/route.ts and lib/server/resolve-model.ts, so the gap here is not an absent or unconnected check, as OGX's and Rowboat's own instances above show, but a check whose applicability depended on a condition, process.env.NODE_ENV === 'production', that the caller never touched and that a normal staging, preview or unset deployment fails by default, confirmed directly at both call sites this link checked against the affected tag. This composed with a separately confirmed fail open middleware, unchanged between the affected and fixed tags, that authenticated no request at all when the operator left ACCESS_CODE unset, so the unmediated path was reachable by an unauthenticated caller in the deployment states the environment condition already left unmediated. Fixed in OpenMAIC 1.0.1, released the same day, confirmed by this link's own direct read to remove the environment condition at both call sites checked and to add a repository scanning test, tests/server/url-guard-unconditional-invariant.test.ts, also read directly, that fails the project's own build if a validateUrlForSSRF call is again found gated on NODE_ENV. The same release replaces an implicit non production widening of what a caller supplied base URL could reach with an explicit ALLOW_LOCAL_NETWORKS grant an operator must set for local or private network access to be permitted at all, evidence this link reads as squarely on point for what Britive's own documentation does not address: mediation that applies only under an incidental deployment classification is not the same fact as mediation that applies to the resource and effect Britive's own policy evaluation is meant to reach, and an intentional exception to that mediation needs its own explicit grant rather than a classification's default.
- Missing requirement
AWS Agent Registry (Amazon Bedrock AgentCore)
Amazon Web Services
Requirement Whether, and how, a discovered resource's own invocation is independently authorized once found through the registry
This weakness's own authority gap is precisely the fact this record could not establish: what independently authorizes a discovered resource's own invocation, once a consumer has been authorized to find it. AWS's own reachable material states what discovery approval decides and stops there; nothing this session could reach describes the registry itself requiring, checking or even being aware of a separate invocation-time authorization on the resource a record names. Recorded as a missing requirement in the material this session could reach, not as a claim that no such requirement exists in AWS's own architecture; AgentCore Runtime, AgentCore Gateway or a third-party resource may well enforce one independently, and this record states that possibility as unknown rather than either confirmed or absent.