Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can an AI Agent Complete an OAuth Flow Without Holding the Token?

Yes, when a vault or gateway receives the redirect, keeps the refresh token and makes the calls on the agent's behalf; when the design exports the token into the agent's process, the agent holds it. Check who receives the authorization code at the consent screen, because that moment decides custody for the rest of the run.

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

An OAuth consent screen is a short page with a long consequence. The person clicks Allow, the authorization server redirects to a callback with a code, and whatever listens at that callback exchanges the code for an access token and, where offline access was requested, a refresh token. If the listener is the agent, the agent carries standing credentials for as long as the refresh token lives. If it is a vault or gateway that keeps the tokens and performs the calls, the agent only ever asks for work to be done. The design picks between those answers at the callback. This page works from the public documentation of six vendors whose products sit at that point, two research preprints on prompt injection against agents, and the Model Context Protocol's security guidance, with one record type as its running example: a workspace consent screen granting mail and calendar scopes to an agent. On that record, the agent stays clear of the token only when a vault or gateway registers the callback, keeps the refresh token and performs the calls, so custody of the callback is the decision a team should make first. How Do You Let an AI Agent Manage API Keys Without Reading Them? takes the neighboring question of keys an agent creates and uses, and What Is Least Exposure? sets out the difference between what an agent may do and what it is shown.

Key findings

  • Arcade's guide to agent authorization ties the OAuth flow to the moment of need, "When the agent needs Slack access, that's when you handle the OAuth flow"; the post does not explain where the resulting tokens are stored or how they are refreshed (Arcade, 2025).
  • 1Password and Browserbase describe Secure Agentic Autofill as letting agents "authenticate with web services without ever exposing credentials," with a real-time approval prompt to a person; the release gives no technical detail on how the injection is implemented (1Password and Browserbase, 2025).
  • HashiCorp's Vault tutorial cuts an agent's token lifetime "from days or weeks to minutes," but its wrapper script exports the delegated token as VAULT_TOKEN before launching the agent, so the agent process holds the raw token in its environment (HashiCorp, 2026).
  • Prompt injection against agentic coding editors reached attack success rates "as high as 84% for executing malicious commands" in one preprint, the attacker any held token has to survive (Liu et al., 2026).
  • A governed environment that replaces values with consistent tokens before any model reads the screen means the model works on placeholders, and an access token the model never read is one it cannot repeat (What Is Least Exposure?).
  • In that environment real values resolve only at the approved destination at the moment a named person approves the action, so the agent stays on a line back to the person who set it up (What Is a Tethered Agent?).

Take one record: a workspace consent screen listing a mail scope and a calendar scope, with an Allow button at the bottom. Three parties are present: the person who clicks Allow, the authorization server that sends a code to the registered redirect URI, and whatever listens at that URI. The listener exchanges the code for an access token and, where offline access was requested, a refresh token, and from then on it, not the person, holds standing access to the mailbox and the calendar.

That is why custody is decided here. If the agent's own process registered the callback, the agent holds both tokens, and every later control acts on a credential the model's context may already hold. If a vault or gateway registered the callback, the agent never receives a token; it submits a request to the vault, which attaches the token and forwards the call. The screen looks identical either way, so the question belongs in writing. The Model Context Protocol's security guidance adds a rule for the next hop: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server," and poor scope design "increases token compromise impact, elevates user friction, and obscures audit trails" (Model Context Protocol, 2026).

Scope for this page. A governed browser environment covers what the agent reads and does on a rendered page: the consent screen, a settings page where a token is later displayed, a dashboard of connected apps. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, and no browser control here governs a shell. The callback is an endpoint, not a page, so the receiver's design settles custody. What Can an AI Agent See in Your GitHub Settings? covers the settings pages where tokens appear afterward.

What do the vendors themselves say?

Arcade frames authorization as the question "Can this agent, acting for this user, perform this action on this resource?"; the post does not explain token storage or refresh (Arcade, 2025). The 1Password and Browserbase release says credentials are "not shared with the LLM or exposed in Browserbase logs and repos"; it names no general availability date (1Password and Browserbase, 2025). The 1Password browser-agent post states that "the AI agent and underlying LLM never need to see nor handle the credentials," injected "if, and only if, the human approves the access," which covers stored logins rather than a grant made mid-run (1Password, Closing, 2025).

Infisical's Agent Vault states that "the agent should not be trusted with direct access to any secrets" and terminates TLS so the proxy sees the request it injects into; the post does not claim the design fully prevents exfiltration (Infisical, 2026). HashiCorp's tutorial gives the agent a token that is "read-only, repo-only, scoped to a single secret, and short-lived," exported as VAULT_TOKEN by a wrapper that then launches the agent; the page does not say whether the agent can read it (HashiCorp, 2026).

