JavaScript-only API key creation exposes NHI trust gaps

At a glance

What this is: ActiveFence demonstrates that API keys for major AI and cloud platforms can be created through browser-side JavaScript when session cookies or local storage expose the needed identity material.

Why it matters: This matters because IAM teams must treat browser-accessible session state as a credential creation pathway, not just a login surface, especially where NHI and agent tooling can silently mint durable access.

By the numbers:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read ActiveFence's analysis of JavaScript-only API key creation and NHI exposure

Context

API key creation is part of identity governance, not just application convenience. When a browser session can generate a long-lived credential, the control boundary has shifted from server-side authentication to client-side state, where cookie scope, local storage, and extension permissions become part of the trust model.

ActiveFence focuses on how that trust model breaks for AI and cloud platforms when API key issuance depends on material that JavaScript can read. That creates an NHI governance problem because the result is a durable secret tied to a session that was never meant to authorise persistent access.

The article’s examples are atypical in execution detail but typical in failure pattern: a session-bound workflow exposes a credential creation action to the browser runtime, and the browser runtime becomes the attacker’s control plane.

Key questions

Q: What breaks when API key creation is available from a browser session?

A: The boundary between authentication and credential issuance breaks. If a live browser session can mint a durable key, then any script, extension, or delegated tool that reaches that session can convert temporary access into standing access without a separate control. That is a lifecycle failure, not just a web security flaw.

Q: Why do browser-readable cookies and local storage create NHI risk?

A: Because they can contain enough identity material to bootstrap a new secret. Once JavaScript can read tokens or session state, it can often turn that access into API key creation, which gives attackers or rogue tools a persistent credential that survives the original session.

Q: How should security teams govern API keys used for generative AI access?

A: Treat them as machine identities with lifecycle controls, not as disposable developer conveniences. Each key should have an owner, a specific purpose, an expiry date, and a revocation path. Security teams should also scan repositories, CI/CD pipelines, logs, and collaboration tools so leaked keys are discovered before they become standing access.

Q: How can organisations reduce the risk from malicious extensions and agent skills?

A: Limit what delegated browser code can do inside authenticated consoles. Separate human console permissions from extension and agent permissions, deny access to secret-issuing endpoints by default, and review any workflow that lets non-human runtime code act with the same authority as the logged-in user.

Technical breakdown

Cookie-backed API key issuance in the browser

Some console flows use browser-authenticated sessions to create API keys through POST requests that inherit cookies automatically. If sensitive cookies are not HttpOnly and the endpoint trusts the session alone, JavaScript running in the page context can read identity material and submit a key-creation request with no separate approval step. That is not a login bypass in the classic sense. It is a privilege transition from authenticated session to durable credential issuance inside the browser trust boundary.

Practical implication: treat any browser-reachable key issuance endpoint as a privileged control plane and require step-up authentication before new secrets are minted.

Local storage and token extraction in AI console flows

Other console designs place OAuth or session material in local storage or in app state that the page can inspect. In that pattern, JavaScript can extract the bearer token, exchange it for a short-lived session token, and then create a new API key. The important technical detail is that the browser is not merely presenting identity, it is carrying the proof material needed to bootstrap a stronger credential. Once that bootstrap path exists, persistent access can outlive the original user session.

Practical implication: remove secret-bearing identity material from browser-readable storage and reassess every token exchange that can be chained into credential creation.

Agent skills and extensions as credential-minting pathways

Browser extensions and agent skills extend the attack surface because they can execute JavaScript in a context that already has authenticated access. When those components can call platform endpoints directly, they do not need to defeat MFA if the sensitive action is protected only by the existing session. That makes the issue broader than injection alone. Any delegated browser automation that can reach secret-creation APIs becomes a potential NHI compromise path if it inherits user trust without separate action authorization.

Practical implication: isolate agent and extension permissions from human console permissions, and block delegated browser tools from secret-issuing actions by default.

Threat narrative

Attacker objective: The attacker wants durable, reusable API credentials that survive session expiry and enable later access to AI and cloud services.

1. Entry occurs through a malicious browser extension, XSS payload, or compromised agent skill that runs JavaScript in an already authenticated browser session.
2. Escalation happens when the script reads cookies or local storage, extracts session material, and uses it to call API key creation endpoints that trust the browser session.
3. Impact is the issuance of a persistent API key that can be exfiltrated and reused outside the original session, extending access well beyond the user’s login window.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Session-backed secret issuance is the governance failure, not just cookie exposure: The problem is not only that JavaScript can read identity material. The deeper issue is that some platforms allow a live browser session to mint a durable credential without a second control boundary. That collapses the separation between transient authentication and persistent authorization. Practitioners should treat secret issuance as a privileged lifecycle event, not a routine API call.

