Your Secrets Manager Ends Where the Context Window Begins

Your vault does everything right. Secrets are encrypted at rest, access is logged, rotation is automated, and nothing ever touches disk in plaintext. Then your agent calls a debugging tool, the tool prints an environment dump to stdout, the framework helpfully feeds stdout into the model's context — and your database credential is now part of a prompt. From that moment, the vault's guarantees are fiction. The credential exists in the trace your observability platform captured, in the prompt cache your provider keyed on that prefix, in the memory store your agent writes to between sessions, in the eval fixture someone snapshotted from production traffic, and in the provider's retention logs. Five persistence layers, none of which your secrets manager knows exist.

This is not a hypothetical. A large-scale study of over 17,000 published agent skills found that information exposure through logging accounted for 73.5% of all credential security issues — dwarfing hardcoded secrets at 18.2% — precisely because agent frameworks capture console output directly into the LLM context window. The old failure mode was a developer committing a key to GitHub. The new one is a tool response committing a key to a context window, and the context window has no git revert.

The uncomfortable framing: a credential that transits the model can't be un-leaked. You can rotate it, but you cannot rotate the copies. Every mitigation that matters follows from taking that sentence seriously.

Context Is a Copy Machine, Not a Pipe

Engineers reason about credentials as if the model call were a pipe: data goes in, a response comes out, and the data is gone. The actual architecture is a copy machine with five output trays.

Traces. Every serious LLM deployment runs observability — LangSmith, Langfuse, Braintrust, a homegrown span logger. These systems capture full request and response payloads by default, because that's what makes them useful for debugging. A secret in the prompt is now a secret in your tracing backend, subject to that system's retention policy, access controls, and export integrations. Stack-trace leakage is its own sub-genre: when an inference client throws, the exception message often embeds the API key from the failed request, and that exception flows into whatever logging pipeline catches it.

Prompt caches. Providers cache prompt prefixes to cut latency and cost, and your gateway may cache aggressively on top. A cached prefix containing a credential outlives the request that created it. Cache entries are keyed, stored, and evicted on schedules you don't control and mostly can't inspect.

Memory stores. Long-horizon agents persist what they learn. If a credential appeared in a tool response, there's a decent chance the agent summarized it into long-term memory — "the staging DB password is X" is exactly the kind of fact a memory system is designed to retain. Memory writes are model-mediated and unstructured, so no schema tells you which rows contain secrets.

Eval fixtures. Teams snapshot production traces to build regression suites. A trace with an embedded credential becomes a fixture with an embedded credential, checked into a repo, copied to laptops, and replayed in CI for the next two years. The eval set is the persistence layer with the longest half-life and the least security review.

Provider logs. API providers retain inputs and outputs for abuse monitoring — historically 30 days as the industry default, though this is shifting; Anthropic cut standard API log retention to 7 days in late 2025, and zero-data-retention agreements exist for enterprise customers who qualify. But unless you've signed one, your credential spent time on infrastructure governed by someone else's retention policy.

Your vault's audit log records one read. The copy machine produced five copies. That asymmetry is the whole problem.

Rotation Assumes an Origin You Can Revoke

The standard incident response for a leaked credential is: rotate it, invalidate the old one, done. This works because traditional leaks have a countable set of locations — a repo, a log file, a Slack message — and rotation makes every copy worthless simultaneously.

Rotation still works for context leaks in exactly one sense: the old credential stops authenticating. What it doesn't do is tell you what else the credential touched while it was live in context. An agent holding a valid key mid-session can be prompt-injected into using it — and injection exfiltration is no longer theoretical. One public disclosure showed that a malicious pull-request title alone could get coding agents from three different vendors to post their own environment variables as a PR comment. The agent read attacker-controlled text, the text asked for secrets, and the agent had secrets to give because they were sitting in its environment and its context.

The window between "credential enters context" and "credential is rotated" is an attack window in which the model itself is the confused deputy. And most teams can't even measure that window, because they don't know the credential entered context in the first place. Nothing alerts. The tool call succeeded. The trace looks normal unless a human reads the payload.

This is also why the scale trend should worry you. GitGuardian's 2026 sprawl report counted 28.65 million new secrets hitting public GitHub in 2025 — with AI-assisted commits leaking at roughly twice the baseline rate, and over 24,000 unique secrets exposed in MCP-related config files alone. The same report found that nearly 70% of credentials confirmed valid in 2022 were still valid three years later. Combine long-lived credentials with a copy machine and you get exposure that compounds: the secret leaks once, persists everywhere, and keeps working.

The Tool Boundary Is the Only Real Chokepoint

Once you accept that context is irreversible, the design question inverts. Stop asking "how do I clean secrets out of my traces?" and start asking "where is the last point at which a secret is structured data I can still act on?"

