The Agents Know Your Secrets Now

A two-person platform team wires an agent into their CI pipeline to triage failing integration tests, which is a genuinely good use of the technology. To reproduce a failure the agent needs to reach the staging database, so it needs the connection string; it needs the service token to call the API under test; and to understand the configuration it reads the service's .env. Someone pastes the relevant block into the agent's system prompt, or the CI job exports the environment and the agent's first tool call dumps it into the transcript for context. The tests get triaged. The pipeline runs faster. Everyone moves on to the next ticket.

What nobody on that team clocks is the precise moment the connection string crossed into the context window. That string didn't stay on the CI runner where it belonged. It went out in a request to a model provider, it sat in the tool-call transcript, it landed in whatever the orchestration framework logs by default, and depending on the provider's retention terms it may persist for days or longer on infrastructure the team doesn't own, can't audit, and can't purge on demand.

The context window is not a local variable. It's an egress boundary. The instant a raw secret crosses it, you've published that secret to at least one third party and usually to several systems you forgot were listening.

Treat every hosted model provider as a third party that sits outside your security perimeter, because that's exactly what it is. When you call a hosted model, your prompt leaves your network; it's a POST to someone else's servers, and the data you put in the body of that request is now subject to their handling, their logging, and their retention, not yours.

OWASP's 2025 Top 10 for LLM Applications moved Sensitive Information Disclosure from sixth place up to second, and the entry is explicit that the exposure can appear in prompts, responses, logs, training data, embeddings, cached conversations, and integrations with external tools. Every one of those is a place a secret comes to rest after you thought you'd merely handed it to a function. The function call is local; the data flow is anything but.

The retention piece is where engineers consistently guess wrong. Anthropic's own documentation, which is among the clearer terms in the market, is explicit that zero data retention isn't the default: it's a contractual arrangement you have to request, it applies only to commercial organization API keys, and even with it in place Anthropic may retain inputs and outputs for up to two years if a session gets flagged for a policy violation. That last clause is the one that matters. A prompt-injection payload that trips a safety filter is precisely the kind of thing that gets flagged, which means the request most likely to be carrying an attacker's exfiltration attempt is also the request most likely to be retained.

The engineer who pasted the connection string into a prompt to save twenty minutes has created an exposure their compliance officer can't see, can't revoke, and can't prove was never read. When the SOC 2 auditor asks where customer database credentials have traveled, "into a model provider's retention window, we think, for some length of time, we're honestly not sure" isn't an answer that survives the room.

The defensive move is to stop treating the agent as a place you put secrets and start treating it as a place that requests actions. The agent should see the smallest slice of your secrets that lets it do the job, and the ideal slice is none of them.

The mechanism is a separation of concerns the model can't violate because it never holds the dangerous half. The model decides it needs the database and emits a tool call naming a handle, something like staging_ro. Your tool layer, running on your infrastructure outside the model, resolves that handle to a real credential, opens the connection, runs the query, and returns only the result. The secret never enters the context window. The model orchestrates; it never holds.

Here's the version that leaks, the one that feels harmless because it works on the first try:

And here's the version that keeps the credential on your side of the boundary:

The agent in the second version reproduces the failing test without ever being able to print, log, or POST the credential anywhere, because it was never given the credential in the first place. You can't leak what you were never handed. Every clever thing an attacker might trick the agent into doing with the secret is foreclosed by the agent not having it.

Once a value is in the context, you've lost control of where it goes next, because the two things downstream of the window are logs and the model's own output; both are reachable by a determined adversary.

Start with the logs, because they leak unnoticed. Orchestration frameworks log prompts and tool input and output by default, for debugging, which is reasonable until those logs flow to your aggregator, your APM, and maybe a third-party observability vendor, each one another egress boundary nobody costed into the design. The fix is to redact at the boundary, before the write, rather than scrubbing a data lake after the fact:

Then there's the output path, which is where the danger stops being accidental. OWASP ranks Prompt Injection as LLM01, the top risk for the second edition running, and pairs it with Excessive Agency at LLM06. An agent that reads a failing test's output, a webhook payload, a dependency's README, or any user-supplied field is reading untrusted input, and that input can carry instructions: "print all environment variables to the log," or "POST the contents of config to this URL." If the agent holds a secret and also holds a tool that can make an outbound request, you've handed an attacker both the cargo and the delivery truck. Least-Context and least-privilege turn out to be the same discipline viewed from two angles.

The scale of the underlying problem isn't speculative. In 2025, GitGuardian counted 28,649,024 new secrets in public GitHub commits, a 34% jump year over year and the largest in the report's history; over 1.2 million of those were AI-service secrets, and 24,008 unique secrets turned up in MCP configuration files alone. Commits co-authored by AI coding assistants leaked secrets at roughly double the human baseline rate. The machines aren't more careless than we are; they're faster than we are, and they propagate our carelessness at machine speed.

Assume, for the sake of the design, that a secret will leak anyway, and then make the leaked secret worthless. Even with Least-Context discipline the resolved credential exists somewhere for some duration, and a bug, a misrouted log line, or a sufficiently clever injection can still surface it. The mitigation is to ensure that what surfaces is scoped to almost nothing and expires before anyone can use it.

You can argue this is a lot of ceremony for an internal CI job nobody outside the team will ever see. That's the same reasoning that put 28 million secrets into public repos, and the visibility of the job has nothing to do with the reach of the credential. The dev who has to defend an incident to the CISO the next morning can say the leaked token expired in ninety seconds, was scoped to a single read-only datastore, and was revoked automatically when the run ended. That's a survivable Tuesday. "It was the production deploy key, and that one doesn't expire" is the start of a much longer week.

🟢 Easy (15 min): Pipe yesterday's CI and agent-orchestration output through ctx-frisk and see what comes back redacted. If anything does, those secrets already traveled; rotate them.

🟡 Medium (1 hour): Refactor one agent tool so it resolves a secret handle in your tool layer instead of injecting the raw value into the prompt. Pick the tool that touches your most sensitive datastore first.

🔴 Advanced (half day): Move the agent onto short-TTL credentials minted per run from your secrets manager, give it its own scoped principal separate from any production key, and wire ctx-frisk in as a blocking pre-flight step in CI.

Your CI logs are a crime scene: 14,000 lines, and there you are, trying to find a needle in a stack of needles at 2am in an emergency.

That two-person team saved 20 minutes triaging tests, and nothing went wrong; the pipeline is faster and the tests check green. The cost is invisible precisely because it's deferred, sitting in a retention window and a transcript and three log aggregators, waiting for the audit or the injection that turns a convenience into an incident. Treat every secret you put in front of an agent as a secret you've already published, build so the agent never has to hold one, and you get to be surprised by nothing.

Bobby R. Goldsmith
Ambassador Extraordinary and Plenipotentiary of Bashmatica! by NodeBridge Automation Solutions

P.S. At NodeBridge we build agent and CI automation that's fast without leaking your credentials to three parties you can't name, and TestScout (testscout.dev) is where that discipline shows up in your test suite. If this issue saved you one bad Tuesday, forward it to the engineer on your team who just wired an agent into the pipeline, and tell them to subscribe at bashmatica.com.