Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is Vault Enough to Secure a Browser Agent?
No, not for the screen a browser agent works on: Vault issues and bounds tokens for clients that ask it, and the session a browser agent uses at a portal is a cookie the vault never issues. Check what the model receives from the page it reads and who approves each action before an agent signs in.
For a security team that has standardized on Vault, an agent that signs into a supplier portal does the work the way a person does: it opens the page, reads the fields the application draws and clicks the button that submits the change. Nothing in that loop asks a credential store for anything. The session that lets the agent in was created by the portal at sign-in and travels as a cookie in the browser, so the value granting access is one a vault never issues and never sees. That split decides the answer for those teams once they point an agent at an application they bought rather than built. A credential path and a screen path are different surfaces with different failure modes, and a control that governs one does not reach the other by default. A policy written for a client that fetches a token says nothing about a browser that is already signed in. The record here is a single portal session, a record type that carries a member or customer record on screen, and the question is what the agent holds while the session is open and what the model receives while the page is rendered.
Key findings
- For Vault to secure a browser agent on the screen path, the values a portal renders would have to be replaced with consistent tokens before any model reads the page, with real values released only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each consequential action in the portal and a record of what the model received and who approved the change (Why Should Submitting a Credential Require Its Own Permission?).
- None of the Vault pages reviewed describes a session a portal creates for itself or the values its pages render, so the record stops where the credential is issued (HashiCorp, Lease, 2026).
- HashiCorp's agent tutorial states that "Token lifetime is reduced from days or weeks to minutes" and that the agent "receives a token that is read-only, repo-only, scoped to a single secret, and short-lived" (HashiCorp, Secure, 2026).
- ST-WebAgentBench reports that web agents' "average CuP [Completion under Policy] is less than two-thirds of their nominal completion rate" (Levy et al., 2026).
- Adaptive attacks bypassed 12 published defenses with "attack success rate above 90% for most," which is why a classifier added to a run does not decide what the model is shown (Nasr et al., 2025).
What does a browser agent read when it works a portal session?
A browser environment under this control covers what an agent reads and does on a rendered page: dashboards, consoles, settings pages and forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. The record on this page is one portal session, a signed-in browser session on a bought application, and everything the agent does inside it happens on pages the application draws. The credential boundary is not the data boundary: 9 of the 15 AI agents reviewed document keeping passwords or credentials away from the model, and 0 describe doing the same for the customer data a working page displays (Do AI Agents Ask Before Making a Payment?).
The agent starts by signing in. A person or a setup step supplies the password, the portal accepts it, and the browser receives a session cookie the portal will honor on every later request. From then on the agent does not present a credential to the application; it presents the session, and that session authorizes every page the agent opens for as long as it lives. A connection that drives the user's own Chrome keeps its cookies and login sessions, so an agent attached to a browser that is already signed in is inside every session the person left open (Can a Browser Agent Read My Session Cookies?).
What the model receives is the page. Each screen the portal renders, an account summary, a claim detail, a payment method, arrives in the model's context as text and images. The cookie is not in that text; the values the page displays are.
Where does Vault's control stop when the page renders from the application's store?
Vault's control starts and ends with a client that asks it for something. The agent permissions tutorial scopes the agent's token to "a single secret," and a wrapper script exports it into the agent's environment before the job starts (HashiCorp, Secure, 2026). A lease fixes how long an issued value stays valid: "All dynamic secrets in Vault are required to have a lease," and revocation "invalidates that secret immediately" (HashiCorp, Lease, 2026). Response wrapping protects a handover with "A new single-use token is generated with the TTL supplied by the client" (HashiCorp, Response, 2026).
Each control assumes that the value Vault hands out is one Vault holds. A portal page is drawn from the application's own store: the account number on a summary screen, the card on file, the API key a dashboard prints after a rotation, all rendered by the application, with no Vault call between that render and the model (Can an AI Agent Rotate a Key in a Vendor Dashboard Without Seeing It?). A key a console prints has no lease to revoke; the session that displayed it can end, and the value does not (What Can a Browser Agent See in My AWS Console?).
The boundary is placement. Vault can say which client read which path and for how long. It cannot say which values a page displayed to a model, because the read it governs never happened: the browser already held the session, and the application answered with its own data.
What do the vendors themselves say?
HashiCorp's pages describe custody of values Vault issues. The agent permissions tutorial states that the agent "receives a token that is read-only, repo-only, scoped to a single secret, and short-lived," and that a wrapper script "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent" (HashiCorp, Secure, 2026). The lease page states that "All dynamic secrets in Vault are required to have a lease" and that revocation "invalidates that secret immediately" (HashiCorp, Lease, 2026). The response wrapping page states that "A new single-use token is generated with the TTL supplied by the client" (HashiCorp, Response, 2026). All three describe a value the store holds; none of them describes a session an application creates or a page an application renders.
AWS's AgentCore Identity blog describes the same shape for its token vault, built to "Securely store OAuth 2.0 Access and Refresh tokens, API keys, and OAuth 2.0 client secrets," with the agent retrieving them with its own workload token (Douglas III, 2025).
| Dimension | Vault, per its documentation | What a buyer should verify |
|---|---|---|
| Where the control sits | At the store, for clients that ask it for a value | Whether the agent's portal session is issued or held there |
| What it bounds | Token lifetime, scope to one credential, lease and revocation | Whether the value on screen has a lease at all |
| What it gives the agent | A token in the environment the wrapper launches | Whether the value the page renders passes through it |
| What it records | The lease, its TTL and its revocation | Whether the record shows what the model read |
| What it leaves out | The screen an application draws from its own store | Where rendered values are replaced, and who approves |
A value the store issues is scoped, leased and revocable; a value an application renders is none of those things until someone replaces it at the page.
What does prompt injection reach once the agent is signed in?
A signed-in browser is the most useful thing an attacker can find, because the session removes the need for credentials. Indirect injection is the route: "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files" (OWASP, Prompt Injection, 2025), and a portal page or a document opened in the same tab is such a source (Is It Safe to Let an AI Agent Browse Docs While I Am Logged Into GitHub?). Harvard's guidance names the combination: "The riskiest agent setup combines three things: access to private data, exposure to untrusted content, and the ability to send data outward" (Harvard, 2026). A portal session supplies all three.
How often a filter holds is the wrong question. Adaptive attacks bypassed 12 published defenses with "attack success rate above 90% for most" (Nasr et al., 2025). A design that assumes the model may follow the page is stronger: the CaMeL work aims to ensure "the untrusted data retrieved by the LLM can never impact the program flow" (Debenedetti et al., 2025).
What injection reaches is what the page already showed the model. If the account number was rendered, an injected instruction can carry it into the next form. The control that survives a non-zero failure rate keeps the value out of the context.
What does a security team ask for in writing?
Three commitments decide whether the screen path is governed, and each one is a question a buyer can put to a vendor in writing.
First, which credentials the agent holds for the task, and whether the portal session is one of them. A vault policy covers the first part, and nothing in the pages reviewed covers the second, so the answer has to say where the session comes from and how long it lives.
Second, what the model receives from a rendered screen: whether the values a page displays are replaced with consistent tokens before the model reads them, or whether the model sees the account number, the card and the claim amount exactly as the application drew them. That question separates a credential control from an exposure control.
Third, who approves a consequential action and what record follows it. A policy written before the run and a person approving the payment are different decisions: an administrator binds a policy to a token, and a read either matches it or fails (HashiCorp, Secure, 2026). Harvard's guidance sets the standard to ask for: "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" (Harvard, 2026). The record has to answer the same two questions, what the model saw and who approved the change, and a lease record answers neither.
What does a governed environment change?
A governed environment is a control class, and it changes three things.
First, the screen. Values chosen by policy are replaced with consistent tokens before any model reads the page, so a portal summary that would show an account number shows ACCT_001 for the whole run. The token stays stable across screens, so the work no longer depends on the real value being in context.
Second, the destination. Real values resolve only at approved destinations, at the moment of an approved action, so the number reaches the payment form a person approved and not the transcript, the next page or a tool call.
Third, the approval and the record. A named person approves each payment, submission and record change, and every screen as tokens, every action and every approval lands in an exported record. An attacker who succeeds against a tokenized screen collects tokens.
None of this replaces a credential store. A vault still issues and bounds the credentials that call an API, and a governed environment governs what a page shows a model. The two controls sit at different points in the same run, and a team running agents in bought applications needs both. The comparison for this vendor sets that division out row by row (RedactSure vs HashiCorp Vault: 2026 Comparison & Alternative).
What the record shows
A browser agent's exposure is decided where a page renders: what the screen draws is what the model receives, and no credential store sits between the two. A credential store governs the other half, bounding which client may fetch an issued credential and for how long. A portal session is created by the application and held by the browser, so the credential the agent uses never reaches the store. Name one agent and one portal task, then run the same test on the first screen that carries a real value: compare what the model received with the credential the store issued for that run. If the only record you can produce is a lease, the screen path is ungoverned.
Methodology and limitations
This page rests on HashiCorp's Vault documentation and its agent permissions tutorial, AWS's AgentCore Identity blog, OWASP's prompt injection entry, Harvard's generative AI guidance, and three research preprints. The pages were read between October 16, 2026 and October 21, 2026, and each Sources line carries its date. Public documentation read in full gives a sound view of where each product applies its control.
No product on this page was tested for it. Vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a single portal session, not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Is Vault enough to secure a browser agent?
No. Vault bounds a credential it issues, and a browser agent at a portal works from a session the portal created, so the value that admits the agent never reaches the vault. What the model receives is the rendered page, and Vault's pages describe leases, scopes and wrapped responses rather than the screen. The control that changes the answer sits at the render, before the model reads the page.
What does the model receive when the agent opens a portal page?
Whatever the application draws. An account summary sends the member's name, the account number and the balance into the model's context as text, and a billing page sends the card on file. The session cookie is not in that text; the values the page displays are. Nothing in the pages reviewed replaces those values before the model reads them, so the first screen that carries a real value sets the exposure for the rest of the run.
Can a Vault policy stop an agent from reading a session cookie?
No. A Vault policy governs which client may read a path in the vault, and the cookie is held by the browser and presented to the portal. The policy has no view of the browser's cookie store, and the pages reviewed describe no mechanism that inspects it. Revoking a token does not end the portal session; signing out of the portal does, and that is a decision the person running the agent makes.
Who approves an action the agent takes inside the portal?
Usually no one, unless the workflow adds it. Vault's approval is written before the run: an administrator binds a policy to a token, and a read either matches it or fails. A person approving a payment at the moment it happens is a separate control, and one the policy cannot supply. Ask which person approves, where the approval is recorded, and whether the record sits beside the transaction or in a different system.
What record does Vault leave of a browser agent's work?
The lease and the token policy. HashiCorp's lease page documents a TTL and a revocation that ends validity, which answers when a credential stopped being valid (HashiCorp, Lease, 2026). It does not answer what the model was shown or who approved a change. A team that needs the second record has to produce it at the screen, beside the first. A lease answers one of the two questions, so a review needs the screen record too.
What should a team do before pointing an agent at a portal it can read?
Write down what the model will receive on the first screen that carries a real value, and name the person who approves the submission. Then check whether the tool replaces those values before the model reads them or sends the page as the application drew it. A credential store answers a different question, and a session that outlives the task keeps the exposure open until someone signs it out.
How RedactSure Keeps a Portal Session Out of the Model's View
A portal session is created by the application, so the credential a browser agent works with never passes through a vault. HashiCorp's tutorial cuts token lifetime "from days or weeks to minutes," a bound on an issued credential (HashiCorp, Secure, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent signs in, the browser holds the session cookie, and the summary page draws the account number and the claim amount. Inside, the page draws ACCT_001 and CLAIM_001, and the real account number resolves only at the destination the approver named, at the moment the approval is recorded.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
The difference on a portal page is whether the model ever holds the account number it reads. Bring one portal task and see, with test values, what the page shows the model and where the real value lands. Book a demo