Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Is It Safe to Let a Coding Agent Create API Keys?

Only when the key is captured at the moment it appears, because a new key is shown once, on the page or in the response the agent is reading, and from then on the agent holds it. Check where the key renders at creation, who takes custody of it in that moment, and what the agent holds afterward.

A credential reference travels from a browser record through a bounded route to a separate API destination.

Letting an agent create a key is different from letting it use one. An existing key can be kept in a store the agent never opens, but a key being created has to appear somewhere, and that place is the dashboard, console or API response the agent is working in. For that moment the agent and the key are in the same place, and nothing about later storage changes what the agent already read. This page examines creation as the point of exposure, rather than storage or use. Its example is a new API key on a hosting dashboard that a coding agent generates for a deployment task, followed from the creation screen into the agent's context, its shell and the files it writes. The finding is that vendor custody controls start after the key exists, so whoever approves an agent's deployment work also accepts the copy made at creation unless a control acts on the rendered page. What Happens When an AI Agent Can See API Keys in a Console or Settings Page? covers keys that already sit on a page; this page covers the one the agent makes.

Key findings

  • A new key appears in full at creation, and an agent that reads the creation page holds the value from then on; a governed environment that replaces values before any model reads the screen is the one control class that acts at that moment (What Is Least Exposure?).
  • Real values resolve only at the approved destination, so a captured key can be used by an approved action without the model ever holding the string (RedactSure vs Skyflow: 2026 Comparison & Alternative).
  • Anthropic's Claude Code security page states that in its cloud sessions "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM," a custody design for a credential the vendor issues rather than for a key the agent creates elsewhere (Anthropic, 2026).
  • HashiCorp's agent tutorial describes a wrapper script that "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent," so the agent process starts with the raw token in its environment (HashiCorp, Secure, 2026).
  • Code models can return credentials from their training data: "two valid credentials were identified" in one study of neural code completion tools (Huang et al., 2024), and GitGuardian found Copilot "generates 2702/900 = 3.0 valid secrets for one prompt on average" (GitGuardian, 2025).
  • The Model Context Protocol specification warns that "Cloud metadata endpoints often expose IAM credentials, API keys, and other secrets," one route by which a key reaches an agent without anyone handing it over (Model Context Protocol, 2026).

Where does a new key appear when a coding agent creates it?

In one of three places, each of which the agent reads. On a dashboard, the provider renders the new key once, usually with a notice that it will not be shown again, and the agent that clicked the button reads the page. In a command-line tool, the key prints to the agent's terminal. In an API call, it comes back in the response body the agent parses. On each route the full value passes through the agent's context, because creation is the one operation where the provider must hand the value to somebody, and the agent is the somebody.

The record type for this page is a new API key on a hosting dashboard. A coding agent asked to set up a deployment finds that it needs a key, opens the provider's settings page and creates one. The key renders in a text box. From here the agent can paste it into a .env file, export it in the shell, write it into a configuration file or a CI credential, or reason about it in its next message. Each is an ordinary step in the task, and each leaves a copy of the key where the agent, or a later process, can read it again. The value is exposed in the instant of creation, and every later control is a control on copies.

Scope matters here. A governed browser environment covers what the agent reads and does on a rendered page, including dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A key the agent creates through the dashboard route is on a rendered page at the moment it appears; a key it creates through the CLI or an API call is not, and those routes stay with the team's credential tooling. Can API Connectors Expose More Data Than an AI Task Needs? looks at the API route in detail.

What do the vendors themselves say?

Anthropic's Claude Code security page describes a sandbox for Bash commands with "filesystem and network isolation," and states the limit in the same breath: "The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can" (Anthropic, 2026). For cloud sessions it describes a custody arrangement in which GitHub credentials "never enter the session VM" and the VM holds "a short-lived credential scoped to that session." That design covers a credential Anthropic issues for its own integration; a key the agent creates on a third-party dashboard enters the session through whatever the agent reads. The page closes with "no system is completely immune to all attacks."

HashiCorp's Vault documentation states that "All dynamic secrets in Vault are required to have a lease" and that "When a lease is revoked, it invalidates that secret immediately and prevents any further renewals" (HashiCorp, Lease, 2026), which bounds how long a captured value stays useful rather than whether it was captured. Microsoft's managed identities page states that "This token acquisition doesn't require any secrets and is automatically authenticated based on the environment where the code runs" (Microsoft, 2026), which removes the creation moment for Azure resources that support it and does not cover a key a third-party service issues on its own dashboard.

Source What it documents What the page leaves open
Claude Code security Sandbox for Bash; cloud GitHub credential held outside the VM Custody of a key created on a third-party dashboard
Vault leases Lease on every dynamic secret; immediate invalidation on revoke Whether the value was read before revocation
Azure managed identities Token acquisition without stored credentials Keys issued by services outside Azure

