AI API key security

DEEP DIVE · iPROMPT #153 COMPANION

16 SEPTEMBER 2026

AI API key security
Find and contain exposed keys

A practical audit for one repository, container image or automation account. Identify what is exposed, decide what needs revoking, and leave each unresolved finding with an owner.

6 MIN READ · AUDIT AND CHECKLIST

The newsletter explains why stolen AI keys matter. This companion starts with the work. Anthropic’s report supplies the threat examples; the audit below is iPrompt’s guidance. Anthropic has a commercial interest in direct access, and its selected cases do not establish how often small teams are affected.

Anthropic threat report · 10 September

AI API KEY SECURITY / THE AUDIT

The five-step audit

Pick one location and set aside an afternoon for a first pass. Record the date, scope and responsible person. This is a starting audit, not a security certification. If you find public exposure or suspicious use, move straight to step four.

1 List. Record key labels, providers, owners, purposes, permissions and known consumers. Add expiry, last use and available spending controls. Use the newsletter’s prompt if helpful, but never enter credential values. Unknown ownership is a finding.

2 Scan. Use TruffleHog on authorised material and retain verified, unknown and unverified results for review. Check full available repository history, not just current files. For images, inspect layers and build history. Keep scanner output private; it may contain credentials. The checklist below covers other locations.

3 Rank. Prioritise confirmed exposure and suspicious activity, then the ability to spend, read data or change systems. Check the actual permissions: a model API key is not automatically access to every tool in an agent workflow. Separate connected-service tokens may grant that access.

4 Rotate. Publicly exposed or abused key: revoke or disable promptly and restore service with a replacement. No evidence of compromise: create a replacement, update every consumer, test, then revoke the old key. Record the provider-side revocation time and review available logs from the earliest plausible exposure. Missing logs leave uncertainty.

5 Contain. Give each replacement a named owner and one purpose. Restrict permissions, set expiry and enforce spending limits where supported. An alert or budget label may not stop requests; check the provider’s behaviour. Store secrets server-side, outside model context, and restrict the actions agents can take with them.

Finish with a short record: location checked, evidence reviewed, action taken and open questions with owners. Repeat the relevant checks after deployments and access changes. A first pass is complete when the findings have a disposition, not when every system has been declared safe.

Where to look for copied keys

Use the row that matches your chosen location. These checks target common hiding places; they do not cover every way credentials can escape.

Exposure locations drawn from Anthropic’s report and the Strix case study. Checks are iPrompt’s recommendations.

A correction to how our #149 LiteLLM recommendation should be used: a fallback gateway also concentrates credentials. Anthropic describes prompt-injection attacks on wrapper services’ LiteLLM deployments; it does not establish a flaw in LiteLLM itself. Keep secrets outside model context and enforce access in the application. A prompt telling an agent not to reveal a key is not an access control.

AI API KEY SECURITY / RESPONSE AND PREVENTION

Evaluate the intermediary before the discount

Cheaper access can be legitimate. Price alone tells you little about who operates a gateway, which model answers, or how credentials are handled. Before changing routes, answer these four questions.

Anthropic describes a reseller that substituted another model and harvested credentials. It also describes fake clients that kept stealing fresh tokens after resets. If a client or device is compromised, rotating keys on that same device can give the attacker the replacements.

Isolate a suspected compromised device and stop using the client. Revoke affected tokens and sessions from a trusted device, then have the endpoint cleaned or rebuilt before issuing replacements to it. A credential leak can be a one-key incident; a credential-stealing client requires a broader response.

Confirm revocation at the source

In Strix’s Baseten case, the exposed credential was a GitHub token, not an AI API key. It was found in image build history and still had repository admin rights years after the build. Baseten restricted the registry and rotated it. Strix sells the testing agent, but the distinction is useful: removing public access to an image does not invalidate copies already downloaded.

Strix write-up · September

OpenAI’s Agents API vault documentation is explicit: deleting stored credentials neither revokes the original provider tokens nor stops a running session. Check provider-side revocation separately, cancel affected sessions where appropriate, and look for other access created during the incident. File cleanup comes after containment.

OpenAI vaults documentation

The strongest objection

“Our provider already scans for leaks, and our AI bill is small.” Both points can be true. Neither establishes what is sitting in an old image, a contractor’s laptop or an integration nobody owns.

Automatic scanning covers particular locations and credential types. Spending limits constrain cost, while permissions determine data and system access. A clean scan only tells you what that scan detected within its scope. It cannot clear material it never inspected.

We cannot tell you the probability that your team will be hit from these case studies. That is why the recommendation is a bounded first pass: inspect one location, fix confirmed exposure and assign the unknowns. Expand if the findings justify it.

YOUR MOVE

Audit one location this week. Reply with a redacted summary of where you looked, what you found and what you did. “No findings within the checked scope” and “still investigating” are both valid. Never send a credential or raw scan output.

The useful result is a smaller exposure and a clear owner for what remains.

ISSUE ACCOUNTABILITY / APPENDIX

The standing prediction ledger

Historical forecasts are reproduced for continuity, separately from the security guidance. This edition does not independently re-score them.

The statuses below are carried from the supplied issue records. An unresolved entry is not a claim that no relevant event has occurred. Original wording and counting rules must be checked before any outcome is scored.

The #151 counting rules, including void and loss provisions, remain controlling. These entries are abbreviated. No new forecast is added.