A non-human identity that leaks secrets through context windows creates a silent data‑exfiltration channel.
In many organizations, service accounts, CI‑CD bots, and AI agents are given long‑lived API keys or static passwords. Those credentials are often baked into build scripts, stored in configuration files, or even copied into environment variables that persist across deployments. When an automated workflow generates a prompt for a large language model, the prompt frequently includes the raw output of a previous command, logs, or error messages. If any of those strings contain a credential, the model’s context window captures it and can unintentionally reproduce the secret in a later response.
Because a non-human identity can be used by automated scripts, any accidental exposure is amplified. The model does not understand the sensitivity of the data it sees, so the secret can appear in generated code, documentation, or chat logs that are later shared with developers who never needed to see it. The breach is hard to detect: there is no explicit network request, no alert from a traditional firewall, and audit logs often show only a successful API call to the LLM service.
Teams typically try to mitigate the problem by rotating keys frequently, limiting the scopes of service accounts, or moving secrets to a vault. Those steps improve the static risk profile, but they do not stop a secret that has already been injected into a context window from being propagated further. The root cause is the lack of a runtime enforcement point that can inspect and control what leaves the identity‑to‑resource path.
Why identity alone isn’t enough
Using a non‑human identity that is federated through OIDC or SAML satisfies the setup requirement: the system knows who the request originates from and can enforce least‑privilege scopes at token issuance time. However, the data path – the actual network hop between the identity and the target service – remains unguarded. The request still travels directly to the database, Kubernetes API, or SSH daemon, bypassing any intermediate inspection.
When the request reaches the target, the service sees a perfectly valid credential and executes the command. No audit record is created that captures the exact query or the response payload. No inline masking occurs, so any sensitive fields returned by the service flow back into the context window unchanged. No just‑in‑time approval step can intervene because the gateway that could enforce such a step does not exist in the path.
Putting a gateway in the data path
hoop.dev addresses the missing enforcement layer by sitting between the non‑human identity and the infrastructure target. The gateway terminates the client connection, validates the identity token, and then proxies the request to the destination. Because hoop.dev controls the traffic, it can apply policy checks on every command and on every response.