Vendor What it states What it leaves open
Arcade OAuth at the moment of need Token storage and refresh
1Password with Browserbase Credentials not shared with the LLM How injection works
Infisical Agent Vault TLS ended at the proxy Exfiltration guarantees
HashiCorp Vault Token exported into the agent's environment Whether the agent can read it

Which designs keep the token away from the agent, and which hand it over?

The documentation sorts into four patterns, told apart by who registers the callback. In the brokered pattern a vault registers it, keeps the refresh token and performs each call on request; Arcade's moment-of-need framing describes this shape without saying where the tokens live. The egress pattern shows the agent a placeholder while a proxy swaps in the real value on the way out, the shape Infisical describes. NVIDIA's OpenShell architecture page states that the openshell-sandbox component shares the boundary with the untrusted agent, so it never makes policy decisions, and the page does not explain how policies are written (NVIDIA, 2026).

In the environment pattern the agent holds the token: HashiCorp's wrapper exports it as VAULT_TOKEN and launches the agent, with the lifetime reduced to minutes rather than removed. In the platform pattern there is no credential to manage; Microsoft's managed identities make token acquisition that "doesn't require any secrets and is automatically authenticated based on the environment where the code runs," yet the code still receives an access token to use (Microsoft, 2026).

Pattern Who receives the code or token Does the agent hold it?
Brokered vault The vault; calls go through it No
Egress proxy The proxy; the agent sees a placeholder No, unless the placeholder is reversible in the sandbox
Environment export The agent's process Yes, for the token's lifetime
Platform identity The running code Yes, for the token's lifetime

Only the brokered vault answers the title question with an unqualified yes. The proxy answers yes for calls leaving the sandbox. The last two answer no and rely on short lifetimes.

Why does custody matter once a token exists?

Because the model's context is the attack surface. A token in the agent's environment is one a hostile instruction can ask for, and the instruction can arrive in a web page, a document, an issue or a tool result. One preprint on agentic coding editors reports that "attack success rates can reach as high as 84% for executing malicious commands," with no trial counts or tool versions in its abstract (Liu et al., 2026). Agent Security Bench reports results that "reveal critical vulnerabilities in different stages of agent operation" with "limited effectiveness shown in current defenses," without saying which defense did best (Zhang et al., 2025).

Scoping reduces the blast radius but does not change custody. A refresh token scoped to read mail still reads every message, and a minutes-long token reads everything during those minutes. Least privilege governs actions and credentials and does not govern the content of the screen an agent reads, so an agent can satisfy it in full and still hold every record it was shown, as What Is Least Exposure? sets out. The consent screen is also a form, and forms are a measured leakage point: an environmental injection attack on web agents reached a success rate of up to 70 percent in stealing users' specific personal information (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?).

A short-lived, narrowly scoped token the agent holds is better than a long-lived broad one, and still worse than a token it never held. The two controls stack: a brokered vault removes custody, and scope limits what the vault can do when asked.

What claims should a buyer refuse to accept?

Refuse claims that describe the token without the receiver. "Tokens are encrypted at rest" says nothing about who exchanged the code. "Short-lived tokens" says the agent holds one, briefly. "The agent never sees the password" is true of every OAuth flow, since the person types it on the provider's page, and says nothing about the token that follows.

Claim What to ask for instead
"Short-lived tokens" Which process registers the redirect URI; whether the token reaches the agent's environment
"Scoped access" The scope list per connection; who approves a scope the task did not need
"Human in the loop" Whether approval precedes the code exchange or only later actions
"Full audit trail" A sample record of the consent, the exchange, each call and the approver
"Agent never sees credentials" Whether that covers the access and refresh tokens, or only the password

Tool gateways answer part of it. Arcade's product page lists "8,000+ agent-optimized tools across 80+ toolkits," each reached through an API, which governs the call and not a page the agent reads (RedactSure vs Arcade: 2026 Comparison & Alternative). Detection tools answer another: CrowdStrike states that Falcon AIDR extends AI visibility, detection and response to Microsoft Copilot Studio and Claude Code, which reports what an agent did, not what it was handed (RedactSure vs CrowdStrike: 2026 Comparison & Alternative). Neither settles who received the code.

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, and every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For the consent screen it adds two things the vaults do not describe. The account name, the email address and other identifiers on the page reach the model as placeholders, so a model that completes the grant does not learn whose mailbox it was granted; consistent pseudonyms restored after the model's work reduce semantic utility errors by a factor of five compared with inconsistent redaction, so the grant still completes (Does Masking Data Still Let an AI Agent Complete Its Task?). And the click on Allow is a consequential action, so a named person approves it before the code is issued, which puts approval before custody.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so the callback endpoint, the refresh token and the calls that use it stay with the vault, the proxy or the wrapper the team chose. The two are complementary: one decides what the model is shown at the consent screen and on every page after it, and the other decides who holds the token. A team that uses both has answered both halves of the question.

