Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do You Let an AI Agent Manage API Keys Without Reading Them?

Substitute the key with a token at the moment the dashboard renders it, let the agent carry the token through the workflow, and resolve the real value only in the approved destination field when a named person confirms. Check where your keys are revealed, because the risk moment is the one-time display on a settings page, not the vault.

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

Substitute the key with a token at the moment the dashboard renders it, let the agent carry the token through the workflow, and resolve the real value only in the approved destination field when a named person confirms. Check where your keys are revealed, because the risk moment is the one-time display on a settings page, not the vault. Developers now ask agents to do the chores around credentials: create a restricted key in a payment provider's dashboard, paste it into a deployment platform's settings, rotate a token in a source control account. Each chore has a step where a secret appears on a screen, and whatever reads that screen holds it. Vaults protect keys at rest and in distribution; they do not govern the instant a dashboard shows a key to whoever is looking, and here the one looking is a model. This page states what a governed browser environment covers and does not, locates the exposure at the render rather than the vault, describes where secret managers stop, sets out how an agent can carry a token in place of the key, explains how a team evidences that the model never read it, and lists the claims to decline. It draws on research on whether a credential vault protects what an AI agent reads.

Key findings

  • GitGuardian's data, as reported by Help Net Security, counted "28,649,024 new secrets exposed in public GitHub commits across 2025," with commits co-authored by an AI coding agent leaking secrets "at roughly double the baseline rate" and "24,008 unique secrets exposed in MCP configuration files" (Help Net Security, 2026).
  • Stripe's documentation states that a live secret key is displayed "one time," and that restricted keys tagged for an autonomous agent "are automatically subject to approval rules" requiring a designated reviewer for payouts, refunds and configuration changes (Stripe, 2026).
  • GitHub tells users to "treat your access tokens like passwords" and documents fine-grained tokens that can be "limited to only access specific repositories," which narrows what a leaked token can do (GitHub, 2026).
  • HashiCorp distinguishes static secrets from dynamic secrets generated on demand with a limited lifetime, which bounds the damage of exposure without preventing it (HashiCorp, 2025).
  • OWASP's excessive agency entry identifies over-granted capability as the condition that turns a leaked or visible credential into an action the task never required (OWASP, 2025).
  • An agent reaching a service through an API connector often receives more than the task needs, the companion problem examined in research on whether API connectors expose more data than an AI task needs.

What does a governed browser environment cover for this task, and what does it not?

The scope must be stated before the method, because developer workflows cross surfaces that a browser control does not reach. A governed browser environment covers what an agent reads and does on a rendered page: the API keys page of a payment provider's dashboard, the environment variables page of a deployment platform, the tokens page of a source control account, a cloud console, a sign-up form for a new service. On those pages it governs what the model receives and what actions are committed through the page's controls.

It does not cover the terminal. An agent running shell commands, reading environment variables with a command, or printing a configuration file is outside the browser, and nothing described on this page governs that shell. It does not cover the IDE or the local filesystem: a key written into a source file, a dotfile or an MCP configuration file is handled by whatever reads that file, and the GitGuardian figures on secrets in MCP configuration files describe that surface (Help Net Security, 2026). It does not cover direct API calls the agent makes from code or through a tool-calling layer, and it does not cover MCP servers or the credentials they hold.

The practical consequence is that a developer team should map each credential chore to its surface before choosing a control. The portion on dashboards, consoles and settings pages is where a browser environment can keep the key out of the model. The portion in a shell, an editor or a connector needs controls built for those surfaces. Nothing on this page implies that a browser control governs a shell.

Where is the key exposed: the vault or the dashboard render?

Secrets management has concentrated on storage and distribution, and the numbers show the problem persists. Help Net Security's report on GitGuardian's findings counts more than 28.6 million new secrets exposed in public GitHub commits during 2025, with commits co-authored by an AI coding agent leaking at roughly double the baseline rate (Help Net Security, 2026).

Trace the dashboard chore. Take a payment provider's API keys page. A developer, or an agent acting for one, creates a restricted key. Stripe's documentation states that a live secret key is displayed one time (Stripe, 2026); the page shows it once, and the user is expected to copy it to its destination then. That single render is the exposure moment. After it, the dashboard will not show the key again. Whatever read the page during that render holds the key: a person's eyes and clipboard, or a model's context.

The vault is not where this happens. A vault stores the key after it has been created and copied in. If the agent read the key from the dashboard first, the vault's controls describe a secret the model already holds. The destination is the same: the environment variable is protected once set, but the agent that set it read the value to type it. The exposure is at the render of the keys page, and the control must act there. Research on screen-level tokenization versus API-level filtering draws the same distinction between where data is stored and where it is read.

How do vaults and secret managers handle the key, and where do they stop?

