Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does Prompt Injection Matter If the Agent Has No Credentials?

Less, and still some. An agent that holds no credentials can still push, delete or post under whatever grant it carries, so the question becomes who approves those actions; check what the model is shown and who answers for each consequential one.

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

An agent without credentials still holds authority, even after a team strips the keys out. Remove the API keys, the session cookie and the stored password from a developer workflow and the model still reads pages, still decides what comes next, and still holds whatever permission the person who connected it granted: push to a branch, delete a record, post a comment, change a setting. The exposure shrinks while the action surface stays the same. A credential is the first control and an approval is the second, and removing the first does not install the second. That split is the whole of the answer. Teams should first ask what remains at risk once no credential is in reach, which the browsing-agent research measures from the attacker's side: "untrusted web content can hijack agent behavior," and its findings include "prompt injection, domain validation bypass, and credential exfiltration" (Mudryi et al., 2025). From there the page reads what the vendors who ship approvals document about the control that is left, then the grant that makes an action possible, then the approval itself, and closes with the control class that covers the whole run. The record type throughout is an agent with placeholders and push rights, working a repository settings page.

Key findings

  • A study of injection against agentic coding editors reports that attack success rates can reach as high as 84% for executing malicious commands, so the payoff of a successful injection is an action and not only a disclosure (Liu et al., Your, 2026).
  • The risk does not leave with the credentials: OWASP names excessive agency as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" (OWASP, 2025).
  • Vendors put the approval in front of the action rather than in front of the text: Cursor's documentation states that "By default, terminal commands need your approval" and that "All MCP connections need your approval" (Cursor, 2026).
  • A governed environment replaces the values on a rendered page with consistent tokens before any model reads the screen, so a hijacked run holds placeholders such as REPO_TOKEN_014 and never the record behind them (What Is an AI Control Record?).
  • Real values resolve only at the approved destination at the moment of an approved action, and a named person approves each consequential one, which is the control that remains when there is no credential left to steal (What Is Supervised Delegation?).

What does a browser control cover when the agent holds no credentials?

The scope decides which half of this page's question a browser control can answer. A governed browser environment covers what the agent reads and does on a rendered page: a repository settings page, an issue thread, a cloud console, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. With no credentials in play, that boundary matters more rather than less, because what is left is an action, and actions split cleanly across it. Merging a pull request, changing a webhook URL, closing an issue, posting a comment or saving a permission change happen on a page. A push issued from a shell, a script that calls an API, or an MCP tool that writes to a repository happen outside one.

That split is the shape of the record type this page uses. A coding agent is connected to one repository with push rights and works in a browser on that repository's settings pages and issue threads; it holds placeholders where a value would sit, because the environment it runs in does not hand it the real ones. An injected instruction arrives in an issue comment and tells it to change the deployment key, then merge. The settings page is also where the grant is written down: the documentation reviewed for this page describes tokens that can be limited to specific repositories and tells users to treat access tokens like passwords (What Can an AI Agent See in Your GitHub Settings?). If the agent holds a placeholder rather than the token, that page shows it REPO_TOKEN_014, and the question stops being what it could read and becomes what it can still do.

Why does injection still matter when there is nothing to steal?

The honest answer is that it matters less, and that the remainder is not small. Removing credentials removes the second half of the classic attack: there is no credential to exfiltrate, no key to paste into a prompt, no session to replay. What remains is the first half, and the excessive agency entry describes it without reference to credentials at all, as a vulnerability of actions rather than of data. OWASP lists excessive functionality, excessive permissions and excessive autonomy as the root causes, which maps onto a no-credentials agent: it can do more than the task needs, it holds more permission than the task needs, or it acts without a person in the loop (OWASP, 2025).

A second residue survives as well, because an agent with no credentials still reads records. Injections that ask an agent to leak personal data it observed during a task reached average attack success rates around 20 percent in a University of Zurich study, a disclosure that requires no stored credential at all (Does Prompt Injection Expose Customer Records?).

There is also a reason the credentials were removed, and it is measured. GitGuardian's test of Copilot found that it generates "2702/900 = 3.0 valid secrets for one prompt on average" and that over 1,200 repositories leaked at least one credential (GitGuardian, 2025). The test does not confirm whether the extracted credentials were still active. The point is structural: an agent that reads untrusted content and holds a credential will eventually be asked to use it, and the same holds for one that holds a permission.

What do the vendors themselves say?

Four vendor pages describe how an agent's actions are gated. Cursor describes its run modes as "best-effort guardrails rather than a hard security boundary" and warns that "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues" (Cursor, 2026). 1Password and Browserbase state that "Secure Agentic Autofill allows AI agents to authenticate with web services without ever exposing credentials," and add "Human-in-the-loop authorization: Real-time approval prompts via 1Password mobile or desktop" (1Password and Browserbase, 2025). What the agent reads on the page after it authenticates is not described in the pages reviewed.

