What should I do if my AI-built app exposes an API key?

If a real API key is exposed, treat it as compromised and arrange its revocation or rotation with the responsible provider and engineering team. Identify what the key can access, where it appeared, and which services depend on it. Deleting the visible text alone does not invalidate a credential someone may already have copied.

GitHub's guide to remediating leaked secrets covers context gathering, revocation, affected services, unauthorized access, and repository cleanup. Use your organization's incident process to coordinate those activities for the actual exposure.

What should we establish first?

Record the provider, credential type, privileges, affected account, and exposure location. It may have appeared in a repository, a browser-delivered file, a public build log, a screenshot, or an agent conversation. Preserve useful evidence in an appropriately restricted place without spreading the secret further.

Name someone who can revoke access and someone who understands the application's dependencies. If a key supports a production integration, replacement may require coordinated configuration changes to avoid creating another operational failure.

Keep the response focused on the real privilege involved. A development-only token and a production administrative credential have different consequences.

Where might the same credential have been copied?

An AI-assisted workflow can move configuration through several tools. Check the repository and relevant history, generated assets, deployment settings, logs, shared documents, and approved tool conversations within the incident scope.

Do not paste the key into another assistant to ask whether it is sensitive. Describe its type and location without disclosing its value. Give investigators access through the approved incident channel.

A browser-visible environment variable is public in the delivered application regardless of its variable name. Have the engineer verify the compiled output rather than assuming a configuration file stayed on the server.

How do we check what happened?

Review provider activity and application logs for the affected period, where available. Determine which data and actions the credential could reach. Retain the evidence needed to assess the incident and follow the organization's decision process for any customer, contractual, or regulatory communications.

Absence of a suspicious log entry is not proof that nobody obtained the key. Logging coverage and retention limit what can be established.

What needs to change before normal work resumes?

Verify that the replacement works and that the old credential no longer does. Remove unnecessary privileges and separate development from production access where the architecture supports it.

Add checks appropriate to the failure: secret scanning, reviewed configuration, restricted tool access, or a change to the build process. Make the expected practice clear to people using coding agents. A rule to "be careful with secrets" is less useful than a supported way to configure the integration without placing a key in source code.

Review how the application handles credentials

If your team needs help tracing the exposure and repairing the app configuration, discuss an engineering review. Share the incident context through an approved channel and agree the review scope before providing access.

Frequently asked questions

Is deleting the GitHub file enough?

No. The credential may remain usable and may exist in history or other copies. Revocation or rotation and investigation need to address the actual exposure.

Will rotating the key break the app?

It can if dependent systems still use the old value. Coordinate the replacement and verify the integrations, while prioritizing containment according to the incident's consequences.

Can I leave a key in a private repository?

Private access reduces some exposure paths but does not make source code a general-purpose secret store. Use the supported configuration mechanism and controls for the particular service and deployment.