A secret leak is not a single event. It is a copying process.
A token appears in a CI log. The log is indexed for troubleshooting. An agent is asked to diagnose a failed deployment and retrieves the log. The agent summarizes the failure, stores the useful parts in memory, and later uses that memory while calling a tool. By then the token may have moved through several systems that were never designed to be secret stores.
The leak began as an ordinary NHI problem. The persistence is what makes it agentic.
The first article in this series looked at identities that outlive their purpose. The second looked at identities that still serve a purpose but carry too much authority. This article looks at a third pattern: credentials that escape their intended container and become durable context.
The OWASP Non-Human Identities Top 10 for 2025 names the two identity-side failures clearly: NHI2:2025 Secret Leakage and NHI7:2025 Long-Lived Secrets. Secret leakage is the movement of keys, tokens, certificates, and credentials into unsanctioned places. Long-lived secrets are credentials whose useful life is too long, or not bounded at all.
The OWASP Top 10 for Agentic Applications 2026 gives the agent-side vocabulary for the risk that follows: ASI06 Memory and Context Poisoning and ASI08 Cascading Failures. A leaked secret can become poisoned context when it is stored, indexed, summarized, or retrieved. A long-lived secret can turn one bad memory into repeated access.
The Token Path
The following path is a review model, not a claim about a specific incident. It shows where a secret can travel once agents begin reading operational data.
| Step | System | What happens | Failure introduced |
|---|---|---|---|
| 1 | CI job | A deployment token is printed in an error log. | Secret enters an unsanctioned data store. |
| 2 | Log platform | The log is retained and indexed for search. | The secret becomes discoverable outside the pipeline. |
| 3 | Troubleshooting agent | The agent retrieves the log to explain the failed deploy. | Secret enters prompt or tool context. |
| 4 | Agent memory | The agent stores a summary with the token or a near-complete token fragment. | Secret becomes persistent context. |
| 5 | Later task | A different workflow retrieves the memory because it appears relevant to deployment. | Secret crosses task boundaries. |
| 6 | Tool call | The agent uses the token while invoking a repository, cloud, or deployment tool. | Leaked context becomes executable authority. |
The important detail is not that the agent is malicious. The important detail is that each system behaves normally. Logs retain. Search indexes. Agents summarize. Memory persists. Tools accept valid credentials.
The breach is assembled out of ordinary behavior.
Why Rotation Is Not Enough
Rotation is necessary. It is not sufficient.
If the token was short-lived, rotation may reduce the damage window. If the token was long-lived, the window can be wide enough for the copied secret to reappear in later workflows. But even after rotation, the copies remain. The old value may still sit in logs, traces, prompts, vector stores, memory snapshots, support tickets, chat transcripts, evaluation datasets, and provenance records.
Those copies matter for three reasons.
First, they may still work. Many environments still contain credentials with long expiration periods or no practical expiration at all. OWASP calls this out in NHI7 because a leaked long-lived secret gives an attacker time.
Second, they may reveal structure even after revocation. A redacted or expired token can still expose account names, project IDs, hostnames, tenant identifiers, deployment patterns, naming conventions, or the shape of internal APIs.
Third, they can poison retrieval. If an agent learns that a secret-shaped string is relevant to deployment, it may retrieve that artifact again, summarize around it, or include it in a future tool call. The credential may be invalid by then, but the memory still teaches the system where authority used to be.
What to Scan
Repository secret scanning is table stakes. It is not the whole surface.
Agentic systems need scanning across the places where agents read, write, summarize, and remember. That includes CI logs, application logs, model prompts, tool inputs, tool outputs, conversation transcripts, scratchpads, memory stores, vector databases, embeddings metadata, evaluation corpora, incident notes, and provenance records.
The scan has to follow the token path. If the CI log contains a secret, the review should ask whether that log was indexed, whether it was retrieved by an agent, whether it entered a prompt, whether any memory record was written from that prompt, and whether later tool calls used related context.
The result should not be a single finding called “secret leaked.” It should be a lineage record:
| Artifact | Example question |
|---|---|
| Source log | Where did the secret first appear? |
| Retrieval event | Which agent or tool read it? |
| Prompt or context bundle | Was the secret included in model-visible context? |
| Memory write | Was the secret, fragment, or derived hint stored? |
| Memory read | Did a later task retrieve that record? |
| Tool invocation | Did the retrieved context influence an authenticated action? |
| Revocation proof | Does the old credential now fail everywhere? |
Without this lineage, cleanup becomes guesswork. A team can rotate the key and still leave behind the trail that teaches future agents how to find it again.
What Has to Be True
Secrets should not enter memory by default. Agent memory needs deny rules for credential formats, secret manager values, authorization headers, private keys, session cookies, database URLs, cloud access keys, and near-miss fragments. The goal is not only to block exact matches. It is to prevent the system from preserving material that functions like a credential or points directly to one.
Memory writes should be policy decisions, not side effects. A troubleshooting agent may need temporary context from a CI log, but that does not mean the log belongs in long-term memory. The write path should know the source, classification, retention period, and allowed future uses.
Tool outputs need the same treatment as user input. A secret printed by a build system is still a secret. A token returned by a diagnostic endpoint is still a token. A credential embedded in an exception trace is not safer because it came from a trusted tool.
Rotation should be paired with erasure and proof. When a secret leaks, response should include key rotation, memory-store search, log retention review, vector index cleanup, transcript deletion or redaction, provenance updates, and a negative test that the old credential fails.
Long-lived secrets should be treated as design debt. If a workflow cannot use short-lived credentials, the system should record why, who owns the exception, what compensating controls exist, and when the exception expires. A permanent credential in an agent-accessible environment is not a convenience. It is stored time.
The final test is simple to state and hard to pass: after rotation, can the system still retrieve enough context to reconstruct or reuse the secret path? If yes, the incident is not finished.
In agentic systems, secrets are not only keys. They are context that can be copied, summarized, indexed, embedded, retrieved, and acted upon. That is why secret response has to follow the memory trail, not just the credential.
Next in the series: environment isolation and NHI reuse, and how shared identity paths turn local failures into system-wide failures.