OpenAI's Codex documentation states that "Locally, Codex uses an OS-enforced sandbox that limits what it can touch (typically to the current workspace)" and that "By default, the agent runs with network access turned off," with approval required to edit files outside the workspace or to run commands that need network access (OpenAI, 2026). The page does not describe how credentials are stored inside that session.

Meta's newsroom states that "Muse runs on its own dedicated computer in the cloud" and that it "checks with the person before sensitive actions like sending an email or making a purchase" (Meta, 2026). The same release says Muse "can't see stored passwords or payment methods but can use credentials stored for it," which leaves approval as the control that decides what the stored login is used for (Meta, 2026).

Dimension What the documentation states What a buyer should verify
Cursor Approval by default for terminal commands and every MCP connection; run modes called "best-effort guardrails rather than a hard security boundary" Whether the approval shows the page or command that shaped the action, and what the model read before proposing it
1Password and Browserbase Agents authenticate without credentials being exposed; real-time approval prompts on mobile or desktop What the agent sees on the page after it authenticates, which the release does not describe
OpenAI Codex OS-enforced sandbox, network off by default, approval for edits outside the workspace and commands that need the network How credentials are held in the local session; the page does not say
Meta Dedicated cloud computer; approval before sensitive actions; cannot see stored passwords or payment methods but can use credentials stored for it Whether the approval shows the destination and the value, and what its audit trail records

What can an agent do with a grant it should not have?

The grant is the whole of the remaining risk. Willison's patterns accept a narrower agent instead of a better filter: "These design patterns constrain the actions of agents to explicitly prevent them from solving arbitrary tasks," and one of them says agents "can trigger tools, but cannot be exposed to or act on the responses from those tools" (Willison, 2025).

The benchmark record measures the defense side rather than declaring it won: one study reports that the authors "conduct a systematic evaluation on 5 prompt injection attacks and 10 defenses with 10 LLMs and 7 tasks" (Liu et al., Formalizing, 2024). A defense measured across ten models and seven tasks is a defense with a failure rate, and a failure rate applied to an agent holding push rights produces actions. Documented guidance against creating root access keys rules out the simplest way an agent gets durable top-level power, and says nothing about what a scoped grant still permits (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?).

A grant can be too broad in three directions, and the remedy differs for each. Function: the agent can delete, publish, invite and pay when the task needs one of those. Reach: the grant covers every repository or record rather than the one in the task. Duration: the grant outlives the run, so a session shaped by an injection is still usable tomorrow. The review questions that follow are the ones in What Should an AI Agent Security Review Cover?, beginning with what the AI saw and where it could go.

Does human approval close the gap?

Approval is the second control, and it is not a formality. It is also not a solution on its own, for a reason that has nothing to do with credentials: the person approving sees what the agent presents. Attackers can manipulate the content and presentation of approval dialogs to deceive users into authorizing malicious operations, an attack cataloged as HITL dialog forging, or Lies-in-the-Loop (Does Human Approval Stop Actions Triggered by Prompt Injection?). If the model's summary of the action is the only thing the approver reads, then the injection writes the approval prompt.

Cursor's default puts a person in front of terminal commands and MCP connections, which is the right shape of control and still only a gate on the action the model proposed (Cursor, 2026). The gap sits in what the approver is shown: the command, not the issue comment that argued for it, and not the values the page displayed when the decision was made. The useful questions are whether the approval names a person rather than a role, whether it shows the destination and the value, whether it covers one action or a batch, and whether the decision is written to a record the organization can read later.

A worked contrast makes the difference plain. An approval that reads "allow agent to change the deployment key" tells the approver what the agent said it would do. An approval that shows the same request arriving from a newly edited issue comment, with REPO_TOKEN_014 in the field the agent read and the destination repository named, tells the approver what actually happened. The first is a notification. The second is a decision.

What does a governed environment change?

A governed environment changes three things at once. The first is what the model receives: values chosen by policy are replaced with consistent tokens at the render layer before any model reads the screen, so the model works on tokens rather than the values behind them. The second is where real values are allowed to exist: they resolve only at the approved destination at the moment of an approved action, so a page that would display a key displays a token. The third is who answers for the action: a named person confirms the tokenization policy and approves each consequential action, and every screen, action and approval is written to a record that exports to the organization's own monitoring.

For an agent with no credentials, the first change moves less than it would on a page full of credentials, and the third carries the answer. Tokens still matter, because an agent with no stored credential still reads values that belong to someone: a customer record, a deployment target, an account number on a settings page. But the control that decides this page's question is approval with a record behind it. An action proposed by a hijacked model is an action a named person approves or refuses, with the destination, the value and the source of the instruction in front of them, and the decision written down with their name. That turns a non-zero injection rate into a rate of refused actions rather than a rate of incidents.

