Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Why Should Storing a Credential and Using It Be Separate Approvals?

Because a hijacked agent spends a credential rather than files it: if one approval covered both, the first injection would inherit everything the vault holds. Ask for two decisions, one that keeps the credential and one that names the task, the destination and the person approving that use.

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

A vault answers one question well: whether a credential may exist, where the copy lives and which people may attach it to an agent. It answers the second question only by implication, which is whether this agent, on this task, may spend the value now. The two differ in who can answer them, when the answer is given and what the answer is about. One is a standing decision about custody. The other is a decision about a single action, taken while a named person can still see the task in front of them. Merge them and the standing decision becomes a permission that every later run inherits, including a run that an injected instruction is driving. Keep them apart and an attacker who reaches the vault has reached a place where the value is kept, not a moment when it is spent. This page takes the two decisions apart, sets the scope for what a governed browser environment covers, reads what the vendor pages say about each decision, works through the record of an injection that reaches the vault and stops at the grant, and ends with what a second approval should name. The question is one of design before it is one of products, and the answer holds whether the credential is an API key, a deploy token or a session cookie.

Key findings

  • The 1Password and Browserbase release states that "credentials are not shared with the LLM or exposed in Browserbase logs and repos," a custody design that keeps the value from the model and leaves the approval of its use to a person (1Password and Browserbase, 2025).
  • Cursor's Agent Security page states that "by default, terminal commands need your approval" and that "all MCP connections need your approval," approvals placed on the action the agent proposes rather than on the credential behind it (Cursor, 2026).
  • Firecracker's design document states that "all egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level," treating the boundary a value crosses separately from the isolation that holds it (Firecracker, 2026).
  • A governed environment replaces a stored value with a consistent token before any model reads the screen, so the agent works with a key it never reads. GitGuardian counted "28,649,024 new secrets exposed in public GitHub commits across 2025" (How Do You Let an AI Agent Manage API Keys Without Reading Them?).
  • Real values resolve only at the approved destination at the moment of an approved action. That is the second approval this page asks for, and it separates a credential check from an authorization (Does Checking Credentials Stop an AI Agent From Taking Unauthorized Actions?).

What does a governed browser environment cover when an agent uses a stored credential?

Scope comes first because the answer depends on where the value would be spent. A governed browser environment covers what an agent reads and does on a rendered page: a vault dashboard, a credential settings page, a console that lists keys, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An agent that lifts a token from a variable and calls an API from somewhere else is outside this page. An agent that opens the vault's settings page and reads the key list is inside it.

That boundary decides which of the two decisions the page can describe. The storage decision is usually taken in a vault's own interface, where a person creates the credential, scopes it to a workflow and decides who may attach it. The use decision is taken wherever the value is spent. The second is the harder one to keep, because a page is where a model meets the value.

The record for this page is a credential vault's settings page that lists one stored credential for an agent workflow. The row carries a name, a scope, the workflows allowed to attach it and a reveal control. Everything this page says about a second approval is about that row and the moment its value would be spent.

AWS's guidance on access keys is why the row matters. It states that "IAM users with access keys are an account security risk" and instructs account holders not to "provide your access keys to unauthorized parties" (What Happens When an AI Agent Can See API Keys in a Console or Settings Page?). A page that renders the value renders it to whoever is reading, and inside an agent run that reader is the model.

Why is approving the storage of a credential not the same as approving its use?

The storage decision is about existence and custody. It settles whether the organization keeps this credential at all, where the copy lives, which people may attach it to an agent, and what the agent will never hold. It is taken once and reviewed on a schedule.

The use decision is about one action. It settles which agent, on which task, against which destination, for how long, and whose name is on it. It is taken at the moment the value would be spent, by a person who can see the task. The first decision cannot answer the second, because the task does not exist when the first is made.

OWASP keeps the two failures apart, naming NHI2 as the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores" and NHI5 as overprivileged identities (OWASP, 2025). An approval written once and expected to prevent both is written to cover the broader case.

Stripe's documentation shows the split in a working product, since a live secret key is displayed "one time" and a restricted key tagged for an autonomous agent is "automatically subject to approval rules" that name a designated reviewer for payouts, refunds and configuration changes (Stripe, 2026). The display is a custody event; the reviewer's approval is a use event.

Microsoft's managed identity page shows the limiting case, stating that "managed identities eliminate the need for developers to manage these credentials" and that "this token acquisition doesn't require any secrets" (Microsoft, 2026). Remove the stored credential and only the use decision remains, which shows the two are separable.

