Trellix: AI agents can leak API keys and tokens – without malware or malicious intent
A Trellix analysis, covered by CyberPress, describes how AI agents in entirely routine development tasks can move passwords, API keys, and tokens out of encrypted storage and into command lines, logs, files, and ultimately an external model provider's systems — without malware, without malicious intent, and without anyone doing anything wrong. The risk model points to a detection problem that security teams barely have the tools to handle.
An AI agent that retrieves a secret and uses it is, at first, doing exactly what it was asked to do. The problem, as the security firm Trellix describes it in an analysis covered by CyberPress, is what happens along the way: the secret leaves the encrypted store, lands in process memory, then in command-line arguments, then in logs, telemetry, and files — and in the worst case, in the context window of a language model operated by an external provider. No link in this chain is a security breach. Yet the end result can still be a legitimate API key sitting in a log file, in an agent transcript, or on a model provider's server.
It is important to be clear about what this is and is not: no documented incident or concrete victim has been reported. The basis for this article is CyberPress's secondary coverage of the Trellix analysis — the underlying Trellix document, including its title, date, and authorship, is not available for verification. What Trellix describes is a risk model: a way in which agent-driven credential leaks can happen, and why they are so hard to detect.
The Isolation Gradient
The analysis's central concept is what Trellix calls an "isolation gradient" — a gradient along which secrets move steadily further away from protection. The chain looks roughly like this:
- Encrypted storage — OS keychain, cloud secret manager, environment variables in a secrets vault. Here the secret is properly protected by access control and encryption.
- Process memory — A credential helper or CLI tool retrieves the value, and it now exists in plaintext within a process.
- Command line — The value is inserted as an argument or header in a command, for example a curl command against an API.
- Files and telemetry — The command is logged by the shell, by monitoring tools, by the agent's own transcript, or by the application's file logs.
- External systems — Data is sent to the service that was meant to be reached — or, via the model's context window, to an external model provider.
The point of the method is that every transition is legitimate and individually innocent. But exposure increases step by step, and how far the secret actually travels depends on access permissions, logging settings, and the agent's design, according to Trellix. An agent setup that logs all tool calls, combined with an agent allowed to read configuration files, can thus move a secret from a well-protected vault to a text file in seconds — as part of a completely normal work session.
The OAuth Token in the Curl Header
Trellix's illustration of the mechanism is deceptively simple. An agent is told to fetch a user profile from Microsoft Graph — an entirely routine task. The agent uses a credential helper to obtain an OAuth token, then builds a curl command with the token in the authorization header. The request reaches the right service, and everything appears to have gone well.
But the token was now in plaintext as part of a command line. It can show up in process telemetry, in the agent's transcript of its own tool calls, or in other command logs. All of these are real exposure surfaces: process telemetry is read by EDR systems and IT staff, transcripts can be stored, shared, or used for troubleshooting, and command logs often sit untouched in files for a long time. It is worth noting that the source does not say whether this example is drawn from real observations or is constructed — CyberPress's coverage describes it generically as an example from the analysis.
The point is structural, not anecdotal: as long as the agent builds commands with secrets as arguments, the very mechanism of legitimate authentication becomes a leak channel. The tool works; it is the traces around it that leak.
Configuration Files into the Context Window
The second main mechanism goes via file reading. Projects are filled with files like .env, AWS credentials files, Kubernetes configuration, and application settings — files that by definition contain secrets. When an agent reads such files as part of an assignment ("set up the environment," "troubleshoot the deployment"), the contents become tool output — and tool output ends up in the agent's context window.
For cloud-based models, that means, as Trellix describes it, that secrets can be sent to an external model provider. Here the source's caveat matters: storage and retention vary between services and configurations, and exposure should not automatically be described as permanent. But it is a structural change in what a secrets-leak incident is: previously, an attacker had to exfiltrate data from your machine. Now the agent's normal functioning can send a legitimate secret as part of an API request to a third party, without anyone classifying the event as exfiltration.
Trellix also points to a third variant that is even more contradictory: OS keychains and cloud secret managers can deliver secrets in plaintext, entirely correctly. The vault's access control works as intended — authentication, authorization, audit logging. What fails is what happens afterward: the agent mishandles the value it was just handed over. The vault's security model ends where the value leaves the vault; the agent's handling of the value lies outside it.
Why Detection Struggles
What makes this a difficult detection problem is that the agent's toolbox is identical to the developer's. Curl, git, node, and kubectl are the core of any legitimate development and operations workflow. An agent running curl with a token in the header, or reading a Kubernetes config, in no way establishes credential theft — that is often exactly what the task required. A rule set that flags these patterns will either flood analysts with false positives or be defined so narrowly that it loses its value.
Trellix's conclusion is that security teams must move from single events to correlation: which agent accessed a secret, how the value was used, and whether data subsequently left the host. That requires linking credential access, process execution, file changes, and network traffic across systems — a capability many organizations today have neither the tools nor the procedures for. Single-log analysis, the norm in many SOCs, sees each event in isolation and cannot distinguish the harmless curl command from the problematic one.
Prompt Injection as an Amplifier
The risk model becomes sharper when you add an attack vector Trellix mentions directly: prompt injection. The agent's capabilities — reading files, running commands, fetching web pages — can be redirected by instructions hidden in untrusted project files or web content. A malicious README, a package description, or a web page the agent reads can steer the agent toward reading secrets or sending them somewhere they should not go.
In this framing, the attacker does not need to compromise the machine or break the vault. It is enough to get the agent to use the capabilities it already has, against a different target. Existing credential access plus injected instructions produces a leak path in which all technical security controls have nominally functioned.
As background context — clearly separated from the Trellix material — Palo Alto Networks' Unit 42 has confirmed 22 types of prompt injection techniques used in real environments, with goals including promoting phishing sites, unauthorized transactions, leaking sensitive data, and leaking system prompts. It is worth emphasizing that this comes from separate coverage (Masato Kawakami, citing Unit 42) and does not document the Trellix analysis. But it shows that controlled redirection of agent behavior is not a theoretical concern; the technique pattern is documented in practice, and sensitive data leakage is among the goals.
What Trellix Recommends
The countermeasures from Trellix, as CyberPress relays them, address the problem on several levels at once:
- Keep secrets out of command arguments and model context. This is the most direct answer to both main mechanisms: don't let the token sit in a curl header or let the contents of a .env file reach the model.
- Credential brokers. Instead of the agent itself handling the value, authentication is mediated by an intermediary that never exposes the secret in plaintext to the agent or its toolchain.
- Controlled input channels. Restrict which files, URLs, and data sources the agent can accept instructions and content from — a direct response to the prompt injection risk.
- Redaction before model submission. Remove or mask secrets from the data before it is sent to the model, so the context window never becomes an export channel.
- Restrictions on insecure transport and unauthorized uploads. Limit the agent's ability to send data off the host outside controlled channels.
What the measures have in common is that they move the security boundary from the vault — which already works — to the agent's data circulation, which today is largely unregulated.
Open Questions
The risk model raises several questions the sources do not answer. How widespread is the practice of agents actually reading .env files and credentials files into the context window? It depends on the agent's permission model, and the Trellix analysis, as covered, provides no quantification. How effective are redaction and credential brokers in practice, when agents combine tools in unpredictable ways? And who bears responsibility when a legitimate agent sends a legitimate secret to a legitimate model provider — the developer who invoked the agent, the agent vendor, or the organization that configured the permissions?
The source base also sets limits: the whole picture rests on one secondary account of one company's analysis, with no documented incident and no access to the underlying document. The illustrative examples are not confirmed as real observations. That does not mean the risk model is wrong — the mechanisms are concrete, and the logic of the isolation gradient can be verified against how agent tools actually work. But it is not yet supported by documented leaks or numbers.
That is nonetheless why the analysis deserves attention: it points to a gap that neither existing vault security, EDR, nor the model's own security frameworks covers. The secret's journey from encrypted storage to model context consists entirely of lawful actions. Security models that only look for unlawful ones have, for now, little to react to.