Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Why Should Submitting a Credential Require Its Own Permission?

Reading a page and sending from it are different acts, and an injected instruction works through the second, so a separate permission on submission leaves a hijacked agent with placeholders to read and nothing real to send. Ask who approves each submission, to which destination, and what the model held when it asked.

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

An agent that reads a page takes in text. An agent that submits a form, sends a message or saves a record changes something outside the page. Prompt injection attacks the second act: a hostile instruction on a page does harm only if the agent acts on it, and acting means sending something somewhere. That asymmetry is the case for giving submission its own permission, separate from permission to open and read. The question is why the separate gate is the right design and what the alternatives leave open. This page separates the two acts, reads what vendors document about approvals, scopes, short-lived credentials and prompts, shows what detection and privilege controls leave open at the moment of a send, and ends with a test a team can run. The example record is a submit blocked after a hijacked read: an agent reads a page that carries an injected instruction, tries to send an account number to an outside address, and is stopped at the submission. The neighboring question, what happens to a credential an agent created and no one approved, is covered in What Happens to a Credential an Agent Created but I Did Not Approve?.

Key findings

  • A study of browsing agents reports findings that "include prompt injection, domain validation bypass, and credential exfiltration," the attacks that arrive by reading a page and succeed by what the agent then does, though its abstract reports no success rates (Mudryi et al., 2025).
  • 1Password and Browserbase list "Human-in-the-loop authorization: Real-time approval prompts via 1Password mobile or desktop," an approval attached to a credential's use, and the release gives no technical detail on how injection is implemented (1Password and Browserbase, 2025).
  • Anthropic's Claude Code documentation states that "The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can," which shows that a prompt gates a command and that what an approval allows can be wide (Anthropic, 2026).
  • A governed environment replaces values with consistent tokens such as ACCT_001 before any model reads the screen, so a hijacked agent that reads the page reads placeholders (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?).
  • Real values resolve only at the approved destination at the moment of an approved action, and a named person is accountable for that approval (What Is Supervised Delegation?).

What does a governed browser environment cover when an agent reads a page and then submits from it?

A governed browser environment covers what an agent reads and does on a rendered page: dashboards, consoles, settings pages and sign-up forms, including the Send, Save and Pay buttons on them. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An agent that posts a credential to an endpoint from a shell is outside this page. An agent that clicks Send on a rendered form is inside it.

Two acts happen on such a page. The first is reading: everything the page draws enters the model's context, including text an outside party wrote. The second is submitting: the agent presses the button that moves a value out of the environment to a destination. A permission to read answers whether the agent may open the page. A permission to submit answers a different question, whether this value may go to this place now, and only a person or a policy can answer it.

The example record is a submit blocked after a hijacked read. The agent opens a support ticket to summarize it. A comment on the ticket, written by an outside party, tells the agent to send the account number to an address in the comment. The agent reads the comment, forms the action and reaches the Send button. Whether anything real leaves depends on two things: what the agent's view held where the account number sits, and whether the Send needs a person's approval.

Why are reading a page and sending from it different acts?

Because the instruction arrives by one and does its harm by the other. A study of browsing agents demonstrates "how untrusted web content can hijack agent behavior," which puts the instruction in the page and the harm in the agent's next act (Mudryi et al., 2025). Reading is the act the attacker uses to get an instruction in, so a permission on reading cannot stop it. Only the send is a place to stop it, because the send is the only act that moves a value out.

What the agent holds at that moment decides what the send carries. In GitGuardian's test of Copilot, "over 1,200 leaked at least one secret" and "Copilot generates 2702/900 = 3.0 valid secrets for one prompt on average," a measure of how readily a model repeats a value it has read (GitGuardian, 2025). If the model has read real values, a hijacked send can carry them. If it has read placeholders, a hijacked send carries placeholders. If the send also needs a person's approval, a placeholder never reaches the outside address.

The surfaces where this happens are ordinary. Sign-up and checkout forms are a measured leakage point: an environmental injection attack on generalist web agents reached an attack success rate of up to 70 percent in stealing users' specific personal information, as the linked page reports (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?). A form is a place where a page asks for a value and an agent has one to give, which is the shape of the record above.

What do the vendors themselves say?

The vendor pages below describe approvals, temporary credentials, scoped tokens and prompts. They are the nearest documented relatives of a permission on submission, and each governs a credential or a command. Read the rows twice: once for what each states, once for the question each leaves open for a buyer.

