AI-built sites leak OpenAI, Stripe and Slack secrets in code

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cyble's report: AI-built sites are exposing live OpenAI, Stripe, Slack and database secrets in browser-delivered code, and template cloning can spread one leak across many domains.

Why it matters: This matters because any secret embedded in client-side code becomes a reusable attack path against billing, data and cloud control planes, and cloned deployments can magnify one mistake across an entire fleet.

By the numbers:

• Cyble found 35 genuine private credentials on 22,306 AI-built sites it identified.

Context

AI app-builders compress the time between idea and deployment, but they also compress the time available to verify what the generated site ships to the browser. When secrets are embedded in client-delivered code, the public page becomes the access path rather than the control boundary.

The governance gap is not AI generation itself. It is the assumption that secrets can be placed wherever the application renders cleanly, even when that rendering path is public. That pattern matters in identity and NHI programmes because API keys, service tokens and webhooks function as machine credentials, not harmless configuration.

The risk is most acute when builders encourage template reuse across multiple domains. A single exposed secret can then become fleet-wide exposure, which is atypical for well-governed application delivery but increasingly common in no-code and AI-assisted publishing environments.

Key questions

Q: How do AI-built websites leak secrets into browser code?

A: AI-built websites leak secrets when builders place private credentials into fields or template components that are rendered into the front-end bundle. Anything shipped to the browser can be inspected by a visitor, so the issue is not just accidental disclosure but exposing a working machine credential in a publicly readable artefact.

Q: Why do exposed API keys and weak API controls create outsized breach risk?

A: Exposed API keys are powerful because they often grant direct access to applications, data, and automation paths without the friction of interactive login. If keys are reused, overprivileged, or poorly monitored, a single leak can enable broad unauthorized access and rapid abuse. API controls matter because digital services increasingly depend on machine-to-machine access that attackers can exploit quietly.

Q: How should teams rotate a secret that has already been public?

A: Revoke the exposed secret, issue a new one, and update every system that used the old value, then rotate it immediately. If the secret cannot be revoked in place, replace the credential, check logs and audit trails for misuse, and treat any dependent tokens, certificates, or API keys as potentially compromised until reissued.

Q: What is the difference between a publishable key and a secret key?

A: A publishable key is meant to be embedded in client-side code and identifies the application, while a secret key authenticates the server or backend and must be kept confidential. The secret key can usually create, read, or modify sensitive resources, whereas the publishable key is limited to non-sensitive public operations.

Technical breakdown

Why client-side secret exposure is different from ordinary configuration leakage

Client-side exposure matters because the browser is not a trusted execution environment. Anything delivered in the page source, JavaScript bundle or visible network response can be inspected, copied and replayed by an attacker without bypassing authentication. That is why a secret embedded in front-end code is materially different from a hidden backend variable. In practice, the same leaked value can act as a billing token, an API authenticator or a direct control-plane credential depending on the service. The security issue is not only disclosure, but immediate reusability at machine speed. See the API Key Management Guide.

Practical implication: Move every credential that can mutate data, spend money or access production systems out of browser-delivered code.

Why template cloning turns one secret into a fleet-wide problem

Template reuse is efficient for publishing, but dangerous when the template includes a live credential. Each cloned domain inherits the same secret, so the blast radius is defined by how many sites copy the template rather than by how many operators understand the secret. That creates a governance problem across environments, not a one-off coding mistake. If one bundle contains a Slack webhook, Stripe secret or service token, the attacker does not need to rediscover it on every site. One successful inspection of the template can expose the full fleet. Read Guide to the Secret Sprawl Challenge.

Practical implication: Treat cloned sites as one secret-sharing estate and verify that no reusable credential is embedded before replication.

How browser-safe keys differ from private credentials

Not every key exposed in a front-end bundle is equally dangerous. Browser-safe identifiers such as publishable keys, anon keys or reCAPTCHA site keys are designed to be visible, while private credentials such as secret keys, service-role JWTs and database tokens are not. The control failure is confusing visibility with legitimacy. A visible key is safe only when it has no authority to act on behalf of the account or backend. Once a browser-visible value can charge a card, read records, post messages or bypass access rules, it has crossed from configuration into credential abuse territory. See the Secrets Management Guide.

Practical implication: Classify every shipped key by the privilege it carries, not by whether it appears to work in the browser.

Threat narrative

Attacker objective: The attacker wants reusable access to accounts, APIs, databases or cloud resources that can be exploited directly from the exposed secret.

1. Entry occurs when an attacker loads a public AI-built site and inspects the shipped front-end code for embedded credentials.
2. Credential access follows when the attacker copies live OpenAI, Stripe, Slack, AWS or database tokens directly from the browser-delivered bundle.
3. Escalation occurs when the same secret is reused across cloned domains, giving the attacker access to every site built from the template.
4. Impact is billing abuse, data theft, API misuse, backend modification or internal phishing using the compromised machine credential.

Breaches seen in the wild

• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
• Microsoft Azure OpenAI abuse by Storm-2139: Storm-2139 used API keys leaked by Microsoft customers to hijack Azure OpenAI, bypass safety guardrails and resell access to generate harmful content.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Client-side secret leakage has become an AI-builder governance problem, not just a developer mistake. The article shows that the secret can be generated into the page as part of the build process, which means the publishing workflow itself has to be treated as a control point. When the browser can see the credential, the account behind it is already in a weaker security posture than the owner intended. Practitioners should treat every generated front-end as an untrusted distribution surface.

Fleet-wide template reuse creates a new form of secret sprawl. A single secret copied into a reusable site template turns one publishing decision into many exposed identities or accounts. That is the same structural issue that secret sprawl creates in other delivery pipelines, except here the replication is accelerated by AI-assisted publishing. The governance failure is not only leakage, but repeated inheritance of the same credential across domains. Security teams should manage clone sets as a shared exposure domain.

Machine credentials deserve the same lifecycle discipline as privileged human accounts. OpenAI keys, Stripe secrets, Slack webhooks and service-role tokens all act as standing access, even if they are stored in application code rather than an IAM console. That makes the boundary between application development and identity governance much thinner than many teams assume. The practical conclusion is simple: if a secret can act on behalf of a system, it needs ownership, scoping, rotation and revocation controls.

Browser exposure changes the meaning of least privilege. A secret that is safe in a backend vault is unsafe once copied into a client bundle, because the access path has expanded from controlled runtime to any page visitor. The field-level lesson is that privilege must be judged by where the credential can execute, not where it was created. Teams that publish AI-built apps need a release gate for secrets, not just a scanning pass after launch.

OpenAI, Stripe and database tokens in browser code show a broader trust collapse between build speed and control verification. AI app-builders reduce the work needed to publish, but they do not verify that the generated artefact is safe to expose. That leaves identity and data access decisions embedded in templating choices rather than policy. The result is a governance gap that security teams need to close before scale turns repetition into systemic exposure.

From our research library:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: API Key Management Guide

What this signals

Secret sprawl now includes generated front ends. The old assumption was that secrets leak mainly through repositories or misconfigured pipelines. AI builders extend that risk into the published page itself, which means release processes need a secret check before any domain goes live.

Browser-delivered credentials should be treated as pre-compromised. Once a private key has shipped in public code, rotation is the minimum response and trust in that credential should be considered lost. That is especially true when one template is copied across multiple domains.

A recurring signal here is the widening gap between what is safe to expose and what is merely convenient to embed. Security teams should expect more sites to ship with harmless-looking keys beside genuinely dangerous ones, so classification and ownership need to happen before publishing, not after discovery.

For practitioners

• Block private secrets from client-delivered code Keep OpenAI sk- values, Stripe sk_live_ keys, service-role JWTs and webhook URLs in server-side functions or backend workflows, never in fields that ship to the browser.
• Classify every shipped key by authority Separate browser-safe values such as publishable keys and anon keys from credentials that can charge accounts, read data or bypass access rules, then remove the latter from front-end bundles.
• Treat cloned domains as one secret estate When a template is reused across multiple sites, assume any embedded credential is live on every copy and rotate or revoke it across the full fleet.
• Search released source for secret markers Scan generated page source and public bundles for sk-, sk_live_, service_role and hooks.slack.com before launch, because visible code is the attack surface attackers will inspect first.
• Scope response to the whole deployment set If one domain in a cloned environment exposes a private key, treat the entire template family as affected and review billing, database, cloud and messaging access together.

Key takeaways

• AI-generated sites can expose working machine credentials in the browser, which converts a publishing shortcut into an access-control problem.
• Template reuse across many domains turns a single embedded secret into a fleet-wide exposure event.
• The most effective control is to keep privileged credentials out of client-delivered code and rotate any secret that has already shipped.

Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · Ultimate Guide to NHIs: Static vs Dynamic Secrets · API Key Management Guide · Secrets Management Guide

Key terms

• Stripe Secret Key: A Stripe Secret Key is a server-side API key used to authenticate requests to the Stripe API. It carries authority to create, read, and modify account resources, so it must be kept off browsers and mobile apps and rotated if exposed.
• Supabase Service-Role JWT: A Supabase Service-Role JWT is a high-privilege JSON Web Token used by backend code to access Supabase with elevated rights. It bypasses normal row-level restrictions, so it must never be exposed to clients and should be protected like a root-level secret.
• Template Fleet: A template fleet is a managed set of template-based resources deployed in parallel, often across hosts, clusters, or environments. In IT operations it usually means many similar instances created from the same template, which makes configuration consistency, patching, and drift control easier.
• OpenAI API Key Exposure: OpenAI API key exposure is the accidental or malicious disclosure of a secret used to authenticate requests to OpenAI services. An exposed key can be reused by attackers to access models, generate costs, or move into connected systems, so detection, rotation, scope limits, and secret management are critical.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the way credentials are created, exposed and revoked across modern delivery pipelines.