The answer is the tool boundary — the seam where a tool response is serialized before being appended to the prompt. Before that seam, a credential is a typed value in a runtime you control. After it, the credential is undifferentiated text inside a probabilistic system, already fanning out to the five trays. Everything downstream of the seam is best-effort cleanup; everything at the seam is enforcement.

Concretely, the tool boundary is where three defenses live:

• Egress redaction. Scan every tool response for credential patterns — high-entropy strings, known key prefixes (sk-, ghp_, AKIA), connection-string shapes — and replace matches with placeholders before the framework sees the output. The agent-skills study's top recommendation to framework authors was exactly this: extract recognized credential patterns from stdout before injection into context. Regex won't catch everything; it catches the 90% that currently leaks through console.log.
• Placeholder dereferencing. Invert the flow so secrets never need to enter context at all. The model works with symbolic references — {{STRIPE_KEY}} — and a trusted executor resolves them at call time, outside the model's view. The model can orchestrate the use of a credential it has never seen. This is the same privilege separation we've used between web servers and databases for decades, applied between the reasoning engine and the execution engine.
• Transport-layer injection. The strongest version removes credentials from the agent's process entirely. A local proxy or kernel module intercepts the agent's outbound HTTP, authenticates the workload by its identity (SPIFFE or similar), fetches a short-lived token from the broker, and injects the auth header after the request leaves the agent. Tools like Infisical's agent-vault and the workload-identity products in this space all converge on the same shape: the agent proves who it is; infrastructure supplies what it needs; the credential value never exists in any address space the model can read from or echo back.

Note what's not on this list: output filtering on the model's responses. Filtering what the model says is a guardrail against one exfiltration channel; it does nothing about the trace, the cache, the memory store, or the provider log, all of which captured the secret on the way in.

Short-Lived Credentials: Rotation You Don't Have to Trigger

Redaction is a chokepoint, but chokepoints get bypassed — a new tool, a new output format, a base64-encoded blob the regex missed. The complementary control is to make the leaked artifact worthless by construction: if every credential expires in minutes, a copy captured in a trace is a fossil by the time anyone reads it.

This is the honest argument for workload identity and short-lived tokens in agentic systems, and it's worth stating precisely. Short-lived credentials don't prevent the leak; they cap its blast radius at the token lifetime. A fifteen-minute token that lands in an eval fixture is an inert string. A static API key that lands in the same fixture is a standing liability for however many years that 70%-still-valid statistic implies.

The trade-offs are real. Token issuance adds latency to tool calls. Brokers become critical-path infrastructure. Long-running agent tasks need mid-task re-authentication, which means your agent runtime needs to handle credential refresh without losing its place. But every one of those costs is an engineering problem with a known shape, whereas "which traces contain my Postgres password" is an archaeology problem with no terminating condition.

A useful forcing function: treat any credential with a lifetime longer than your longest agent session as a design smell. If the agent can outlive the rotation period, the rotation period is doing its job; if the credential can outlive the agent, every context the agent ever assembled is part of your attack surface.

The Audit Question Nobody Can Answer

Here is the test that separates teams that have internalized this from teams that haven't. Ask: which secrets has the model already seen?

Your vault can answer "which secrets were read, by whom, when." Your SIEM can answer "which secrets appeared in log files." Almost nobody can answer the context-window version, because answering it requires scanning every stored trace, every cached prefix, every memory row, and every eval fixture for every credential format you use — retroactively, across systems owned by four different teams, some of them external.

If you can't answer it, you can't scope an incident. When a key is compromised, "did this key ever transit a model context, and if so, which sessions, and what else was in them" is the difference between rotating one credential and auditing every action an injected agent might have taken.

Making the question answerable is mostly bookkeeping, which is why it's worth doing now rather than during an incident:

• Tag at the seam. The tool-boundary redaction layer already detects credential patterns; have it emit a structured event — secret fingerprint (a hash, never the value), session ID, timestamp — whenever one crosses, even when redaction succeeds. Redaction failures become detectable as fingerprints appearing in traces without matching events.
• Fingerprint your traces. Run the same secret-scanning you run on git commits against your trace store and memory store, continuously. Vendors ship trace-masking hooks (LangSmith's input/output masking, SDK anonymizers with credential regexes); the gap is usually that nobody turned them on and nobody scans what got stored before they did.
• Inventory the fifth tray. Know your provider's retention terms the way you know your database's backup schedule. Seven days, thirty days, zero-data-retention contract — it determines how long an incident's exposure window extends beyond infrastructure you can query.

The direction of travel is clear enough. Secret scanning moved from "run it on your repo sometimes" to a mandatory pre-commit gate over about five years. Context-egress scanning will follow the same path, compressed, because agents are minting the leak surface faster than repos ever did — an 81% year-over-year surge in leaked AI-service credentials says the copy machines are already running. The teams that will be fine are the ones that put the chokepoint at the tool boundary, capped credential lifetimes below session lifetimes, and can answer the audit question with a query instead of a war room. The vault was never the perimeter. The prompt is.