Why is a key the agent created a key the agent was given?

Because the context does not distinguish them. Once in the agent's context, the key is a string the model can repeat, and the research record shows that models repeat strings they have seen. A study of neural code completion tools found they "can not only return the precise piece of their training data" and that "two valid credentials were identified during our experiments" (Huang et al., 2024). That is memorization from training, a slower path than a key in the live context, but it establishes that a model with a credential in reach can emit it.

GitGuardian's test of Copilot found it "generates 2702/900 = 3.0 valid secrets for one prompt on average" and that "over 1,200 leaked at least one secret" (GitGuardian, 2025). The same page does not confirm whether the extracted credentials were still active, so the result is a measure of emission, not of exploitability. For the dashboard record, the point is that a key the agent read at creation has joined the set of strings the model may produce in a commit message, a log line or a configuration file.

Identity controls do not reach this. Least privilege governs what the agent may do with a credential, not the content of the screen it reads, and an agent can satisfy least privilege in full and still hold every value it was shown (What Is Least Exposure?). The same holds for the agent's authority: a tethered agent goes anywhere its supervisor could go and does real work there, and that authority includes the ability to create a key on the supervisor's behalf (What Is a Tethered Agent?). Creating a key is within scope for most deployment tasks; the issue is what the agent holds afterward.

Do short-lived and wrapped credentials close the gap?

They narrow it. HashiCorp's agent tutorial describes giving an agent a Vault token that is "read-only, repo-only, scoped to a single secret, and short-lived," with the result that "Token lifetime is reduced from days or weeks to minutes" (HashiCorp, Secure, 2026). The same tutorial's wrapper script exports the delegated token as VAULT_TOKEN before launching the agent, so the agent process starts with the raw token in its environment, and the page does not say whether the agent can read it. Lifetime is bounded; exposure at the handover is not addressed.

Response wrapping moves the problem by one step. Vault issues "a new single-use token" with "the TTL supplied by the client," and the holder unwraps it to receive the credential (HashiCorp, Response, 2026). If the agent is the holder, the agent unwraps it and reads the credential. If a process outside the agent is the holder, the agent never sees the value, which is the arrangement How Do You Let an AI Agent Manage API Keys Without Reading Them? describes. Vault states that it "does not provide signed response-wrapping tokens, as it provides little extra protection," so single use, not a signature, is the control.

Managed identities remove the key altogether for the resources that support them, since "Managed identities eliminate the need for developers to manage these credentials," in Microsoft's words. For the hosting dashboard in this page's example, the provider issues its own key and no managed identity applies, which is the common case for the third-party services a deployment touches. Is It Safe to Let an AI Agent Set Up Your Cloud Environment? covers the cloud side, where identity-based access is more often available.

What does prompt injection add when the agent holds a fresh key?

A reason to send it somewhere. An agent that has just created a key and then installs dependencies, reads documentation or opens an issue tracker is reading untrusted text with a credential in its context. The LlamaFirewall preprint describes PromptGuard 2 as "a universal jailbreak detector" and reports that its approach "shows stronger efficacy at preventing indirect injections in general scenarios than previously proposed approaches" (Chennabasappa et al., 2025); the abstract gives no quantitative results, so the residual rate is unknown from that page, and a detector that stops most injections still leaves the key in the context for the ones it misses.

The supply chain is a second route out. Code-generating models hallucinate package names at "at least 5.2% for commercial models and 21.7% for open-source models" (Spracklen et al., 2025). The abstract does not say whether those names were registered and exploited, but an agent that installs a package whose name a model invented is running code it did not vet, with the new key in its environment. The MCP specification adds a third: servers "run with the same privileges as the client," and "Poor scope design increases token compromise impact, elevates user friction, and obscures audit trails" (Model Context Protocol, 2026). Its rule that servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server" is about token audience and does not describe how a coding agent's own credentials are held.

For the dashboard record, the sequence is short. The agent creates the key, pastes it into the environment, installs a package the task calls for, and reads a README. Any of the last three steps can carry an instruction, and the key is already present.

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 such as KEY_001 rather than the value. 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. 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 acts at the moment of creation, which no storage control reaches. When the dashboard renders the new key, the policy recognizes a credential pattern and replaces it before the model reads the screen, so the agent's context holds KEY_001 and the real value is held apart. The agent can paste KEY_001 into a configuration field on another approved page, and the real value resolves there, at the destination, when a named person approves the submission. The agent's later steps proceed with a placeholder in context, and an injected instruction that asks for the key gets KEY_001. A token in this sense carries no exploitable value on its own, with the original held apart from the operational data (RedactSure vs Skyflow: 2026 Comparison & Alternative).

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a key created through a CLI or an API response is outside it and stays with the credential tooling described above. A team that creates keys through the dashboard has a control at the creation moment; a team that creates them through the API has lifetime and scope controls and none on the read.

