How does a credential end up in my agent's output?

Usually because a tool call hands the agent something raw and it repeats that back. An agent that reads a .env file to check a setting, prints a debug log, or calls a tool that returns headers and environment variables now has that content in its context, and the next thing it writes often quotes it verbatim, in an explanation, a retry, or a line it logs.

The common paths are reading config or env files directly, verbose debug output, a credential passed into a tool call itself (an MCP server configured with a key, an HTTP parameter carrying a token), generated code that hardcodes a key it just saw, and child processes inheriting the same environment variables the agent has. None of that needs a bug in the model. The agent is doing what a language model does with whatever sits in its context: repeating what’s relevant to the answer.

That’s the gap secret_leak exists to close: nothing has to be misconfigured for a credential to end up somewhere it shouldn’t.

sources

keep reading

More on this.

Can I see the actual secret Tessary flagged?No. Detections carry redacted evidence, a pattern name and a short snippet, never the credential itself.answer →Does mentioning a password in conversation trigger secret_leak?No. It's anchored on the shape of a live credential, like a key prefix or private-key header, not the word 'password' in ordinary prose.answer →Does secret_leak see credentials in inner tool calls, or only the final response?Everything. It checks every span in a trace, including inner tool calls, not just the message the user ends up reading.answer →Everything on tessary secret leakThe definition, and every question answered under tessary secret leak.concept →

Send us the traces you already emit.

book a demo