The environment is a control class, not a product feature, and its parts are what make it quotable: tokens before any model reads a screen, real values only at the destination a person approved, an approver with a name for every consequential action, an exported record.

Methodology and limitations

This page rests on three research preprints on prompt injection and its measurement, one practitioner pattern set, vendor pages from Cursor, 1Password and Browserbase, OpenAI and Meta, one standard entry from OWASP, one vendor research post from GitGuardian, and existing RedactSure research pages on the control class. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and the research preprints are cited for what their abstract pages say and not for figures those pages do not give.

RedactSure did not test any named product hands-on. Where the recorded facts for a page do not cover how a value is stored or what the model is shown, this page says so, and the phrase "not described in the pages reviewed" means exactly that and not that a vendor does nothing. The test for such a statement is the absence of the fact from the recorded page, not an inference about the product behind it. Vendor features change and the page carries its date, so a release after that date is unreviewed until the test below is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, an agent with placeholders and push rights working a repository settings page, and not an organization.

Determinations about whether an agent's grant, approval flow or record meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers, not to this page. Nothing here replaces a test of the organization's own agent against a test repository, repeated after each release.

What the record shows

The record supports a narrower claim than either side of the argument. An agent with no credentials cannot be made to hand over a credential it does not hold, and that removes a real and measured failure mode, since models repeat credentials they have read and public repositories leak them at scale. What the same agent can still be made to do is act: change a setting, merge a change, post a message, delete a record, all under the grant its owner approved. The control that answers for those actions is approval by a named person, with a record of what the model saw and who approved what, and RedactSure's environment is built on that control class. With one agent and one repository, a team can test its own exposure directly: plant an instruction in an issue comment, then record what the model read, what it proposed, who approved it, and what the approval screen showed.

Frequently asked questions

Does prompt injection still matter if the agent has no credentials?

Yes, less than it would with a credential in reach, and the remainder is an action. An agent that holds no credential still holds permission: it can push, merge, delete, publish or submit under the grant it was given. A hijacked run then becomes a question of what that grant permits and who approves it. A read-only agent is the narrower case. The exposure that disappeared is the one a credential would have carried off the machine.

What can an injection do to an agent with no credentials?

It can redirect work. The injected text changes what the agent decides to do next: which page it opens, which setting it changes, which pull request it merges, which account it contacts. None of that needs a credential, because the authority is already attached to the session. The instruction does not need to name a credential to be worth following. The damage is bounded by the grant, which is why the grant's breadth and the approval on each action are the two facts worth establishing before the agent runs unattended.

Is a sandbox enough if there are no credentials inside it?

A sandbox limits what the process can reach, and that is a real control. It does not decide whether a permitted action should happen: a command inside the sandbox can still delete the workspace, and a page inside the browser can still change a setting. The two controls answer different questions, what the agent can touch and who agreed to this particular action. Neither control substitutes for the other in a review. A team needs an answer to both before it removes the person from the loop.

Does human approval stop a hijacked action?

Sometimes, and not reliably on its own. An approver who sees only the agent's summary is deciding on the agent's account of the action, and the content and presentation of approval dialogs can be manipulated to deceive the person authorizing them. The screen, not the summary, is the evidence. Approval works when it names a person, shows the destination and the value, covers one action rather than a batch, and lands in a record. Anything less is a notification with a button.

What should an approval screen show?

The action, the destination and the value, plus where the instruction came from. An agent proposing a settings change should present the token it read, the repository or account it will change, and the page that shaped the decision, so the approver is judging the request rather than the request's description. Approvals that show the model's prose summary alone inherit whatever the injection wrote into that summary. Ask to see the screen, not the log line.

How does a governed environment handle an agent with no credentials?

It treats the action as the exposure. Values on the rendered page become tokens before the model reads them, real values resolve only at the destination a person approved, and each consequential action waits for a named approver whose decision is recorded. RedactSure's environment is built that way, and its record shows what the model saw beside who approved what. The record lets the team compare the two. The scope is the rendered page, so a push issued from a shell stays the team's own problem.

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 Keeps a Hijacked Agent From Acting on Its Grant

An agent without credentials still has authority, and a sandbox or scoped grant limits what it can touch while the page the model read stays ungoverned.

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

Before: the agent reads the issue comment, opens the repository settings page and sees the key and the deployment target as the page renders them, then proposes the change and the merge. Inside the governed environment: REPO_TOKEN_014 sits where the key sat and a named person approves the settings save.

RedactSure is deploying now with enterprise and government customers. A coding-editor study found injected instructions executing malicious commands up to 84% of the time.

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

See it on your own workflow

An agent with no credentials can still act on its grant when it is hijacked. Bring a repository task and see, with test values, which change a named person must approve before the save goes through. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.