Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does an AI Agent Need Access to Your Stored Credentials?

No, because a credential can be filled at the destination after a person approves the sign-in, so the model never holds a password it could repeat, log or be tricked into sending elsewhere. Check where in your agent's architecture the credential becomes readable, and whether the model is on that path.

A workflow path passes above a recessed credential store before reaching a controlled doorway.

No, because a credential can be filled at the destination after a person approves the sign-in, so the model never holds a password it could repeat, log or be tricked into sending elsewhere. Check where in your agent's architecture the credential becomes readable, and whether the model is on that path. The question arises because the obvious way to let an agent work inside a company's applications is to hand it the same passwords, API keys and tokens a person would use. That approach treats the model as a trusted employee, when it is a text processor that will reproduce whatever it has read if a page or a prompt asks it to. This page sets out why agents end up holding credentials, what follows when a model has a secret in its context, how a credential can be used without the model seeing it, why credentials issued for the moment are safer than stored ones, how human approval fits into the flow, and what a buyer should refuse to accept from a vendor. It draws on credential protection for AI agents as the frame: the model needs the result of a sign-in, not the secret that produces it, and the two can be separated by design.

Key findings

  • The AI agent and the model behind it can be kept out of the credential path entirely: 1Password's design for browser agents states that "the AI agent and underlying LLM never need to see nor handle the credentials," which are injected "if, and only if, the human approves the access" (1Password, 2025).
  • The OWASP Top 10 for Non-Human Identities ranks secret leakage second, defining it as the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores," and ranks overprivileged identities fifth (OWASP, 2025).
  • Tool and agent platforms are converging on the same separation: Arcade describes its design as keeping credentials away from the language model, so the model requests an action and the platform performs the authenticated call (Arcade, 2026).
  • Secrets that are generated on demand and expire are a distinct category from stored static secrets, and the distinction determines how much a leaked value is worth to whoever obtains it (HashiCorp, 2025).
  • An agent that holds credentials and can act is a case of excessive agency, the OWASP LLM risk in which a model has more permissions or autonomy than its task requires (OWASP, 2025).
  • A credential vault answers where a secret is stored, not what the model reads once it is signed in, so vaulting and screen-level protection address different exposures (Can a Credential Vault Protect What an AI Agent Reads?).

Why do AI agents end up holding credentials in the first place?

Because the simplest integration is impersonation. An agent asked to update a supplier record, pull a report or file a form needs to be signed in to the application that holds the record, and the fastest way to arrange that is to give the agent the password, the API key or the session token a person would use. Browser agents make the problem concrete: the agent sees a sign-in form, and either a human types the credential while the agent watches, or the credential is placed in the agent's instructions so it can type it itself. Both routes put the secret in front of the model.

The documentation of the agent platforms themselves shows how ordinary this has become. OpenAI's system card for its Operator browsing agent describes an agent that operates in a browser on the user's behalf and the safety measures applied to it (OpenAI, 2025), and Anthropic's documentation for its computer use tool describes a model that controls a screen, mouse and keyboard, with safety guidance attached (Anthropic, 2024). An agent with a keyboard will be asked to sign in. The question is only whether the credential it types ever passes through the model.

OWASP's guidance on secrets management is written for software, but its central discipline applies directly: secrets should be injected into the process that needs them at the moment of use, not embedded in configuration or code where they can be read by anything with access (OWASP, 2024). A model's prompt is configuration. A credential placed there is a hard-coded secret with a very wide readership.

What happens when a model holds a password or token?

Three things, none of them reversible. The credential enters the model's context, which means it is part of the text the model reasons over for the rest of the session. It enters the transcript, which is logged by the agent platform, often by the application vendor, and frequently by whatever observability tooling the organization has attached. And it becomes reproducible on request: a model that has read a password can be asked to type it into a different form, include it in a message, or append it to a URL, and prompt injection exists precisely to make such requests on an attacker's behalf.

The OWASP Top 10 for Non-Human Identities names this outcome. Its second-ranked risk, Secret Leakage, is the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores" (OWASP, 2025). A model's context window, the transcript logs around it, and the vendor's own retention are unsanctioned data stores for a password that was supposed to live in a vault. The same list's fifth risk, overprivileged identities, describes what the agent becomes when the credential it holds carries more access than the task at hand.

Consider a supplier portal sign-in. The agent's task is to confirm a single invoice status. If the model has been given the portal password, it now holds a secret that opens every invoice, every payment detail and every stored bank account on that portal, and it holds it in a form that any page the agent visits afterward can attempt to extract. The exposure is out of proportion to the task, which is the condition OWASP describes as excessive agency (OWASP, 2025). The credential, not the task, defines what the agent can do.

How can a credential be used without the model ever seeing it?