Methodology and limitations

This page rests on Anthropic's Claude Code security page, HashiCorp's Vault documentation and agent tutorial, Microsoft's managed identities page, the Model Context Protocol security specification, three research preprints, GitGuardian's published test of Copilot and existing RedactSure research pages. Sources were read between October 20, 2026 and October 21, 2026. Quoted facts are cited to the page that states them, and the research results are cited for what their abstracts state, since the abstracts are the pages reviewed.

No vendor product was tested hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader; where a vendor page is silent on custody at the moment of creation, the page says what the vendor does document instead. The HashiCorp tutorial gives token lifetime as minutes and no fixed figure, and none is written here. The research preprints are cited for the principle they establish, not as measurements of any particular coding agent. 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 a new API key on a hosting dashboard, and not organizations.

Determinations about whether a key-creation workflow meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test on the organization's own dashboard with a throwaway key, repeated after each release of the agent or the provider's console, since either can change where the key appears.

What the record shows

The vendor pages describe custody for credentials they issue themselves and lifetime and scope controls for credentials they broker, and none of them describes who holds a key at the moment a coding agent creates it on a third-party dashboard. The research record shows that a model with a credential in reach can emit it, that injection detectors reduce but do not report a zero rate, and that package hallucination gives an injected instruction somewhere to send a value. Short-lived tokens and response wrapping bound how long a captured key is useful and can keep the agent from ever unwrapping it; a control at the render layer is the one that acts on the read itself. Counting copies is the test that settles it for a given team: let an agent create a throwaway key on a real dashboard, then grep its transcript, its shell history and the files it wrote for the value.

Frequently asked questions

Is it safe to let a coding agent create API keys?

Only with a control at the moment of creation, because the new key renders once and the agent that created it reads it. After that moment, storage controls act on copies and lifetime controls act on usefulness, and neither removes the value from the agent's context. On a dashboard, a render-layer control can replace the key before the model reads it; through a CLI or an API call, the value lands in the agent's shell or response buffer, so a short lifetime and a tight scope are the remaining levers.

Where does the key go after the agent creates it?

Wherever the task sends it. A deployment task typically writes the key into a .env file, exports it in the shell, pastes it into a CI credential or a configuration page, and may mention it in a commit message or a chat reply. Each of those is a copy, and a later process, a log or a commit can surface any of them. The practical count is the number of places the value exists after the task, and the aim is to bring that count to one or zero.

Does a short-lived token solve the problem?

It bounds it. A token that expires in minutes is worth less to whoever reads it, and HashiCorp's tutorial describes exactly that reduction, from days or weeks to minutes. The same tutorial starts the agent with the token exported in its environment, and the page does not say whether the agent can read it. Lifetime limits the damage of a read; it does not prevent the read, so pair it with a control on what the agent is shown.

What is response wrapping, and does it keep the key from the agent?

Vault's response wrapping delivers a credential through a single-use token with a client-supplied lifetime, and whoever unwraps the token receives the credential. If the agent unwraps it, the agent holds the value. If a process outside the agent unwraps it, the agent never does, and that is the arrangement to aim for. Vault states that it does not sign these tokens because a signature adds little, so single use is the property to rely on.

Can a managed identity remove the creation step entirely?

For resources that support it, yes. Microsoft's documentation states that token acquisition with a managed identity requires no stored credentials and authenticates from the environment the code runs in, so there is no key to create and no moment of exposure. The limit is coverage: a third-party hosting provider, payment service or analytics tool issues its own keys on its own dashboard, and those are the keys a coding agent is most often asked to create.

What should a security team ask for in writing?

Ask which route the agent uses to create keys, the dashboard, the CLI or the API, and what reads the value at that moment. Ask what the agent's context, shell and files hold after the task, and what the lifetime and scope of the created key are. Ask who approved the creation and the first use, and what record shows the key as a placeholder. Where a vendor page is silent, treat the custody question as unanswered until a throwaway-key test answers it.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Captures a New Key the Moment It Appears

A new key renders once and the agent that created it reads it, while leases, response wrapping and managed identities only limit how long a captured value works.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the agent creates a key on the hosting dashboard, reads the full value, pastes it into a .env file and a CI credential, then reads a README with the key in context. Inside the governed environment: the dashboard shows the model KEY_001, the agent pastes KEY_001 into the configuration page, and the real value resolves there on a named person's approval.

RedactSure is deploying now with enterprise and government customers. GitGuardian found Copilot generating 3.0 valid credentials per prompt.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

A key the agent creates tends to end up in a .env file and a CI credential. Bring a key you would ask an agent to create and see, with test values, where the real value lands. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.