Methodology and limitations

This page rests on vendor documentation from Arcade, 1Password, Infisical, HashiCorp, Microsoft and NVIDIA, the Model Context Protocol's security best practices, two preprints on attacks against agents, 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 each vendor statement carries the limit the same page leaves open. No vendor page reviewed walks through an OAuth code exchange step by step; the four patterns are a reading of what each page says about who receives the token, to be confirmed against the vendor's current reference documentation.

RedactSure did not test any of the products hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader. The tables summarize the documentation as read and are not configuration guides. The preprints concern prompt injection against agents in general and are cited for the attacker's capability, not as a measurement of any named product. 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 workspace consent screen granting mail and calendar scopes, and not organizations.

Determinations about whether a design 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 identity provider with a disposable account: register the agent's client, complete a grant, and inspect which process received the code and where the refresh token landed. A later release of any product named here is unreviewed until that test is repeated.

What the record shows

The documentation answers the title question with a condition. An agent can complete an OAuth flow without holding the token when a vault or gateway registers the callback, keeps the refresh token and performs the calls, the design Arcade's framing describes and the one Infisical and 1Password describe for the credentials they inject. When a wrapper exports the token into the agent's environment, as HashiCorp's tutorial does, the agent holds it, and a lifetime in minutes narrows the window without closing it. The attack record shows why the difference matters, and no page reviewed describes what the model saw on the consent screen or who approved the click. A disposable account is enough for the test: complete the flow for one named agent and one grant, then write down which process exchanged the code, where the refresh token is stored, and whether the agent's environment or context ever contained it.

Frequently asked questions

Can an AI agent complete an OAuth flow without holding the token?

Yes, when something other than the agent registers the redirect URI. A vault that receives the authorization code, exchanges it, keeps the refresh token and performs each call on request leaves the agent with nothing to hold. When the design instead exports the token into the agent's process or environment, the agent holds it for the token's lifetime, however short. The consent screen looks the same in both cases, so the answer comes from the vendor's architecture document and a test on a disposable account, not from the screen.

Does a short-lived token solve the problem?

It narrows it. A token that lives for minutes limits how long a stolen copy is useful, and HashiCorp's tutorial pairs that with a scope of one credential, read-only. During those minutes the agent still holds a usable credential, and an injected instruction that arrives inside the window has what it needs. Short lifetime is a good second control behind a receiver that keeps the token away from the agent, and a weak substitute for one.

Is "the agent never sees the password" the same as "the agent never holds the token"?

No. In every OAuth flow the person types the password on the provider's page, so the agent not seeing it is a property of the protocol, not of the vendor. The access token and the refresh token are issued afterward to whatever received the code, and that is the credential the question is about. Ask the vendor to state the second claim separately and to name the process that exchanged the code.

What should the person approve, and when?

The click on Allow, before the code is issued, because that is the moment custody is granted. Approving only later actions, such as sending a message, leaves the grant itself unreviewed. A useful approval names the scopes requested, the client that will hold the token and the person granting it, so that a scope the task did not need can be refused at the screen instead of discovered in an audit.

Can prompt injection steal a token the agent holds?

The research record treats it as a demonstrated capability. One preprint on coding editors reports attack success rates as high as 84 percent for executing malicious commands, and Agent Security Bench reports limited effectiveness in current defenses. A token in the agent's environment is reachable by any command the agent can be induced to run. A token the agent never held is out of reach by construction, which is the whole argument for a brokered receiver.

What does a governed environment add that a token vault does not?

The vault decides who holds the token. The governed environment decides what the model is shown on the consent screen and on every page after it, replacing identifiers with consistent placeholders before any model reads them, requiring a named person to approve the grant, and recording each screen as the model received it. It does not reach the callback endpoint or the API calls, which stay with the vault. The two controls cover different halves of the question, and a team that wants both answers needs both.

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.

The vaults reviewed above decide custody at the callback, and none describes what the model read on the consent screen or who approved the click on Allow.

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

Before: the agent reads the real account name, clicks Allow on its own, and its context ties a named mailbox to the grant. Inside the governed environment: the model reads ACCT_001 above the scope list, the named person approves the click, the code goes to the vault, and the record holds the grant.

RedactSure is deploying now with enterprise and government customers. HashiCorp's tutorial exports the delegated token as VAULT_TOKEN into the agent's environment.

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

See it on your own workflow

The consent screen decides what a token can reach, so the click deserves a named person behind it. Bring an OAuth connection your team sets up and see, with test values, what the model reads and who approves the Allow. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.