# Protect API Keys in AI-Built Apps: Storage & Rotation > An environment variable is not automatically a secret. Follow credentials from development through the deployed browser, backend, logs, and incident response. Official source: https://warhoundai.com/blog/protect-api-keys-ai-built-apps/ Published: 2026-10-19 Author: WarHoundAI Updated: 2026-11-12 ## Distinguish public configuration from private credentials A public project identifier and a private service credential can look similar in a configuration file while granting very different powers. For each value, identify its owner, permitted operations, environment, expiry, and exposure rules. Consult the provider documentation rather than assuming that a variable with the word key in its name must be private, or that a variable named public is safe. For example, some browser-facing database keys are designed to be public when suitable authorization policies protect the data. A database password or an administrative service credential has a different purpose and must stay in a trusted environment. Merely hiding either value in a minified file does not change its privileges. Treat the permissions behind a credential as the source of truth, and ensure access control applies the principle of least privilege as advised by the OWASP Secrets Management Cheat Sheet. ## Understand what the build sends to the browser Frontend frameworks commonly expose specially prefixed environment variables at build time. If a build substitutes a private key into client JavaScript, the resulting bundle contains the value regardless of whether the original environment file was excluded from version control. Browser developer tools, network requests, source maps, and public build artifacts are part of the exposure review. Inspect a production-style build using a harmless sentinel value in place of the real secret. Confirm that the sentinel does not appear in browser assets, static HTML, or downloadable configuration. Test the deployed behavior as well as the repository. Keep real private credentials in the backend or managed secret storage, and have server-side code call the external service after checking the user and action. ## Test access boundaries with a safe test matrix To verify access controls without risking production credentials, deploy a synthetic test matrix using limited-scope fixture keys. This matrix defines the expected allowed and denied outcomes for various actors attempting to read or use a secret. A typical safe test matrix includes the following expectations. An unauthenticated browser client requesting the raw key payload must receive an HTTP 401 denied outcome. An authenticated user calling a backend proxy endpoint should receive an HTTP 200 allowed outcome with the remote service data, but the key itself must not be in the response body. A CI/CD runner executing a deployment script should receive an allowed outcome to inject the key into the environment, whereas a pull request from a forked repository attempting to print the environment variable must receive a denied outcome or read an empty string. Document these tradeoffs and failure modes, such as the risk of a misconfigured proxy inadvertently reflecting the credential. ## Implement automated rotation in serverless architectures Automating secret rotation reduces the window of vulnerability if a credential is leaked. The OWASP Secrets Management Cheat Sheet details architectural patterns for rotation, such as using a sidecar container in Kubernetes or a serverless function for cloud providers. As a concrete worked example, consider a serverless rotation function for a database credential. The secrets manager triggers the function on a schedule. The function first retrieves a pending credential identified by a specific client request token. It validates that the rotation is enabled and ensures the pending version targets the correct database to prevent privilege misdirection. The function then connects to the database, applies the new password, tests the connection using the new pending credentials, and finally promotes the pending version to current. This multi-step process minimizes downtime tradeoffs and gracefully handles failure modes where a network timeout might otherwise leave the secrets manager out of sync with the database. ## Prevent secondary exposure in prompts and logs An AI coding session can move a credential from a local file into a remote prompt, generated patch, build log, or support transcript. Use placeholders when asking for implementation help. Review the access and data handling of coding tools before granting them a repository or production environment. A request to debug a configuration rarely needs the actual secret value. Configure application logs to avoid authorization headers, session cookies, connection strings, and full credential-bearing URLs. Mask values in error reports and screenshots. Masking is a display control, not revocation: a partially hidden credential may already have been captured elsewhere. Review upstream provider logs and retained artifacts when investigating an exposure. ## Rotate an exposed credential and check its use If a real private credential was exposed, removing it from the latest commit is not sufficient. Revoke or rotate it through the provider, deploy the replacement to the intended environment, and verify legitimate service operation. Coordinate rotation where two credentials must overlap temporarily so the incident response does not create an avoidable outage. Review provider activity, spend, and access logs for the affected period. Determine which resources the old credential could reach. Remove unnecessary copies from repository history and retained artifacts under the relevant retention policy, but do not mistake cleanup for invalidation. Record an incident timeline and a concrete prevention change such as a build-time sentinel check. ## Sources and evidence limits Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results. Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results. - [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)