By separating the request to sign in from the act of signing in. The model decides that the task requires access to a given application and asks for it. A component outside the model, one the model cannot read, fills the credential into the destination's sign-in form or attaches it to the API call. The model then sees the result: a signed-in page, or a tool response. It never sees the secret.

1Password's design for browser agents describes exactly this flow. In its account, "the AI agent and underlying LLM never need to see nor handle the credentials," which are injected "if, and only if, the human approves the access" (1Password, 2025). Arcade describes the same separation for tool calling: credentials are kept away from the language model, which requests an action while the platform performs the authenticated call (Arcade, 2026). Two vendors in different layers of the stack have arrived at the same architecture.

Approach What the model holds What a buyer should verify
Credential in the prompt or instructions The secret itself, for the whole session Whether transcripts and logs retain it
Human types while the agent watches the screen Whatever the screen shows, including a visible password field Whether the sign-in screen is masked before the model reads it
Injection at the destination after approval A signed-in page or tool result, never the secret Which component fills the credential and whether the model can read it

The third row is the answer to the title question. It requires that something other than the model act at the destination, and that the model's view of the sign-in screen be governed so the typed value is not rendered into its context (How to Secure AI Agents That Access Customer Data).

What is the difference between a stored credential and one issued for the moment?

Lifetime. A stored credential, such as a password in a vault or an API key in an environment variable, is valid until someone rotates it, which means a copy taken today works until the organization notices and acts. A credential issued for the moment, which HashiCorp's documentation describes as a dynamic secret generated on demand with a limited lease, is valid for a bounded period and then expires on its own (HashiCorp, 2025). If an agent's transcript leaks a dynamic secret, the leak is worth what remains of the lease. If it leaks a static one, the leak is worth everything until rotation.

The distinction changes what injection at the destination accomplishes. Injecting a static secret keeps the model from seeing it, but the secret still has to be rotated if the injecting component is compromised. Injecting a short-lived secret keeps the model from seeing it and limits the damage if anything else goes wrong. OWASP's secrets management guidance makes the same recommendation for software: prefer short-lived credentials and automate rotation so that no secret is both long-lived and widely accessible (OWASP, 2024).

For a buyer, the practical question is which of the applications an agent will touch can issue short-lived access, and which cannot. Many applications still rely on a username and password. For those, the design has to compensate with the other controls on this page: fill outside the model's view, approve each sign-in, and scope the session so that a signed-in agent can reach the record the task needs and no further. The access control model in NIST SP 800-207, in which access is evaluated per request at an enforcement point rather than granted once by possession of a credential, describes the target state (NIST, 2020).

How does human approval fit into the credential flow?

Approval is the trigger for injection. In the 1Password design, the credential is filled "if, and only if, the human approves the access" (1Password, 2025). That ordering matters. If the credential is filled first and a person is asked afterward, the agent is already signed in and the approval is a formality. If a person approves first, the approval governs whether the session exists at all, and an injected instruction that asks the agent to sign in somewhere unexpected produces a request a person can refuse.

Approval also has to be specific to be useful. A single consent at the start of a session that covers every sign-in the agent might attempt protects nothing, because the attacker's sign-in is covered too. The approval should name the destination, so that a request to authenticate to a supplier portal the task did not mention looks wrong to the person reviewing it. It should also be recorded, because the organization will later want to show which person allowed the agent into which system, and when (How to audit sensitive data access across enterprise applications?).

Approval of sign-in is one half of the control. Once the agent is inside the application, the screens it reads will contain the data the credential protects, and no credential control governs that. A person who approved the sign-in has not thereby approved the model reading every account number on the page, or every change the agent then proposes. The sign-in approval should be followed by the same discipline for consequential actions: a named person confirms each payment, submission and record change before it lands, and the record of the session shows both the sign-in approval and the action approvals together.

What does a governed environment change?

In a governed environment, the agent completes a sign-in without the model ever holding the credential, because the value is filled at the destination after a named person approves the sign-in, and the screens the agent reads afterward arrive as tokens.

This class of control keeps the model off the credential path and off the data path. The credential is inserted at the approved destination at the moment of the approved action and never enters the model's context, so there is no password in a transcript to repeat or leak. Once signed in, sensitive values on the rendered screen are replaced with consistent tokens before any model reads them, and the task runs on tokens. A named person confirms what is tokenized and approves consequential actions such as submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

A vault answers a different question: it protects a secret at rest and controls who retrieves it, and if the retrieving component is the model, the vault has delivered the secret into a transcript (Can a Credential Vault Protect What an AI Agent Reads?). Each sign-in waits for its own approval, so session-level consent does not stand in for it, and credentials whose lifetime is bounded limit the damage from any gap a demonstration did not cover (HashiCorp, 2025). The record holds the sign-in screen as the model saw it, the approval and the person who gave it, and a transcript in which the secret is absent.