What do the vendors themselves say?

The vendor pages reviewed describe custody and gating an action. They do not join the two: none states who approves the use of a stored credential after the storage decision is closed, and that is not described in the pages reviewed.

Cursor's page warns that "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues" and describes its run modes as "best-effort guardrails rather than a hard security boundary" (Cursor, 2026). The page that documents an approval also calls the control best effort.

The release states that "Secure Agentic Autofill allows AI agents to authenticate with web services without ever exposing credentials" and lists "human-in-the-loop authorization: real-time approval prompts via 1Password mobile or desktop" (1Password and Browserbase, 2025). Its check is not documented: the release gives no technical detail on how the approval is enforced.

OpenAI's Codex documentation states that "locally, Codex uses an OS-enforced sandbox that limits what it can touch" and that "Codex asks for approval to edit files outside the workspace or to run commands that require network access" (OpenAI, 2026). The page does not describe how credentials are stored or handled in local CLI or IDE sessions.

Firecracker's design document states that "Firecracker is designed to assure secure isolation using multiple layers" and treats guest egress as untrusted traffic to be filtered at the host (Firecracker, 2026). It says nothing about credentials inside the guest.

Dimension Vendor, per its documentation What a buyer should verify
Custody Stripe: a live key is shown once, and a restricted key for an agent carries approval rules Whether the rule sits on the key or on each action that spends it
Action gating Cursor and Codex: terminal commands, MCP connections and network commands need approval Whether the approval names one task and one destination
Model exposure 1Password and Browserbase: credentials are not shared with the LLM Whether the model sees a placeholder or nothing at all
Isolation Firecracker: isolation in layers, egress filtered at the host Whether the store inside the guest is ever rendered to a model
Standing credential Microsoft: a managed identity needs no stored credential Which approval remains when there is nothing to store

What does one approval covering both decisions give an injection?

It gives the injection the second decision without a second person. The lethal trifecta, as its originator defined it, is access to private data, exposure to untrusted content and the ability to communicate externally, and an agent holding all three can be made to steal the data by content it reads (What Is the Lethal Trifecta for AI Agents?). A vault is the private data, a page the agent reads is the untrusted content, and the agent's tools are the channel out. If the approval that keeps the credential also authorizes its use, the first content that reaches the agent arrives after every gate has been passed.

OWASP counts the result as a risk in its own right, since NHI5 is overprivileged identities, a separate entry from the leakage of a stored credential (OWASP, 2025). One approval that covers a store and every use makes every stored credential overprivileged.

The measurement is of the use, not the store. A measured environmental injection attack on generalist web agents stole users' specific personal information at a success rate of up to 70 percent (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?). That rate was recorded on what an agent did with a page it read, and a vault prevents none of it.

Verizon's 2026 report finds that a share "of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in," and that "hackers are shifting their focus from tricking people to exploiting systems" (Verizon, 2026). A stolen password is a failure at the store. An exploited system is a failure at the use.

What should the second approval name, and who should give it?

The second approval should name six things: the agent, one task, the destination the value will reach, the operation, the lifetime and the person. Each omission widens the permission. Without the task, the approval covers a class of work. Without the operation, reading a record and submitting one are the same act. Without a name, it is a policy rather than a decision.

Who should give it: a person who can see the task and the destination, and who is neither the agent nor the vendor's model. The name is what an audit checks. Willison's design patterns take the same view from the agent's side, since they "constrain the actions of agents to explicitly prevent them from solving arbitrary tasks" (Willison, 2025). One of his patterns holds that "agents can trigger tools, but cannot be exposed to or act on the responses from those tools," which limits what a tool may return and leaves open who approves the call (Willison, 2025).

Google's guidance for Workspace administrators states that the super admin account should be used only when needed, a rule written for people that applies with more force to an agent (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?). An account used only when needed is an account whose every use is approved.

McKinsey's State of AI research finds 62% of organizations at least experimenting with AI agents and 23% scaling them anywhere, the gap What Is the PII Wall? describes. Most agents are in a trial, the setting in which a storage approval becomes a standing permission unless each use is approved.

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 SECRET_014. 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 page's question, that separates the two decisions in time and in subject. The policy confirmation is the standing decision: a named person says which values a model is never shown, and that decision holds across runs. The approval of an action is the use decision: one task, one destination, one moment, and a name on the record. An injection that reaches the vault finds tokens, because the stored value was replaced before the model read the page.

