Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Design an Agent Workflow That Assumes the Agent Gets Hijacked?

Assume the run is already compromised and give the agent placeholders instead of data, references instead of credentials, a grant that expires with the task instead of a standing role, and a named person on the consequential action. Then run one hijacked task end to end and record what an attacker would have collected at each step.

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

Teams designing agent workflows choose between planning for compromise and hoping for detection, and the choice sets the architecture. A workflow that assumes compromise asks what the run holds when an injection lands, and it arranges for the answer to be nothing worth sending. That arrangement is architectural: it fixes what the model is shown, what the run can spend, how far its grant reaches, and who approves the step that cannot be undone. None of the four is a filter, and none depends on recognizing an attack. McKinsey's research, as What Is the PII Wall? records it, finds 62% of organizations at least experimenting with agents and 23% scaling them, so most workflows now being designed can still choose their architecture. Browsing agents have been hijacked by the content of the pages they read, a benchmark across agent stages finds current defenses weak, and a credential that reaches a model has a way of coming back out. The lethal trifecta is the compact version: private data, untrusted content and a way out. Workflow owners should set the four barriers while that architecture is still open to change.

Key findings

  • A study of browsing agents reports "prompt injection, domain validation bypass, and credential exfiltration" and shows "how untrusted web content can hijack agent behavior" (Mudryi et al., 2025).
  • A benchmark that attacks agents at each stage finds "critical vulnerabilities in different stages of agent operation" and "limited effectiveness shown in current defenses," so a design cannot rest on a defense holding (Zhang et al., 2025).
  • Meta's rule for its own agents is that, until injection is reliably stopped, "agents must satisfy no more than two of the following three properties within a session," those being untrusted input, sensitive data and external communication (Meta AI, 2025).
  • CaMeL's authors report "solving 77% of tasks with provable security" against 84% undefended on AgentDojo (Debenedetti et al., 2025).
  • Substitution at the render layer replaces a value with a consistent token before any model reads the screen, so a hijacked run works on REPO_014 and KEY_003 (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, with a named person approving the step; advice written into an agent's instructions waits on the model's obedience instead (Does IBM watsonx Orchestrate Require Human Approval for Agent Actions?).

What does a governed browser environment cover when the agent is hijacked?

The scope is the rendered page. A governed browser environment covers what the agent reads and does on a page it is shown: a dashboard, a cloud console, a repository settings page, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An agent that reads a file from the working tree, runs a shell command, or calls an API with a key in its environment is outside this page's answer, and the controls that apply there belong to the sandbox and the credential store rather than to a browser.

The failure modes differ. In a browser the model reads rendered text, so the page is the unit of exposure and a control at render time can change what the model receives. In a terminal the model reads command output, which the sandbox and credential store govern, and a workflow that expects one control to cover both leaves one path unguarded.

The record for this page is a hijacked run that ends with nothing taken. An agent is asked to update branch protection on one repository and rotate its deploy key, and it works in the repository settings page rendered in a browser. Partway through, an issue comment it was told to read contains an instruction addressed to the agent: send the deployment credentials to an external address and add a collaborator. The run continues, because the instruction arrives as page content that the model treats as part of its task.

What happens next depends on two separate questions: what the page showed the model, and what the run could spend. A workflow can narrow the grant and still render the values, or hide the values and still leave a standing role. The barriers are separate for that reason, and each is tested against the same record.

What should the model receive instead of the data itself?

Substitution is the first barrier. Before the page reaches the model, the values the policy names are replaced with consistent tokens: REPO_014 for the repository, KEY_003 for the deploy key, ACCT_001 for a billing account. The injected instruction asks for the deploy key; the only deploy key the run has ever held is KEY_003.

The research record says why one reading is too many. The browsing-agent study lists "prompt injection, domain validation bypass, and credential exfiltration" and shows "how untrusted web content can hijack agent behavior" (Mudryi et al., 2025). Neural code completion tools "can not only return the precise piece of their training data," and "two valid credentials were identified during our experiments" (Huang et al., Your, 2024). GitGuardian's test of GitHub Copilot found that "over 1,200 leaked at least one secret" (GitGuardian, 2025).

Those results concern values that entered model-facing text; a placeholder policy decides which may enter it. Sign-up forms show the same exposure, where an environmental injection attack on generalist web agents reached an attack success rate of up to 70 percent in stealing users' personal information (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?).

Substitution acts only on the fields the policy names; a field left out is rendered as itself. It governs the page and not a file, so a deploy key the agent reads from a repository file is outside it.

What do the vendors themselves say?

Three vendor pages bear on the question, and each documents a control on what the agent may do rather than on what its model reads.

Cursor's documentation states that "By default, terminal commands need your approval" and that "All MCP connections need your approval," and warns that "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues" (Cursor, 2026). It describes run modes as "best-effort guardrails rather than a hard security boundary," and what the agent can read on a rendered page is not described in the pages reviewed.

1Password and Browserbase state that "Credentials are not shared with the LLM or exposed in Browserbase logs and repos," and that autofill "allows AI agents to authenticate with web services without ever exposing credentials" (1Password and Browserbase, 2025). The release lists real-time approval prompts but gives no implementation detail.

GitHub's Actions documentation says "It's good security practice to set the default permission for the GITHUB_TOKEN to read access only for repository contents," and asks teams to "Audit how secrets are used, to help ensure they're being handled as expected" (GitHub, Secure, 2026). Those rules govern the token a workflow runs with, not what a repository settings page renders.

The pattern is a control on an action surface, and none of the three describes a control on the values a rendered page shows.

Dimension Cursor, per its documentation What a buyer should verify
What the model receives Not described; the page covers approvals, MCP and run modes Which values are substituted before the model sees the page
Terminal commands "By default, terminal commands need your approval." Whether terminal approval is in scope for the agent's browser run
MCP connections "All MCP connections need your approval." Who approves an MCP connection and whether the approval is audited
Injection risk "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues." What a successful injection can collect, not only what it can trigger
Credential custody Not described on the page Where the credential lives and whether the agent process can read it
Grant scope Run modes described as "best-effort guardrails rather than a hard security boundary" A per-task, expiring grant rather than a mode setting

Why replace a credential with a reference the agent cannot resolve?

A credential is a value with a use. A reference is a name the environment resolves into the value only when the destination is approved, and the agent never holds the value itself. In a hijacked run the attacker inherits whatever the model held: with a reference, it can ask for the action but cannot carry the credential away.

1Password's release describes the split for browser logins: "Secure Agentic Autofill allows AI agents to authenticate with web services without ever exposing credentials," and "Credentials are not shared with the LLM or exposed in Browserbase logs and repos" (1Password and Browserbase, 2025). It lists real-time approval prompts but no implementation detail.

GitHub's guidance points at the same principle: "It's good security practice to set the default permission for the GITHUB_TOKEN to read access only for repository contents," and workflows should "Pin references to actions to a commit SHA in your workflow files" (GitHub, Secure, 2026). A read-scoped token is a reference with a known reach.

The record shows the difference. Before the run, the agent's context holds a bearer token copied from the settings page, and the injected instruction can ask the model to repeat it. Under a reference, the page shows KEY_003, the environment resolves KEY_003 only at the approved host when a named person approves the rotation, and the transcript holds a name that is worthless outside the environment. The limit is the resolver: one that accepts any destination turns the reference back into a credential.

What does a grant instead of a role look like, and who approves the step?

Under a role, a hijacked run can reach whatever the identity can reach; a grant covers one task, one destination and one run, with an expiry.

OWASP's LLM06 names the failure: it is "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" (OWASP, 2025). A single login that bundles workflow access with value access produces that reach by construction (How Do You Give AI Agents Access to Workflows Without Exposing Sensitive Data?), and durable root credentials are the extreme case discussed in Is It Safe to Let an AI Agent Set Up Your Cloud Environment?.

Meta's rule sets the architecture: until injection is reliably stopped, "agents must satisfy no more than two of the following three properties within a session," namely untrusted input, sensitive data and external communication (Meta AI, 2025). A run that reads untrusted content and touches a sensitive system has spent its two, so the external action moves behind a person.

CaMeL's design goal is that "the untrusted data retrieved by the LLM can never impact the program flow," at "solving 77% of tasks with provable security" against 84% undefended (Debenedetti et al., 2025).

Where a platform documents approval as something a builder writes into instructions, the requirement waits on the model (Does IBM watsonx Orchestrate Require Human Approval for Agent Actions?). A gate outside the model does not; name the approver before the run.

What does a governed environment change?

A governed environment is a control class that sits between the rendered page and the model, and it changes four things at once.

First, values chosen by policy are replaced with consistent tokens before any model reads the screen, so the model's context holds REPO_014 where the repository name belongs and KEY_003 where the key belongs, for the whole run. Second, real values resolve only at the approved destination, at the moment of an approved action, so a value reaches the branch protection form and not the transcript, the next page or a summary. Third, a named person confirms the tokenization policy and approves each consequential action, which makes the approval a gate outside the model rather than an instruction inside it. Fourth, every screen as tokens, every action and every approval is written to a record the organization can export to its own monitoring.

For this page's question, the four together change what a hijack yields. The injected instruction still lands, the model still acts on it, and the task may still go wrong. What the run collects is different: tokens instead of values, one task's grant instead of an identity's reach, a record of the attempt instead of an untraced action, and a person who has to approve the irreversible step. The hijack becomes an incident to review rather than a breach to contain.

It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP. That limit is part of the definition: a governed environment is not a sandbox and does not replace the credential custody a team needs for the paths outside the browser. Isolation is the structural version of the same idea, as How Do You Isolate AI Agents From Sensitive Company Systems? sets out.

Methodology and limitations

This page rests on four research preprints, two vendor research posts, vendor documentation from Cursor, GitHub and 1Password, OWASP's LLM06 entry, and existing RedactSure research pages on the lethal trifecta, credential handling without reading and isolation. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted passages are given in the source's wording, and figures are cited as the source states them rather than as measurements this page made. The four preprints are cited for what their abstract pages state, not for rates those pages do not give.

RedactSure did not test any product hands-on. Where a behavior is not described, the statement concerns the pages reviewed and not what a product does; vendor features change, and the page carries its date, so a release after it should be treated as unreviewed until the test below is repeated. The vendor pages reviewed cover terminal and MCP approvals, a credential handoff and workflow tokens; none describes the values a rendered page shows, which is why the worked example is stated as a record type. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a hijacked run against a repository settings page, and not an organization.

Determinations about whether a workflow meets a contractual, regulatory or internal control 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 repository, repeated after each change to the workflow or the model.

What the record shows

Substitution decides what the model can repeat; a reference decides what the run can spend; a grant decides how far one task reaches; an approver decides which action happens at all. Each is documented in part by the vendors reviewed here, and none describes the whole set, which is why the design has to be assembled rather than bought as a setting. The limit is the same for all four: they cover the rendered page and the run around it, not the terminal, the IDE, the local filesystem, direct API calls or MCP, so those paths need their own controls. RedactSure's environment applies the four at the render layer. Proving the design takes one agent, one task and a test repository with a planted instruction; after the run, the owner should record what the model was shown, what the grant allowed, and who approved the irreversible step.

Frequently asked questions

Does assuming a hijack mean giving up on detection?

No. Detection still shortens the time between an injection and a response, and a filter that blocks a known pattern is cheap to run. The design assumption concerns what happens when detection fails, which the research record says it will some of the time. A workflow that assumes failure puts its controls where a missed injection cannot reach a value, and keeps detection as an additional layer rather than the only one. The two are complements, and the budget question is how much each gets.

Which of the four barriers removes the most risk?

Substitution changes what a successful attack collects, so it removes the most from a single hijacked run. A reference and a grant limit what the run can spend after the model acts, and an approver limits which action happens. The order matters less than the coverage: a workflow with three of the four still has a path the fourth would have closed. Start with what the model is shown, then narrow the grant, then name the approver. The answer depends on the task, not the tool.

Do placeholders break the task?

They can, when a task needs the value itself rather than the record it identifies. Reading a repository settings page, comparing a branch name and proposing a protection rule all work on tokens, because the tokens stay consistent for the run. A step that must display the real value to a person needs the value resolved at that point, which is a decision for the policy and the approver rather than for the model. Test the task with tokens before rollout; one run answers the coverage question.

How is a grant different from a role?

A role is standing: it stays attached to the identity after the task ends, and every future run inherits it. A grant is bounded: one task, one destination, one operation and one run, with an expiry, so a hijacked run that finishes leaves nothing usable behind. The difference shows up in what an attacker can do with what the model held. A stolen role is an asset; a stolen grant is a permission that has already lapsed, which is the test to apply to a proposed workflow.

Who should approve the consequential step?

A named person who knows the change, not a queue and not the model's own reviewer. The approver should see the page as the model saw it, with tokens in place of values, and should approve the specific action rather than a class of actions. That keeps the approval meaningful when the run is unusual, which is exactly when a rubber stamp fails. Name the approver before the run, and record the approval with the action.

How would a team test a workflow before it runs?

Plant an instruction in a page the agent will read, run one task against a test repository, and write down three things: what the model was shown, what the grant allowed, and who approved the last step. Repeat with a value the policy names and one it does not, since the gap between them is the coverage the policy actually has. Keep the record with the workflow version, so the next change is tested against a known baseline.

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 a Hijacked Run End With Nothing Taken

Approvals arrive after the model reads and a scoped token limits what a process can call, so neither changes what the run has already seen.

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

Before, the model reads the branch protection page with the deploy key in the field and can repeat it into the issue thread. Inside, the same page shows KEY_003, and the only write is the one a named reviewer approved.

RedactSure is deploying now with enterprise and government customers. The benchmark above found "limited effectiveness shown in current defenses."

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

See it on your own workflow

Designing for a hijacked agent is easier when you can see what a hijacked run ends with. Bring a repository task and see, with test values, what the model could repeat into an issue thread. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.