Data Report · By Chris Sowa · Published
Last updated
How Do I Let a Coding Agent Call an API Without Giving It the API Key?
A proxy or adapter between the agent and the API can supply the key on the way out, as Claude Code, Docker, Browser Use and Devin each describe in some form. Check whether the key ever touches the machine the agent runs on.

Calling an API requires a key, and the agent that makes the call does not have to be the one that holds it. Claude Code, Docker, Browser Use and Devin each describe a way to keep the key on one side of a boundary and let the agent use it from the other. The designs look alike from a distance and differ in where the key sits and who can reach it. The pattern has settled quickly. Four implementations share one idea: the agent works with a placeholder or a name, and something it does not control supplies the real key. The remaining design question is where the key lives while that happens, and whether the agent's model still reads other sensitive values on the way. This page uses one record type as its example, one API key and four brokers, and it tests the pattern against the documentation and research record. The finding is that the pattern keeps the key out of the agent's hands, while what the agent's requests can still reach and who approves them remain open for the organization to control. What Is Least Exposure? supplies the framing. The vendor pages cited here were read on October 20, 2026, and each section says which statements come from them.
Key findings
- The pattern is a proxy between the agent and the API that adds the key on the way out. Claude Code's documentation describes it as masking with a sentinel and a host list, injectHosts, for sandboxed commands only, and places Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks outside the sandbox (Anthropic, 2026).
- Docker's Sandboxes credentials documentation describes a host proxy and a sentinel swap, which keeps the key outside the sandbox the agent runs in and does not address what the model reads on a rendered page (Docker, 2026).
- Data also leaves through requests an agent's client makes on its own: in EchoLeak, a zero-click injection in Microsoft 365 Copilot, the client "automatically fetches the external image URL included by the attacker" (Reddy and Gujral, 2025).
- Adaptive attackers bypassed 12 published prompt injection defenses with success rates above 90% for most, so a key the agent holds should be assumed reachable by a misdirected agent (Nasr et al., 2025).
- A governed environment that replaces values with consistent tokens before any model reads the screen means a settings page shows a placeholder where an API key would appear, which a proxy that governs only outbound calls does not provide (What Is Least Exposure?).
- Real values resolve only at the approved destination, and a named person approves each consequential call, so the approval attaches to the action and not to the model's account of it (What Is a Tethered Agent?).
What does it mean to call an API without holding the key?
An API key is a bearer credential: any request that carries it is authorized as the key's owner. In the usual setup the agent's environment holds the key, the agent includes it in requests, and anything that reads the environment or the transcript can read the key. The alternative takes the key out of the agent's hands. The agent sends a request with a placeholder, and a proxy or adapter in the path replaces the placeholder with the real key for approved hosts.
The record type is one API key and four brokers. The key is the same in each case, a key for one service. What differs is who adds it and where it lives. The design question, as the page's hypothesis puts it, is whether the key ever touches the machine the agent runs on. A proxy on the same machine is better than a key in the environment, and a proxy on another host is better still, because a compromise of the agent's machine yields a placeholder.
Scope note: the controls discussed concern what an agent holds and what a proxy does for it. A governed browser environment, discussed at the end, covers what an agent reads and does on a rendered page such as an API-key settings page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. How Do I Keep API Keys Out of Claude Code's Context Window? takes the context-window side of the same pattern.
What do the vendors themselves say?
Claude Code's documentation from Anthropic describes two treatments for a credential, denied or masked. With masking, sandboxed commands are shown a sentinel, and a local proxy substitutes the real value for hosts listed in injectHosts; Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks sit outside the sandbox (Anthropic, 2026). The key lives in a proxy on the developer's machine. What the model reads on a page, and an approver for the call, are not described in the pages reviewed.
Docker's credentials documentation for Sandboxes describes a host-side proxy that swaps a sentinel for the real credential, which keeps the credential outside the sandbox (Docker, 2026). It governs the call from the sandbox. That page's scope stops short of what the model reads on a rendered page.
Browser Use's sensitive-data page says "The LLM only sees placeholders (x_user, x_pass), we filter your sensitive data from the input text" and that "Real values are injected directly into form fields after the LLM call" (Browser Use, 2026). The page does not say what the model reads on later pages.
Cognition's Devin secrets guide says "In the browser, Devin types the value directly," that "For shell commands, it binds secrets as environment variables whenever needed," and that "All secrets are encrypted at rest" (Cognition, 2026). The page does not say whether the model sees the value.
The AWS Well-Architected guidance for agentic systems states that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026). That is a requirement for attribution. A proxy that adds a key hides the key from the agent, and it does not by itself attribute the call to the agent or to the person who approved it.
How do the four implementations compare?
| Implementation | Where the key is added | Where the key lives | What the pages reviewed do not describe |
|---|---|---|---|
| Docker Sandboxes | A host proxy, by sentinel swap | On the host, outside the sandbox | What the model reads on a page |
| Claude Code injectHosts | A local proxy, for listed hosts | On the developer's machine | An approver; what the model reads on a page |
| Browser Use sensitive data | Form fields, after the model call | Not stated on the page | What the model reads on later pages |
| Devin secrets | Typed in the browser, or bound as an environment variable | Encrypted at rest, scoped to organization, personal, repository or session | Whether the model sees the value |
The table shows a shared goal and different custody. Claude Code, Docker and Browser Use document a placeholder for the agent and a real value supplied elsewhere, while Devin documents that shell commands receive a credential as an environment variable, so the real value reaches the process that runs them. For a buyer the useful question is not which of the four to pick but where each puts the key and what each leaves for another control.
A proxy that adds a key to any request the agent sends gives the agent the key's authority for whatever host it names, so the host list matters as much as the swap. Claude Code's injectHosts is a host list for that reason. How Do You Let an AI Agent Manage API Keys Without Reading Them? covers the key-handling side, and What Is a Private Adapter for AI Agents? takes the adapter form of the same idea.
What can the key still reach?
A proxy keeps the key out of the commands the agent runs through it. For Claude Code that means sandboxed commands only, so the key must also be kept out of files and MCP configuration the agent can read. It does not stop the agent from asking the proxy to call a host. If an attacker's instruction reaches the agent, the agent can ask for a call, and the proxy adds the key if the host is on its list. Siddiqui and colleagues state the mechanism directly: "poisoned data retrieved from one component can change the model's behavior and compromise the entire system, including coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025).
Exfiltration paths other than the key are also real. EchoLeak, a zero-click prompt injection in Microsoft 365 Copilot (CVE-2025-32711), worked because the client "automatically fetches the external image URL included by the attacker," with an allowed Teams endpoint used to get past the content security policy (Reddy and Gujral, 2025). Although the example involves no API key, it shows that data leaves through requests the agent's client makes on its own.
Token and cookie theft shows why a key's lifetime matters. Microsoft describes token theft as "compromising and replaying a token issued to an identity that has already completed multifactor authentication" (Microsoft Security Blog, 2022). A key that never reaches the agent cannot be replayed from the agent's transcript. What Can an AI Agent See in Your GitHub Settings? covers the settings pages where keys are shown.
What does the leak record add?
As Help Net Security reported GitGuardian's data, the year's count was "28,649,024 new secrets exposed in public GitHub commits across 2025," Claude Code co-authored commits "leaked secrets at roughly double the baseline rate," and MCP configuration files held "24,008 unique secrets exposed in MCP configuration files" (Help Net Security, 2025). Those counts cover public repositories and do not single out any one tool's configuration.
Harvard's security office lists seven risk categories for AI-enabled systems, including Sensitive Data Exposure, Context and Memory Leakage, and Agents Connectors and Integrations (Harvard University Information Security and Data Privacy, 2026). An API key in an agent's environment sits in all three. The proxy pattern addresses the first two for the key itself and leaves the third, the connector, as the place where scope is set.
For the example record, a key behind a proxy is a key that does not appear in the context window, the transcript or a committed file, as long as the agent never held it. It is also a key that can be used by any request the agent can get the proxy to make. How Do You Isolate AI Agents From Sensitive Company Systems? describes the session properties that limit what such a request can reach.
What does a governed environment change?
A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, such as a call that changes data. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.
For this question it covers the page. If the agent works in a browser on an API-key settings page or a service console, a key shown there is replaced with a placeholder before the model reads it, and the approver sees the action before it is submitted. The proxy governs the outbound call and the governed environment governs what the model reads. They address the same placeholder idea at different layers. OWASP names the failure class as sensitive information disclosure, where a model's context or outputs reveal data that should not be revealed (OWASP, 2025).
Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so an agent that calls an API from a shell is a case for the proxy and a host list, not for a browser control.
Methodology and limitations
This page rests on Anthropic's Claude Code sandboxing documentation, Docker's Sandboxes credentials documentation, Browser Use's and Cognition's documentation, AWS Well-Architected guidance, a Microsoft Security Blog post, three research papers, a press report of GitGuardian data, Harvard University guidance, OWASP guidance and existing RedactSure research pages. Sources were read between October 16, 2026 and October 21, 2026. Quoted facts are cited to the page that states them, and the press figures are cited as reported, not as independently measured. The page is a reading of public documents and should be read with each vendor's current documentation open. Where a source supports only a premise, such as the EchoLeak example, the page says so and does not present it as proof of the design.
RedactSure did not test any of the four implementations hands-on. Each vendor page is cited for the statements it makes and for nothing it does not make. "Not described in the pages reviewed" means the pages reviewed and nothing broader. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. Examples describe record types, such as one API key behind a proxy, and not organizations.
Determinations about whether a key-handling arrangement meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Examples from other products, such as EchoLeak, illustrate a class of exfiltration path and are not findings about the four implementations. Nothing here replaces a review of the organization's own key inventory, proxy configuration and host lists.
What the record shows
Four implementations, built independently, converge on one pattern: the agent holds a placeholder and a proxy adds the key for approved hosts. The documentation reviewed shows where two of them keep the key, on the developer's machine for Claude Code and on the host outside the sandbox for Docker, and does not describe the others. The research record explains why the pattern matters, since an agent that holds a key can be coerced into spreading it, and why it is not enough, since requests the agent can get the proxy to make still carry the key. None of the sources describes what the model reads on a rendered page or who approves a call. For one named agent and one API, a team should test where the real key lives while the agent works, which hosts the proxy will add it for, and who approves a call that changes data.
Frequently asked questions
How do I let a coding agent call an API without giving it the key?
Put a proxy or adapter between the agent and the API. The agent sends a request with a placeholder, and the proxy replaces it with the real key for hosts on an approved list, so the key is not in the commands the agent runs through it. The proxy becomes the one place to apply a host list, an approval and a record of each call. Keep the key out of files and MCP configuration too, and confirm the list is short and who can edit it.
Which tools implement this pattern?
The page compares four: Claude Code's injectHosts, Docker's sentinel swap through a host proxy, Browser Use's placeholders and Devin's secrets. The documentation describes where Claude Code, Docker and Devin keep the key and does not state where Browser Use does. They differ in custody, host control and who approves a call, which should be asked in writing for any tool being considered, so the comparison rests on those three and not on product names. Keep each answer with its date.
Is a proxy on the same machine enough?
It keeps the key out of the commands that go through the proxy and out of their transcript. For Claude Code the key must also stay out of files and MCP configuration the agent can read. The key still lives on the agent's machine, so a compromise of that machine reaches it, and a proxy on another host, as Docker's host proxy sits outside the sandbox, reduces that exposure. Write down, for each tool, whether the key touches the agent's machine at all.
Does the proxy stop prompt injection?
No. It limits what an injected instruction can read, because the key is not in the environment. It does not stop the agent from asking for a call, and the proxy adds the key for any listed host. Adaptive attacks have bypassed published defenses with success rates above 90% for most, so a short host list and an approver for consequential calls are still needed alongside the proxy, because the proxy limits the key and not the request itself. Test with a dummy key and a dummy injected instruction.
Does a proxy cover a key shown on a settings page?
No. A proxy governs outbound calls. If the agent works an API-key settings page in a browser, the model reads whatever the page shows, so the page needs a separate control that replaces the key with a placeholder before the model reads it. A governed browser environment does that, and it does not cover a terminal, an IDE or MCP, so the two controls are used together, and each should be tested on its own surface before an agent is trusted with either.
What should a security team ask for in writing?
Ask in writing where the real key lives while the agent works, which hosts the proxy will add it for, who can change that list, and whether the call is attributed to the agent or to a person. Ask what the model reads on any page where a key appears and who approves a call that changes data. Treat undocumented items as unanswered, and ask for a dated answer from the vendor that names the service and the key in question.
How RedactSure Keeps an API Key Off the Screen the Agent Reads
A proxy adds the key on the way out, while the same key appears in the clear on the settings page where the model reads it.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the model reads the real key on the settings page, and it sits in the transcript for any misdirected request to carry. Inside the governed environment: the model reads KEY_001, pastes it into the proxy's configuration, and the real key resolves there only when the named person approves the save.
RedactSure is deploying now with enterprise and government customers. GitGuardian's data counted 24,008 credentials exposed in MCP configuration files.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A key shown on a settings page is in the model's context even if your code never prints it. Bring an API setup task and see, with test values, what the model reads while it configures the call. Book a demo