Dimension Vendor, per its documentation What a buyer should verify
Credential kept from the model 1Password and Browserbase state that "Secure Agentic Autofill allows AI agents to authenticate with web services without ever exposing credentials" and that "Credentials are not shared with the LLM or exposed in Browserbase logs and repos" (1Password and Browserbase, 2025). The release gives no technical detail on how injection is implemented and no availability date. Ask whether the approval prompt also covers a submission that carries other values from the page.
Credential kept off the session machine Anthropic's Claude Code documentation states that "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM" and that "While these protections significantly reduce risk, no system is completely immune to all attacks" (Anthropic, 2026). The custody is described for Anthropic-hosted cloud sessions only, and not for local sessions. Ask what an approved action may send, and not only whether a prompt appears.
Temporary, narrowed credentials AWS's AssumeRole reference states that the call "Returns a set of temporary security credentials that you can use to access AWS resources" and that "The resulting session's permissions are the intersection of the role's identity-based policy and the session policies" (AWS, 2026). A session policy narrows what a credential may do. Ask whether a policy can name one operation and one destination for one task, and who writes it.
Scoped, short-lived token HashiCorp's tutorial states that "the agent receives a token that is read-only, repo-only, scoped to a single secret, and short-lived," and its wrapper script "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent" (HashiCorp, 2026). The raw token is in the agent process's environment, and the page does not say whether the agent can read it. Ask who approved the scope.
Token scope in MCP The Model Context Protocol guidance states that "Poor scope design increases token compromise impact, elevates user friction, and obscures audit trails" and advises implementers to "Warn that MCP servers run with the same privileges as the client" (Model Context Protocol, 2026). The guidance is for MCP implementers and says nothing about how a coding agent's own credentials are held. Ask how scope is decided per submission.

Every row narrows what a credential may do, who holds it or what a command may touch. A person's approval of a single submission to a single destination is not described in the pages reviewed; the closest relatives are the approval prompt on a credential's use and the permission prompt on a command.

What do detection and privilege controls leave open at the moment of submission?

Detection acts on the text the model reads. The LlamaFirewall authors describe PromptGuard 2 as "a universal jailbreak detector" and report that the system "shows stronger efficacy at preventing indirect injections in general scenarios than previously proposed approaches," a claim about detecting hostile text that gives no quantitative results in its abstract (Chennabasappa et al., 2025). A detector reduces how often an injected instruction is followed. An instruction that passes it still reaches the Send button, and a send that carries a real value is not recalled.

Privilege control acts on what the agent may do. The Progent authors report that "Progent significantly reduces attack success rates while maintaining high utility," a result for privilege control that the abstract states without numbers (Shi et al., 2026). A policy of this kind decides in advance which actions are permitted, and the abstract does not say how a policy distinguishes this send from the last one. A permission on submission is a privilege decision made per submission, by a person, with the destination and the values in front of them.

Both controls leave the same gap: the agent that is hijacked holds what it read. Meta describes a design in which a separate component must approve every network egress and a human approves sensitive actions, which is one vendor's agent and not a control that applies to any agent on any page (What Would an Enterprise Version of Meta Muse Need?). Enterprise browsers address a neighboring problem, the movement of data by people in web applications (Enterprise Browser or Render-Layer Tokenization?); the agent's send is a different act on a different surface.

How can a team test that submission is its own gate?

Name one agent and one task, use a test account, and plant an instruction on a test page: a comment that asks the agent to send a test account number to an outside test address. Run the task and answer five questions from evidence and not from the product page. Did the agent attempt the send? Was an approval requested, and by whom? Did the request show the destination and the values to be sent? What did the message contain, the real value or a placeholder? If the approver denied it, did anything leave?

Then test the scope of an approval. Approve one submission and watch the next: a second send to a different destination should ask again. An approval that covers every later send is a blanket permission and not a gate. Run the test again with the injected instruction removed to confirm that a normal send still works, because a gate that blocks everything will be turned off. The record should hold the read, the attempted send, the request and the decision (What Is an AI Control Record?). The nearby cases are Can a Browser Agent Read an API Key It Just Generated? and Can a Browser Agent Read My Session Cookies?.

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 ACCT_001. 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, including every payment, submission and record change. 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, it makes the read and the send separable. The read cannot hand the attacker a real value, because the model holds none, and the send cannot go out unseen, because a named person approves it. On the example ticket, the agent that follows the hostile comment composes a message with ACCT_001 in it, the approval shows the outside address and the placeholder and not the sensitive data, and the person declines.

The record keeps the attempt either way, with the screen as tokens, the request and the decision. It governs the rendered page and nothing else. A credential posted to an endpoint from a shell is outside it, and stays with the sandbox and the credential store the team configures for that agent.