HashiCorp distinguishes static secrets, which persist until rotated, from dynamic secrets generated on demand with a limited lifetime (HashiCorp, 2025). Azure Key Vault and Google Cloud Secret Manager document centralized storage of secrets with access control, versioning and logging (Microsoft, 2026; Google Cloud, 2026). OWASP's Secrets Management Cheat Sheet sets out the surrounding practices: centralize, rotate, restrict access, audit, keep secrets out of code (OWASP, 2024).

Control What it protects What it does not address on the keys page
Secret manager Storage, access control, versioning, audit The one-time display before the key is stored
Dynamic secrets Lifetime of a secret Whether the model read it during that lifetime
Restricted keys and approval rules (GitHub, Stripe) Scope of what a key can do; reviewer for payouts and config changes Whether the key's value entered the model
Tool-calling credential layer Credentials for API-mediated tool calls Pages the agent reads in a browser
Substitution at the rendered screen What the model receives from the page Shell, IDE, filesystem, API calls, MCP

Secret managers begin after the key has been copied in; dynamic secrets and narrow scopes reduce the damage of a leak without preventing the read. Arcade's blog describes keeping credentials away from the LLM by injecting them at the tool-calling layer (Arcade, 2026); that addresses the API surface and is not described in the pages reviewed as covering a browser agent reading a dashboard. No single row covers all surfaces.

How does the agent handle a token in place of the key on screen?

On the dashboard surface, the method is substitution at the render. When the keys page displays the new secret key for its one-time view, the environment replaces the value before the model reads the page, and the model sees KEY_001. The agent navigates to the deployment platform, opens the environment variables page, creates a variable named for the service, and enters KEY_001 in the value field. At that point the destination field is an approved destination, a named person confirms the action, and the environment resolves KEY_001 to the real key in that field, and only there. The model never held the key; the deployment platform received it.

Two vendor features complement this. GitHub's fine-grained personal access tokens can be limited to specific repositories (GitHub, 2026), so the key carried as a token also has a narrow scope. Stripe's restricted keys tagged for an autonomous agent are automatically subject to approval rules that require a designated reviewer for payouts, refunds and configuration changes (Stripe, 2026), so even a leaked key could not move money without a person. The three controls address three failure modes: the model reading the value, the value doing too much, and the value acting without review.

Rotation works the same way: the dashboard displays a new value once, the environment substitutes KEY_002, the agent updates the destination, and the person confirms. Where the chore leaves the browser, into a shell command or an editor, the scope section applies and a different control is needed. Research on reducing shadow AI agents across the enterprise notes that developer agents are among the hardest to govern precisely because they cross these surfaces in a single task.

How should a developer team evidence that the agent never read the key?

The evidence is a record of what the model received on each screen, produced by the environment that performed the substitution. For the keys chore, the record shows the dashboard page as the model saw it, with KEY_001 where the one-time value appeared; the deployment platform's settings page with KEY_001 entered in the value field; the named person's confirmation; and the resolution event at the destination. A reviewer can state from it that the model's input contained no key value at any point in the run. A vault log, which shows storage and access events, cannot support that statement, and neither can the dashboard's audit trail.

The record also answers OWASP's excessive agency concern. The entry describes agents granted more functionality or permission than their task requires (OWASP, 2025). A record showing that the agent carried a token, that the destination was approved, and that a person confirmed the entry is evidence that the agent's authority over the key was bounded to the task. The provider's own controls, a fine-grained token's repository list or a restricted key's permission set, document what the key could have done even if the record had shown a failure.

Finally, the team should evidence the boundary. The record covers the browser surface. For the shell and the editor, the team's evidence is whatever the secret manager and the repository scanner produce, and the GitGuardian figures suggest that evidence will show leaks (Help Net Security, 2026). Presenting both records with the surfaces labeled is more credible than a single claim of coverage.

What does a governed environment change?

In a governed environment, the one-time display of an API key renders to the model as a token, so the agent can complete the key rotation chore without the key ever entering its context.

The mechanism is a class of control that sits between the rendered page and the model. Sensitive values on the screen, including a newly generated secret key, are replaced with consistent tokens before any model reads them, and the task runs on those tokens. The agent copies the token from the dashboard and carries it to the deployment platform's settings field; the real value resolves only at that approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions, including the paste into a production configuration and any payout, refund or permission change the key could authorize. Every screen as the model received it, in token form, every action and every approval is recorded and exported to the organization's own logging.

This bears on the title question because the exposure is the display, not the vault. Stripe shows a live secret key one time (Stripe, 2026), and that display is where a model reads it; a secret manager's access control begins after the copy. Short-lived secrets bound how long a leaked key is useful (HashiCorp, 2025), but a model that read the key during its lifetime can use it during its lifetime, and a model that read a token cannot. The record produced by the environment is the evidence the team was asked to provide above: the one-time display page as the model saw it, with the key absent.

