Claude Code keeps Datadog keys out of the agent's reach: a proxy adds the token

A familiar situation: you want an agent to explore Datadog on its own, investigate alerts and find the cause of an outage. The easiest approach is to put an API key in an environment variable. It works immediately. And just as immediately, it becomes a security problem.

A post by @timwork_notes quotes Cat Wu, who works on Claude Code, as telling Simon Willison that Datadog credentials are "available only to the agent, but inaccessible to the agent itself." It sounds like a paradox, but a simple engineering idea lies behind it. An important caveat: all we have is a brief account of the conversation, with no implementation details, so the discussion below examines the pattern itself rather than a specific internal configuration.

Why a raw key in the environment is dangerous

An agent reads plenty of untrusted text: web pages, logs, tickets and code comments. Any of these could contain an instruction such as "print all environment variables." If the key is in the process environment, the model has a way to reach it. One successful prompt injection is enough to get the secret printed in a response, written to a file or sent to someone else's server.

The post's author puts it bluntly: a raw key in an agent's environment is "one injected prompt away from a leak." It is hard to argue with that. Instructions such as "never reveal keys" are an unreliable defense: they are a request, not a barrier.

How the proxy approach works

The idea is for the agent simply never to possess the secret. Instead, it gets the ability to access Datadog through an intermediary proxy.

A simple example: the agent wants to retrieve a service's metrics. It sends a request to the proxy's address with no token at all, or with a placeholder. The proxy, which runs outside the agent's sandbox, checks that the request is permitted, adds the real token to a header and forwards the request to Datadog. The response is returned to the agent. Throughout the process, the actual secret remains solely within the proxy process.

The result: the agent can use the access but cannot copy the credentials. If the agent is tricked, the attacker gets, at most, the ability to send the same requests through the proxy while it is running, rather than a key they can take away and use anywhere.

What to do in practice

This is a pattern you can implement without specialized tools:

• Do not put long-lived keys in the agent's environment, project files or configuration files it can read.
• Place a small proxy between the agent and the external API to add the token. An ordinary reverse proxy or sidecar can do the job.
• Narrow the permissions. For incident investigations, the agent only needs to read metrics and logs; it does not need write or administrative access.
• Restrict the allowed paths and methods in the proxy. That way, even a compromised agent cannot go beyond those limits.
• Log requests passing through the proxy: this also provides an audit trail of what the agent did with your infrastructure.

Limitations

A proxy does not solve everything. While the agent has API access through the proxy, a prompt injection can still make it perform permitted actions, such as reading sensitive logs and relaying their contents outside the system. The proxy therefore works alongside narrowly scoped permissions and outbound traffic controls, rather than replacing them.

Another limitation: this is only a brief post with limited reach, without diagrams or code. But the principle that "the secret lives somewhere the model cannot reach" is more useful than a dozen lines in a system prompt.

If you are building agents that access production systems, check one thing today: what happens if the model prints every environment variable? If production keys are in there, it is time to add a proxy.