The separation is what the second approval adds. A single approval to store a credential can be given months before a task exists. An approval to spend it cannot, because it has to name the task, and the record keeps the two apart as different events with different names on them.

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 uses a token from a variable in a shell needs the sandbox and credential store its team configures.

Methodology and limitations

This page rests on vendor documentation from Cursor, 1Password and Browserbase, OpenAI, Firecracker, Stripe and Microsoft; OWASP's non-human identity standard; one industry report from Verizon; one practitioner analysis from Simon Willison; and existing RedactSure research pages. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and figures from industry reports are cited as reported rather than independently measured. The Verizon figures are quoted as its report landing page states them.

RedactSure did not test any of the named products hands-on. Where this page says a property is not described in the pages reviewed, it means the vendor documentation reviewed does not describe it, not that the product lacks it. Vendor features change, and the page carries its date; a release after that date is unreviewed until the checks below are repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a credential vault's settings page listing one stored credential for an agent workflow, and not an organization.

Determinations about whether a particular approval meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against its own workflow. A reader who needs a determination should take the run's record and the approvals it names to that reviewer, since the same design can satisfy one requirement and fail another. The reviewer should see the task, the destination and the record rather than the credential itself.

What the record shows

The two decisions answer different questions, and the vendor pages reviewed show the split in pieces rather than in one place. Custody designs keep a value from the model, action gates stop what the agent proposes, isolation separates the store from the boundary a value crosses, and none of them states who approves the spending of a stored value after the storage decision is closed. The record of an injection that reaches a vault and stops at the grant is therefore a record with two names on it: one for keeping the credential and one for the task that spent it. RedactSure's environment is built to produce that second approval for each action. Run this test on one agent and one task: ask who approved keeping the credential and who approved spending it, then read the record for both names and the destination between them.

Frequently asked questions

Why should storing a credential and using it be separate approvals?

Because they answer different questions at different times. Storing decides whether a credential exists, where it lives and which workflows may attach it, a standing decision made before any task exists. Using decides whether this agent may spend the value on this task, at this destination, now. If the first implied the second, an injected instruction that reached the vault would inherit every credential inside it. Kept apart, the attack has to get past a person looking at one task.

Doesn't a vault already keep the credential away from the agent?

A vault keeps the value from the agent's context only while the agent is not looking at it. The moment a page renders the value, a field reveals it, or a proxy attaches it to a request the model composed, the custody question and the exposure question part company. A vault that also renders a settings page listing the key is a vault with a page, and a page is what a model reads. Check what the run displays, not only what the store holds.

What should the second approval name?

Six things: the agent, one task, the destination the value will reach, the operation, the lifetime and the person. Each one narrows the permission. Without the task the approval covers a class of work; without the destination it covers any endpoint; without the operation it covers reading and submitting alike; without the lifetime it becomes standing. An approval that names fewer than six is not wrong, but what it omits is what a mistake can reach.

Who should give the second approval?

A named person who can see the task and the destination, and who is not the agent and not the vendor's model. The name is what makes the decision accountable and what an audit can check. A team approval, a ticket number or a policy exception leaves the question of who decided unanswered. The reviewer does not need the value itself and should not be shown it; what they need is the task, the destination and the operation the agent proposes.

Does a short-lived credential remove the need for two approvals?

No, though it shortens the second one. A token that expires in minutes limits how long a mistake stays usable, and the agent still spends it during the run, at whatever destination the task has reached. Expiry bounds the damage after a use; it does not put a person between the store and the use. Read the lifetime as one of the six things the second approval should name, not as a substitute for the approval itself.

How would an audit show that the two approvals were separate?

The record would carry two events with different dates, subjects and names: a policy decision confirming which values the environment never shows a model, and a run decision approving one task and one destination. The first repeats a name that can be checked against the owner of the credential; the second appears beside the action, with the token on the screen the agent read. If one event stands in for both, the audit shows an approval that covered more than the reviewer saw.

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 Makes Keeping a Credential and Spending It Two Decisions

One approval that covers both decisions is one decision, and the designs reviewed above separate custody from use only until the value is used.

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

Before: the agent opens the vault's settings page, the page renders the stored value, and the model reads it while an injected instruction asks it to send the value out. Inside the governed environment the same page renders SECRET_014 for the whole run, and the real value resolves only at the destination the approver chose for this task.

RedactSure is deploying now with enterprise and government customers. In 2025 GitGuardian counted 28,649,024 new credentials exposed in public GitHub commits.

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

See it on your own workflow

Keeping a credential and spending it are different decisions and deserve different approvals. Bring a task that uses a stored credential and see, with test values, where the approver sends the real value. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.