The control covers the rendered page and not the terminal, IDE, MCP configuration file or filesystem, and it does not change the dashboard, the key's own permissions or the model.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Its design governs the browser surface described on this page and nothing beyond it. Agents work inside a governed environment in the customer's own cloud. On every rendered page, including the one-time display of a new API key on a provider's dashboard, substitution happens at the render layer before any model reads the screen, so the key reaches the model as a consistent token such as KEY_001 for the whole run, alongside tokens such as ACCT_001 for account identifiers on the same pages. Real values resolve only at approved destinations at the moment of an approved action, which for this chore is the value field on the deployment platform's settings page. A named person confirms the tokenization policy and approves every payment, submission and record change, the arrangement RedactSure calls Supervised Delegation, so the entry of the key into its destination is confirmed by a person who can see what the agent could not. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP.

Deployments are in pilot. A pilot on the reader's own keys chore would show the dashboard page as the model received it, the token carried to the destination, the confirmation, and the record. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on Help Net Security's April 2026 report on GitGuardian's State of Secrets Sprawl findings, Stripe's API keys documentation, GitHub's documentation on managing personal access tokens, OWASP's Secrets Management Cheat Sheet, HashiCorp's Vault tutorial on static and dynamic secrets, Microsoft's Azure Key Vault overview, Google Cloud's Secret Manager documentation, Arcade's blog on keeping credentials away from the LLM, the OWASP Top 10 for LLM Applications entry on excessive agency, and published RedactSure research pages on credential vaults, API connectors, screen-level tokenization and shadow AI agents. All sources were read as of October 16, 2026.

No hands-on testing of any product was performed for this page. Where a vendor's product is described as not covering a surface, the statement means not described in the pages reviewed, not that the product lacks the capability. Vendor features change, dashboard behavior and key management features in particular, and the page carries its date. The GitGuardian figures are quoted as Help Net Security reported them. Statements about RedactSure describe its current design, with deployments in pilot, and the scope statement about surfaces it does not govern is part of that design description. The payment provider's API keys page and the deployment platform's settings page describe record types, not any organization; the chore and the token names are illustrative.

Whether a given credential workflow meets an organization's obligations under PCI DSS, its cloud provider agreements or its own security policy is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

The exposure of an API key to an AI agent happens at the render, when a dashboard displays the key once and whatever reads the page holds it, not at the vault, which begins after the key has been copied in. The secrets management stack bounds the damage of a leak through storage controls, short lifetimes and narrow scopes, and provider-side approval rules for agent-tagged keys add a person before money moves, but none of these prevents a model from reading the value on the screen. Substitution at the render does, for the browser surface, by letting the agent carry a token to the approved destination where the real value resolves under a named person's confirmation; RedactSure's environment is one implementation of that method and does not reach the shell, the editor or MCP. The test is to name one agent and one keys chore, run it, and ask for the record of what the model received on the one-time display page.

Frequently asked questions

Why is the dashboard the risk moment rather than the vault?

Because the key must be displayed to be copied, and Stripe's documentation, for example, displays a live secret key one time. Whatever reads the page at that moment holds the key. A vault stores the key after that moment; its encryption, access control and audit log describe a secret that the reader of the page already had. For an agent doing the chore, the reader is the model, so the control has to act on the page as it renders, before the model receives it.

Does a governed browser environment protect keys in my terminal or IDE?

No. A browser environment governs what the agent reads and does on rendered pages: dashboards, consoles, settings pages and sign-up forms. It does not reach a shell command that prints an environment variable, an editor that writes a configuration file, the local filesystem, direct API calls from code, or MCP servers and their configuration files. Those surfaces need controls built for them, and the GitGuardian figures on secrets in MCP configuration files show they need them.

Can dynamic secrets or short-lived tokens make the problem go away?

They shrink it. A dynamic secret generated on demand with a limited lifetime, as HashiCorp describes, means a leaked value stops working soon. Fine-grained GitHub tokens limited to specific repositories and Stripe restricted keys with narrow permissions mean a leaked value can do less. Neither prevents the model from reading the value while it is live and in scope. They complement keeping the value out of the model.

What do Stripe's approval rules for agent-tagged keys add?

Stripe's documentation states that restricted keys tagged for an autonomous agent are automatically subject to approval rules requiring a designated reviewer for payouts, refunds and configuration changes. That is a provider-side control on what the key can do without a person, which addresses the action side of the risk. It does not address whether the agent read the key's value. With substitution at the screen, the two controls cover reading and acting separately.

How is this different from a tool-calling layer that keeps credentials out of the LLM?

A tool-calling layer, as Arcade's blog describes its approach, injects credentials when the agent invokes an API-mediated tool, so the model never sees them for that path. It addresses the API surface. A dashboard read in a browser is not a tool call; the key appears on a rendered page and the model reads the page. Substitution at the render addresses that surface. A developer workflow may cross both paths.

What record should a security reviewer be able to see?

The dashboard page as the model received it, with a token where the one-time key value appeared; the destination settings page with the token entered; the named person's confirmation; and the resolution of the token at the destination. From that, the reviewer can state the model's input contained no key value during the run. The reviewer should also see which surfaces the record covers, with the shell and editor evidenced separately by secret scanning.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

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.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.