In May 2026, a key for LiteLLM's internal agent platform appeared in a public repository. The team removed the exposed code but did not revoke the key.
An attacker used it in October. According to LiteLLM's investigation, access to that platform exposed a GitHub token belonging to an organization owner. The attacker stole more credentials and used them to publish a compromised version of the library on October 21.
If you build applications with a coding agent, check where the key goes after you remove it from the source code. The repository is one place to look; the agent's tools and the running application need checking too.
Deleting a key does not revoke it
An API key lets a program use a service on your behalf. Its permissions determine whether it can read data, change it, spend money on requests or perform other operations.
Removing a string from a repository does not tell the issuing service to reject that key. A saved copy can keep working until you revoke it or it expires. Generating a replacement also does not guarantee that the old key has stopped working.
GitHub recommends revoking or rotating an exposed secret before cleaning up repository history. Start at the service that issued the credential, then update the applications that depend on it.
A .env file is readable data
A .env file is a plain-text file containing project settings. Those settings often include API keys and database credentials.
Adding it to .gitignore helps keep it out of future commits if it is not already tracked. It does not change which programs can read the file from disk.
From the repository root, this command checks whether Git tracks the root .env file without printing its contents:
git ls-files -- .env
If it prints .env, Git tracks that file. No output only means that this path is absent from the current index. It says nothing about earlier commits, other secret files or the agent's file access. See the Git command reference.
A coding agent with permission to read the project directory may be able to read that file too. If a tool returns the contents, the key can enter the model's context. A program can also expose it through debug output, an error message or a log.
Check the agent's actual file access and the output of its tools. Do not paste the value into another chat to ask whether it is safe.
Follow the key into the running program
A secret store can keep an encrypted record instead of a readable key. To authenticate a request, a program needs access to a usable credential at some point. An authentication proxy can hold it on the application's behalf; that proxy then becomes part of the path to check.
Trace that path in the system you use:
- Where does decryption happen, and who can request it?
- Does the readable value pass through a server, a worker or a proxy?
- Can the receiving program write the value to a file, print it or return it to the model?
- Does permission apply to one retrieval, a time window or all future requests?
An approval dialog can give a person a chance to reject an unexpected request. After approval, the program receiving the key still needs to be trusted. It may retain a copy, and a compromised runtime may capture the value.
Approval to retrieve a key is also different from limiting what the key can do at the issuing service. Once the readable value leaks, the service will accept it according to its own permissions, expiry and revocation state.
Check one project
Choose a project you are using now. Record the location of each credential without copying its value.
For any exposed key, revoke it at the issuing service, replace it in the applications that need it and review its usage history. Investigate unfamiliar operations and unexpected spending.
Give different projects separate credentials where the service allows it. Limit each credential to the operations the application needs. A program that reads one table should not need administrator access to the whole database.
Check source files, environment settings, tool output and application logs for copies of secrets. To test output handling, use a fake value such as secret-handling-test-2026 in a disposable test configuration, then inspect the output and logs for that marker. Never use a production key for this check. A clean test covers only the code paths you exercised.
If an attacker still controls a computer or server, replacement keys may be stolen too. Revoke exposed credentials from a trusted device and remove the attacker's access before restoring secrets to that environment. For a production system, involve its administrator.
These checks follow OWASP's guidance on secrets management: limit access, manage the lifetime of credentials and make revocation part of the response to exposure.
For that one project, make sure you can answer three questions: where is its key stored, what can use it, and where can you revoke it?
Prepared with AI assistance.
Top comments (0)