TL;DR: API key creation flows for Anthropic, OpenAI, and AWS Bedrock can be abused with JavaScript alone when browser cookies or local storage expose session material, letting a malicious extension or compromised agent skill mint persistent credentials without MFA or expiry, according to ActiveFence. The real issue is that session-bound identity assumptions do not hold when secret creation is reachable from the browser runtime.
NHIMG editorial — based on content published by ActiveFence: JavaScript Is All You Need: Creating API Keys for Fun and Profit
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.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: What breaks when API key creation is available from a browser session?
A: The boundary between authentication and credential issuance breaks.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read ActiveFence's analysis of JavaScript-only API key creation and NHI exposure →
JavaScript-only API key creation: are your controls keeping up?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: JavaScript-only API key creation exposes NHI trust gaps