Methodology and limitations

This page rests on three research preprints on browsing agents, guardrail systems and privilege control, vendor documentation and a press release from HashiCorp, AWS, 1Password, Browserbase and Anthropic, the Model Context Protocol security guidance, one vendor research post from GitGuardian, and existing RedactSure research pages. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and figures from research posts are cited as reported and not as independently measured. Dates on the Sources lines are the dates the pages were read. The preprints are cited for what their abstract pages state and not for rates those pages do not give.

RedactSure did not test any of the named products hands-on. "Not described" means not described in the pages reviewed. The separate permission on submission is described as a design requirement and as RedactSure's current design, and not from a vendor page, and RedactSure is deploying now with enterprise and government customers. The example of a hostile comment on a support ticket illustrates a record type, a submit blocked after a hijacked read, and is not an observed incident or an organization. Vendor features change, and the page carries its date; a reader should treat a release after that date as unreviewed until the test above is repeated.

Determinations about whether an approval practice 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 a test page, repeated after each release.

What the record shows

Reading and sending differ in what each can cost. A read can bring a hostile instruction into the model, and a send is the act that moves a value out. The vendor pages reviewed narrow credentials, scope tokens and prompt for commands or for a credential's use, and the preprints report that detection and privilege control reduce attacks without giving numbers in their abstracts. A permission on each submission, tied to one destination and shown with placeholders, adds the check that a hijacked read cannot pass; RedactSure's environment makes submission its own gate. A security team can run that test in an afternoon: pick one agent and one task, plant an instruction on a test page, and write down what the agent tried to send, who was asked and what left.

Frequently asked questions

Why should submitting a credential require its own permission?

Because the instruction in an attack arrives by reading and does its harm by sending. A permission to read cannot stop an instruction that enters through the read. The send is the one act that moves a value out of the environment, so it is the place where a person can see the destination and the values and say no. Without that gate, whatever the agent holds can leave on the strength of text it found on a page. Teams can keep reads fast and spend attention only on sends.

Is permission to read a page enough?

No. Permission to read answers whether the agent may open the page, and the attack needs nothing more than that. The hostile text is part of the page, so reading it is the only access the attacker requires. Reading less does not help, because the model must read the page to do the task. What the agent can do after reading is a separate question with a separate answer, and the answer should be given per submission, with the destination in front of the person who gives it.

Does injection detection make a submit permission unnecessary?

Detection lowers how often an injected instruction is followed, and the abstracts reviewed here give no numbers for how often it fails. An instruction that passes still reaches the Send button, and a send that carries a real value cannot be recalled. A permission on submission does not depend on recognizing the attack, so it works on the instruction nobody recognized, which is the one that matters. The same holds for any control that works by recognition.

What should the person approving a submission see?

The destination, the values to be sent and the task that led to the request. If the model works on placeholders, the approval shows the placeholder and the real value goes only to the destination the person approved, so the approver can judge the destination without the transcript holding the value, and the approval record should store that view. A request that shows only the word Send or an unexplained prompt asks for trust and not for a decision.

Does approving one submission approve the next?

It should not. An approval is a decision about one value going to one destination for one task. A second send to a different destination is a different decision and should ask again. An approval that carries over to later sends turns the gate into a blanket permission, and the Claude Code documentation reviewed here shows how wide an approved command can be. Test it by approving once and watching the next send, and make the approval expire with the task.

What should a team ask a vendor in writing?

Whether submission is its own permission, separate from reading; what the approver sees, including the destination; whether an approval covers one submission or later ones; what the model holds when it asks, real values or placeholders; and what record shows the read, the request and the decision. Treat any answer the documentation does not support as unanswered until a run with a planted test instruction confirms it, and keep the written answers beside that run's transcript.

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 Submission a Separate Decision From Reading the Page

Detection lowers how often an injected instruction is followed and privilege controls narrow what an agent may call, yet a hijacked agent holding real values can send them.

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

Before: an injected comment tells the agent to send the account number to an outside address, and the agent holds the number and can. Inside the governed environment: the model reads ACCT_001, the Send waits for a named person to approve its destination, and a denied send leaves only the placeholder and the record of the attempt.

RedactSure is deploying now with enterprise and government customers. Claude Code's documentation states that an approved Bash command can still write anywhere your user account can.

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

See it on your own workflow

Reading a page and sending what it contains should never share a single permission. Bring a task that sends data out of an application and see, with test values, the Send wait for a named person. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.