How Secrets Leak From AI Agents, and How to Stop It

A key in the reply

Here's a leak that doesn't look like one. An engineer asks a coding agent why a deployment keeps failing. The agent reads the config, finds the problem and explains it, quoting the line that contains the live database password. The reply lands in a shared channel. Nobody hacked anything.

We've run into versions of this in our own work. Agents are eager to help, and the most helpful answer often includes exactly the detail you didn't want repeated. Secrets don't need an attacker to escape. They need a path.

The same thing happens with card numbers pasted into support tickets, passwords in copied error messages, and tokens inside a shared command. Each one is small. Together they add up to a steady drip that nobody designed and nobody is watching.

How big is the secrets problem?

Big, and it was big before agents arrived. GitGuardian's State of Secrets Sprawl 2025 report found 23,770,171 new hardcoded secrets added to public GitHub repositories in 2024, a 25% rise on the year before. A secret here means anything that grants access: API keys, passwords, tokens, private keys.

The more worrying finding is what happens next. GitGuardian found that 70% of the secrets leaked in 2022 were still valid. Leaks happen, and then nobody turns the key off.

Two more findings matter for AI. GitGuardian found that public repositories using GitHub Copilot, an AI coding assistant, had a 6.4% secret leakage rate, which it describes as 40% higher than the average across public repositories. And private code isn't safe by default: 35% of the private repositories it scanned for customers contained at least one plaintext secret.

Where do secrets leak from AI agents?

OWASP's entry on Sensitive Information Disclosure groups security credentials with personal and financial data, and that's the right frame. Card numbers are a good example. An agent handling support tickets will see them, whether you planned for it or not.

Follow a secret through an agent's day and you'll find at least six exits:

• Prompts and context. Keys pasted into a chat, or written into the system prompt (the standing instructions an agent gets) so it can call a service. OWASP's entry on System Prompt Leakage says plainly that API keys and credentials shouldn't be embedded in system prompts, and that the system prompt shouldn't be treated as a secret.
• Files the agent reads. Config files, environment files, old scripts and tickets. If the agent can read it, the agent can repeat it.
• Tool calls. An agent may pass a key to a tool, sometimes to the wrong tool, or to one that records everything it receives.
• Logs and traces. Agent software often logs full prompts and tool calls for debugging. Those logs then hold every secret the agent ever touched.
• Replies. The agent quotes a secret back to a colleague, a customer or a shared channel.
• Smuggling. A hijacked agent can be told to tuck data into a link or a request to an outside server. That's the external communication leg of what Simon Willison calls the lethal trifecta.

Why streamed replies are tricky

Most AI products stream their answers. Words appear a few at a time, so the reply feels fast. That's good for people and awkward for security.

A check that waits for the finished reply is too late, because the reader has already seen most of it. A check that looks at each small piece on its own misses a secret split across two pieces: half a key in one chunk, the rest in the next. And a secret can be spread out on purpose, one character per line, or buried in other text.

So output checks for streamed replies have to hold back a little text, look across the joins between chunks, and release text only once it's clear. Done well, the pause is hard to notice. Done badly, either the stream stutters or secrets slip through the gaps.

Practical controls that work

Start with the controls that make a leak harmless, then add the ones that catch it.

• Agents never hold real long-lived keys. Give agents access through a short-lived token issued for one task, or through a service that makes the call on their behalf. If the agent never sees the master key, it can't leak it.
• Short-lived credentials. The OWASP Secrets Management Cheat Sheet recommends dynamic secrets where possible, with short lease durations, and regular rotation so that any stolen credential only works for a short time.
• Revoke fast. When a secret is exposed, revoke it. Don't just delete the message. OWASP says secrets that are no longer needed or potentially compromised must be securely revoked, and GitGuardian's finding on 2022 secrets shows how often that step gets skipped.
• Least privilege. A leaked read-only token for one repository is a bad day. A leaked admin token for the whole organisation is a crisis.
• Keep secrets out of logs. The OWASP cheat sheet says secrets should never be logged in plain text. Mask them before anything is written.
• Check what goes out. Scan tool calls and replies, streamed ones included, for keys, passwords and card numbers before they leave.
• Plant decoys. Fake credentials that no legitimate process should ever use make a quiet alarm. If one gets used, something is wrong.

What these controls can't catch

Pattern checks are good at things that look like secrets: keys with known formats, card numbers that pass the standard checksum, private key blocks. They're weaker on a password that looks like an ordinary word, or on business secrets like next quarter's pricing. No output check replaces keeping the secret away from the agent in the first place.

There's also a balance to strike with personal data. Remove too much and the agent can't do its job. Remove too little and you're exposed. That balance is a decision for each company. Write it down as a rule someone owns, rather than leaving it to a default nobody chose.

A quick audit you can run this week

You can learn a lot about your exposure in an afternoon. Pick one agent that matters to the business and answer these questions honestly. Any answer that comes back as "we're not sure" is the place to start.

• Which credentials can this agent use today, and do any of them outlive the task they're for?
• Are any keys sitting in its system prompt, config or environment, where it could read them and repeat them?
• Where are its prompts and tool calls logged, who can read those logs, and are secrets masked before they're written?
• If one of its keys leaked right now, who would notice, and how long would it take to revoke?
• Can its replies, streamed ones included, reach a customer or a shared channel without any check?
• Does it handle card numbers or other personal data, and is there a written rule for what happens to them?

What we do about it

We built Cognilox because we needed it, and secrets were one of the first reasons. Aptibit runs Cognilox on its own AI agents today, and it has already blocked secrets from leaking into our own agents' replies.

Cognilox stops secrets leaking in what agents send and in what they reply, including while a reply is being streamed. Where it can, it fixes rather than blocks: it removes the secret or card number and lets the safe part through. Payment card numbers are removed by default, and other personal data follows your own rules. Decoy credentials expose a compromised agent and isolate it, and a leaked code-hosting token can be revoked automatically.

It runs on your own servers, including fully offline sites, or in Cognilox Cloud, and none of your data goes to Aptibit. Read more about how Cognilox defends agents and our approach to security. If you'd like to watch it catch a secret mid-stream, we can show you live.