The control does not alter the application, the user's permissions or the model, and it does not replace the vault or the policy for issuing and rotating credentials.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design keeps the model off the credential path and off the data path at the same time. The agent works inside a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so a sign-in page, a settings page or a customer account reaches the model with sensitive values replaced by consistent tokens such as ACCT_001 or PATIENT_001 for the whole run. Real values, including the credentials a sign-in requires, resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change, which RedactSure calls Supervised Delegation. 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.

Deployments are in pilot. A pilot on the reader's own sign-in flow would show the sign-in screen as the model saw it, the approval that released the credential at the destination, the person who gave it, and a transcript with no secret in it. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on vendor documentation and standards guidance: 1Password's published design for credential handling by browser agents, Arcade's description of its credential separation for tool calling, OpenAI's system card for its Operator agent, Anthropic's documentation for its computer use tool, HashiCorp's Vault tutorial on static and dynamic secrets, OWASP's Secrets Management Cheat Sheet, the OWASP Top 10 for Non-Human Identities Risks 2025, OWASP's LLM06:2025 entry on excessive agency, and NIST Special Publication 800-207 on zero trust architecture. All sources were read as of October 16, 2026. Vendor designs are described only from the vendors' own pages listed below, and the facts attributed to each vendor are those its page states.

No hands-on testing of any product was performed. Where this page says a capability is "not described," it means not described in the pages reviewed, not that the capability is absent. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot, and are confined to the section on where the company sits. The supplier portal sign-in and customer account examples describe record types, not any organization; no customer or prospect is described, and no vendor's product is said to fail at anything its documentation does not address.

Whether a given agent deployment's credential handling, approval flow and session scoping meet an organization's security policy, its regulatory obligations or its contractual commitments is a determination for the organization's counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

An AI agent does not need access to stored credentials to do authenticated work. Two vendors in different layers of the stack have published designs in which the model requests access and a separate component fills the credential at the destination after a person approves, so the model sees the signed-in result and never the secret. The OWASP Non-Human Identities list names the alternative, a secret in the model's context and transcripts, as secret leakage, and short-lived credentials bound the damage when any other control fails. The remaining gap is what the agent reads once signed in, which no credential control addresses and which calls for governing the screen itself. The test is to name one agent and one task and ask: at which point in this flow does the password become readable, and is the model on that path?

Frequently asked questions

If the model never sees the password, how does the agent get signed in?

A component outside the model does the filling. The model decides the task needs a given application and requests access; the component, which the model cannot read, fills the credential into the sign-in form or attaches it to the call, after a person approves. The model then sees a signed-in page or a tool result. 1Password describes this flow for browser agents, and Arcade describes the equivalent for tool calling, with the model requesting the action and the platform performing the authenticated call.

Is a credential vault enough to protect credentials from an AI agent?

A vault protects the secret at rest and controls who can retrieve it. The exposure this page describes occurs after retrieval, when the secret enters the model's context and transcripts. If the model is the component that retrieves or types the credential, the vault has not prevented that. The question to ask is which component retrieves the secret and whether the model can read that component's output. A vault combined with injection outside the model's view is the combination that works.

Why does it matter whether the credential is static or short-lived?

Lifetime determines what a leak is worth. A static password or long-lived API key that reaches a transcript works until someone rotates it. A dynamic secret generated on demand with a limited lease, as HashiCorp's documentation describes, expires on its own, so a copy is worth only the remaining lease. Short-lived credentials do not replace keeping the model off the credential path, but they limit the damage when some other control fails.

Does the user's consent at the start of a session count as approval?

Not in any useful sense. Consent that covers every sign-in the agent might attempt also covers a sign-in requested by an injected instruction. Approval that protects anything is specific: it names the destination, is given before the credential is filled, and is recorded with the person who gave it. A request to sign in to an application the task did not mention should look wrong to the reviewer, which is only possible if each sign-in is reviewed on its own.

What does a prompt injection gain from an agent that holds a credential?

The credential. A model that has read a password can be asked, by text on any page it visits, to type that password into another form, include it in a message or append it to a URL. Injection succeeds by making such requests look like part of the task. An agent whose model never held the credential cannot comply with that request, which is why the architecture, rather than the model's judgment, is the control that matters.

Once the agent is signed in, is the credential problem solved?

The credential problem is, but a different one begins. A signed-in agent reads every screen the credential unlocks, including account numbers, personal details and payment information the task may not need, and it can propose changes to all of them. No credential control governs what the model reads after sign-in. That calls for governing the screen itself, so sensitive values reach the model as tokens, and for a named person to approve each consequential action before it lands.

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.