Browser-readable identity state creates an NHI trust gap: If cookies or local storage contain enough material to create API keys, then the browser becomes part of the identity supply chain. That means extension permissions, page scripts, and agent skills all inherit the ability to move from session access to standing access. OWASP-NHI and Zero Trust thinking both point to the same conclusion: credential creation must not rely on ambient client trust.

Persistent API keys extend the blast radius of a single session compromise: The article shows why session expiry is not enough when the end product is a non-expiring secret. A short browser session can still produce a long-lived key that survives beyond detection windows. That changes the control objective from session security to key lifecycle governance, including creation, naming, scoping, and revocation.

Agentic browser automation and human browser misuse are converging on the same failure mode: A malicious extension and a compromised agent skill are different delivery mechanisms, but both exploit the same assumption that the browser will only act on behalf of the intended user. That assumption breaks when delegated runtime code can independently initiate credential issuance. The implication is that identity governance must distinguish between human approval, automated execution, and actual authority to mint secrets.

Runtime credential creation needs a named control concept: browser-side secret issuance debt: This is the accumulated risk created when platforms permit credentials to be created from client-visible identity state. The debt grows because every added console, extension, and agent integration increases the number of places where durable access can be minted. Practitioners should audit for this debt as a distinct governance category, not as a generic auth hardening issue.

From our research:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• That pattern reinforces why teams should read 52 NHI Breaches Analysis alongside secrets governance work, because exposed credentials are only valuable when lifecycle controls fail to remove them.

What this signals

Browser-side secret issuance debt: organisations should start treating any console flow that can mint a long-lived credential from a live browser session as accumulated governance debt. Once API key creation depends on client-visible state, extension permissions, agent skills, and page scripts all become part of the identity attack surface. The issue maps directly to OWASP Agentic AI Top 10 thinking around tool misuse and identity abuse.

With 64% of valid secrets leaked in 2022 still valid and exploitable today, the operational lesson is clear: detection without revocation does not contain browser-minted credentials. That is why lifecycle ownership matters as much as discovery, especially where persistent keys can be created from a session that should have remained transient.

Teams that are planning browser automation or agent-assisted console operations should re-evaluate whether those tools are allowed to touch secret-issuing endpoints at all. If a workflow can create credentials, it belongs in the same control family as privileged access, not in ordinary application scripting. The right question is not whether the browser is authenticated. It is whether the browser is authorised to mint standing access.

For practitioners

• Move API key creation behind step-up controls Require OTP, reauthentication, or separate approval before any new secret is minted, even when a user already has an active console session.
• Remove secret-bearing identity material from browser-readable storage Move sensitive cookies to HttpOnly scope and stop placing bearer tokens or session bootstrap data in local storage where JavaScript can extract them.
• Restrict delegated browser tools from secret-issuance endpoints Block extensions, agent skills, and automation contexts from calling API key creation routes unless they are explicitly authorised for that action.
• Inventory persistent keys created from session flows Track which consoles can create durable credentials from a live session and shorten revocation windows for any key that was minted through browser-accessible workflows.
• Classify browser console actions by privilege level Treat key minting, token exchange, and session escalation as privileged identity events that require governance review, logging, and ownership.

Key takeaways

• Browser-accessible API key creation turns a session into a credential factory, which is a governance failure not solved by login controls alone.
• The article’s evidence shows how JavaScript, extensions, and agent skills can extract session material and convert it into persistent access.
• Step-up approval, HttpOnly storage, and restricted secret-issuance endpoints are the controls that materially reduce this attack path.

Key terms

• Browser-Side Secret Issuance: A browser-driven flow that creates a durable credential from authenticated session state. The risk is not the login itself but the ability of client-side code to turn that login into a long-lived secret, often without a second approval step or separate trust boundary.
• Browser-Readable Identity State: Identity material stored where JavaScript can access it, such as cookies without HttpOnly or local storage. When that material can be read by scripts, extensions, or agent code, it becomes a bridge from temporary session access to persistent credential creation.
• Access-Path Drift: Access-path drift is the gap between what a security team believes can be reached or abused and what is actually reachable after applications, APIs, roles, and identity flows change. It is a common failure mode in fast-moving environments where controls and verification lag behind release cycles.
• Delegated Browser Access: Delegated browser access is the permission a user grants to software running inside the browser to act on their behalf or read their session context. It is a practical NHI concern because the delegated actor can observe sensitive content without needing separate credentials.

What's in the full article

ActiveFence's full blog covers the operational detail this post intentionally leaves for the source:

• The exact browser request flow used to create API keys for Claude, OpenAI, and AWS Bedrock.
• The JavaScript and cookie extraction patterns that make the attack work in practice.
• The proof-of-concept mechanics for turning session material into a persistent API key.
• The mitigation recommendations aimed at platform owners and end users.

👉 The full ActiveFence post covers the exploit paths, token handling details, and mitigation recommendations.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.