The Week the API Key Stayed Live

A colleague pasted an API key into a chat with an AI agent. Then forgot about it.

The key had access to a paid model account. It was visible to every service that processed that chat history for the next seven days. The developer did not know. The agent worked fine throughout. The code shipped. Nobody audited what the agent could see.

This is not a hypothetical. It is the category of incident that is already happening at the scale of AI agent adoption , quietly, unreported, with no obvious failure signal because the code keeps shipping regardless.

Hole 1: The .env File

Your AI agent can see every file your code editor can see. On most developer setups, that includes the .env file , the file that holds API keys, database credentials, third-party secrets, and anything else you have configured to authenticate with external services.

Agents need filesystem access to do useful work. The problem is that "filesystem access" is rarely scoped. If the agent can read your project directory, it can read your .env. If it can read your .env, every credential you use in that project is potentially exposed to the agent's context, its logs, and any service that processes its outputs.

Hole 2: Chat History as a Credential Store

The colleague scenario above is more common than it sounds. Developers share sensitive values in chat when debugging , "here's the key that's failing" , and those messages persist in conversation history indefinitely.

Most developer AI tools log conversations. Many sync them to cloud services. Some use them for model improvement. A key pasted in chat in January may still be in a log somewhere in December. The immediate threat is not the only threat.

Hole 3: Git History

If your agent has access to git history , which it often does if it has access to the project directory , it has access to every commit that was ever made, including commits where secrets were added and later removed.

Removing a credential from the current codebase does not remove it from git history. An agent with repository access can traverse the full history. In most developer setups, this exposure is not considered when granting agent access.

Hole 4: Command Execution Scope

Agents that run commands do so with whatever permissions the process running the agent has. On a developer laptop, that is usually full user permissions. An agent that misinterprets an instruction , or encounters a prompt injection through an external resource it is processing , can execute commands at the same scope as the developer.

The solution being adopted by security-conscious teams: MCP servers that expose only what the agent needs. Instead of giving the agent file access, give it a server that answers specific questions about the codebase. Instead of shell access, give it a server that executes a defined set of operations. The agent gets the capability it needs. The blast radius if something goes wrong is bounded.

The Practical Response

Three immediate steps that address most of the exposure:

  • Rotate every credential that has appeared in a chat interface in the last 12 months. Treat any key that was ever visible to an AI system as compromised, whether or not there is evidence of misuse.
  • Scope agent filesystem access to output directories only. The agent should write to a designated folder. Reads should go through a tool or MCP server that controls what the agent can access, not open filesystem access.
  • Monitor your developer accounts for dark web exposure. GitHub credentials, npm accounts, model provider API keys , these are now high-value targets. Treat them with the same discipline as production database credentials.

The developers most exposed are the ones who feel safest , because the agent works, the code ships, and there are no visible failure signals. The exposure is not in the output. It is in what the agent could access while producing it.