Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does a Prompt Injection Detector Protect My Credentials?

Partly: a detector stops the injections its classifier recognizes, and the ones it misses reach an agent holding whatever its context already contains. Run one known injection against your own agent and write down whether the model was holding real values or placeholders when the text arrived.

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

A detector is a classifier on the text path. It reads what is about to enter the model, scores it, and returns a label the harness can act on, which makes it a real control and also the only control on this page whose whole job is to be right about text it has never seen. So the useful question for a team that relies on one is what the detector leaves behind when it is wrong, and that depends on what the model is holding at the moment the text arrives. An agent holding a live deploy token when a novel injection lands hands over a live deploy token. An agent holding CI_TOKEN_001 hands over a string that resolves only where a named person approved it.

The sections that follow keep that comparison in order. The first sets out what a detector inspects and what a browser-level control covers. The second reads the coverage that published research claims for detection and for privilege control. The third reads what Cursor, 1Password with Browserbase, Composio and GitLab document, and what each leaves open. The fourth works one missed injection through both designs on a repository's CI/CD variables page. The fifth collects the layers a team can add around a filter, and the last states the control class in plain terms.

Key findings

  • A study of browsing agents lists "prompt injection, domain validation bypass, and credential exfiltration" among its findings, three failures one hijacked run can produce together (Mudryi et al., 2025).
  • Progent is a privilege-control design rather than a classifier, and it "significantly reduces attack success rates while maintaining high utility", which leaves a rate above zero (Shi et al., 2026).
  • GitLab's documentation replaces a masked variable with [MASKED] in a job log and warns that masking "is not a guaranteed way to prevent malicious users from accessing variable values" (GitLab, 2026).
  • An adaptive attack study reported an "attack success rate above 90% for most" of 12 published defenses (How Do You Protect AI Agents Against Prompt Injection?).
  • A governed environment replaces a value with a consistent token before any model reads the screen, so an agent working a CI/CD variables page sees CI_TOKEN_001 and never holds the credential itself (Enterprise Browser or Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, and an agent that holds a private value, reads untrusted text and can send data out meets the lethal trifecta in one run (What Is the Lethal Trifecta for AI Agents?).

What does a detector inspect, and what does it leave untouched?

A prompt injection detector sees text and nothing else. On a browser task the text arrives from several directions: the page the agent is reading, a comment on a pull request, a package description, the output of a tool it called. The classifier scores that text, returns a label, and the harness decides whether to block, warn or continue. What the detector does not touch is the page itself: if the text passes, the model reads the page as rendered, including every value on it.

That is the whole of the detector's relationship to a credential. It stands in front of the model, and the value is in the model's context for every step after the gate. A detector that is right about 99 injections in 100 has, in those 99 cases, changed nothing about what the model can read. The hundredth case is where the run's design decides what leaves.

The control this page ends with is narrower than the agent's workspace, and the difference matters here. A governed browser environment covers what the agent reads and does on a rendered page: a repository settings page, a CI/CD variables page, a console, a dashboard, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A token read from a file in the tree, or printed from a shell, is outside it and inside the team's sandbox or credential store. A detector is the opposite shape: it sits on the text path wherever the text comes from, which is why the two are layers rather than alternatives.

The record type is a repository's CI/CD variables page, where a pipeline token sits in a field that can be revealed. Two designs carry the task: a detector in front of an agent that can read the value, and one in front of an agent that sees CI_TOKEN_001.

How much do the documented detectors promise?

The clearest published claim comes from LlamaFirewall, an open source guardrail stack. Its paper describes PromptGuard 2 as "a universal jailbreak detector that demonstrates clear state of the art performance" and says it "shows stronger efficacy at preventing indirect injections in general scenarios than previously proposed approaches", while the abstract gives no quantitative result behind either statement (Chennabasappa et al., 2025).

Progent takes a different route and reports the same shape of answer. It applies privilege control to an agent's tool calls and reports that it "significantly reduces attack success rates while maintaining high utility" (Shi et al., 2026). The abstract names AgentDojo and ASB as its evaluation settings and reports no figures, so the useful reading is structural: some injections succeed, and the design limits what a successful one can do.

The record on browsing agents shows what happens after a successful one. The study that lists credential exfiltration among its findings demonstrates "how untrusted web content can hijack agent behavior" (Mudryi et al., 2025). The three belong to one run: the content hijacks the agent, the domain check misses the destination, and the credential leaves.

Adaptive attacks are why misses should be expected rather than treated as exceptions. An attack study that tuned against published defenses reported an "attack success rate above 90% for most" of the twelve it tested (How Do You Protect AI Agents Against Prompt Injection?).

What do the vendors themselves say?

Cursor's agent documentation is direct about where its approvals sit. Terminal commands and MCP connections need approval by default, and the page warns that "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues" while describing its run modes as "best-effort guardrails rather than a hard security boundary" (Cursor, 2026). How Cursor stores or protects credentials is not described in the pages reviewed.

1Password and Browserbase describe a custody route for browser agents. 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", a claim about the browser's store and not about what a page renders after sign-in, paired with "Human-in-the-loop authorization" prompts on a person's device (1Password and Browserbase, 2025). The release gives no technical detail on how the autofill step is implemented.

Composio documents the connected-account version: "Credentials never pass through your app or the model, so it's safe to surface the link right in the chat", a design that keeps the token out of the model and leaves what the page shows the agent unchanged, and the user signs in on a hosted link while Composio stores the account (Composio, 2026). A revoked or expired refresh token moves the connection to EXPIRED.

Layer What the documentation states What a buyer should verify
Action approval (Cursor) Terminal commands and MCP connections need approval by default; run modes are "best-effort guardrails rather than a hard security boundary" Whether approval covers every consequential action, and what the model read before it asked
Autofill custody (1Password and Browserbase) Agents authenticate without the credential being shared with the LLM or exposed in logs and repos; a person approves in real time What the page renders after sign-in, and whether the model reads the account page
Connected accounts (Composio) Credentials never pass through the app or the model; a revoked or expired refresh token moves the connection to EXPIRED Who holds the token, and what the agent sees on a page that displays the connected account
Log masking (GitLab) A masked value becomes [MASKED] in the job log, and masking is not a guarantee Whether the value is hidden from the model, or only from the log

What does a missed injection collect in each design?

The record is a repository's CI/CD variables page, where a deploy token sits in a field the agent reveals. The injection arrives in an issue comment the agent was asked to read, and most teams are earlier than that: McKinsey's research finds 62% of organizations at least experimenting with AI agents and 23% scaling them anywhere (What Is the PII Wall?).

In the first design the detector is all that stands between the agent and the comment. An instruction phrased as an ordinary request passes a classifier that has not seen the phrasing, and varying it until one passes is cheap. The agent reveals the token because the task requires it, then follows the page text that asks it to post the variable block into the issue. Nothing separates that request from the task, because the model is holding the value the task is about.

In the second design the same comment passes the same detector, and the difference is what the model was given. The page renders CI_TOKEN_001, the workflow shows the same token, and the model proposes to post CI_TOKEN_001 into the issue. The run is still hijacked, and what leaves is a string that resolves only inside the environment that issued it, at a destination a named person approved.

Datadog reports that "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions", a static credential in a pipeline by another name (Datadog, 2025), and the Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? page records a 70 percent success rate for the same exposure on a rendered form.

What should a team add to a detector?

The research record's answer is to change the shape of the task rather than the filter's accuracy. Willison's design patterns "constrain the actions of agents to explicitly prevent them from solving arbitrary tasks", and one pattern keeps an agent from being "exposed to or act on the responses from those tools", so the untrusted text never reaches the model (Willison, 2025).

OWASP's CI/CD guidance points the same way for the credential: "Prefer using temporary credentials over static credentials" and "Avoid sharing the same set of credentials across multiple contexts", two design changes that lower what a miss is worth (OWASP, 2026). The entry also asks teams to "Detect secrets pushed to and stored on code repositories", a scanner aimed at the repository rather than at the model's input.

The logic applies to the credential's power. AWS strongly recommends against creating access keys for the root user, which rules out the simplest way an agent might hold durable top-level power (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). A token scoped to one environment and one action is a smaller thing to lose than an account credential, and a placeholder smaller still.

Runtime products answer a different question. Radware's brief describes discovery of AI agents, tools, and MCP and non-MCP servers, mapped to users and enterprise resources, an inventory of what exists rather than what any agent reads on a page it opens (RedactSure vs Radware: 2026 Comparison & Alternative). Inventory and approvals narrow the blast radius, not what the model is given before it acts.

What does a governed environment change?

Strip the product names away and the control class is simple enough to state in four clauses. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so what reaches the model is a placeholder such as CI_TOKEN_001 and not the credential. Real values resolve only at the approved destination, at the moment of an approved action, so a value reaches the workflow that needs it and not the transcript, the summary or the next page. A named person confirms the tokenization policy and approves each consequential action, which is the difference between a filter that guesses and a person who decides. 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, that changes two things a detector cannot. The first is what a missed injection collects. A detector tries to prevent a text classification error; this control class accepts that some injections will pass and makes the pass uneventful. The second is the record. A detector can log a score, and a score is not a statement of what the model saw. This record is per screen, per action and per approval, which is what an incident review needs after a miss.

A detector still earns its place in that design. It is the cheapest way to stop the obvious attempts, and it produces a signal a security team can watch. What it cannot do is make a credential safe to display, because the exposure happens after the label. The scope of the control described here is the rendered page, and it does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP; a token read from a file is governed by the sandbox and the store the team configures.

Methodology and limitations

This page rests on three research preprints, vendor documentation from Cursor, 1Password with Browserbase, Composio and GitLab, one industry standard from OWASP, one vendor research report from Datadog, a practitioner analysis by Simon Willison, and existing RedactSure research pages. 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 figures from research posts are cited as reported rather than independently measured. The preprints are cited for what their abstract pages state, and where an abstract gives no figure the page says so.

RedactSure did not test any of the named products hands-on. Where this page says a behavior is not described in the pages reviewed, it means the recorded pages do not state it, not that the vendor does not do it. Vendor features change, and the page carries its date; a release after that date is unreviewed until the test described on this page is repeated. The adaptive attack result is cited as the study reported it, without a rate for any product on this page or any vendor named here. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a repository's CI/CD variables page, and not an organization.

Determinations about whether a credential handling 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 with a test injection on a test repository, repeated after each release.

What the record shows

The documented claims are narrower than the products around them. PromptGuard 2 is described as a detector with state of the art performance and no published figure, Progent is a privilege control that reduces success rates and reports none, the browsing-agent study lists injection, destination bypass and credential exfiltration as one chain, and the vendor pages closest to this problem, autofill and connected accounts, keep a credential out of the model's context without changing what a page renders after a miss. The research record's own answer is structural: constrain what an agent can do, and control what it is shown. RedactSure's environment is built on the second half. To test this, run one known injection against a page that holds a value, using one agent and one task, and write down which layer stopped the text and what the model was holding when the text arrived.

Frequently asked questions

Does a prompt injection detector protect my credentials?

Only against the injections it recognizes. A detector is a classifier that labels text before the model reads it, and published defenses have been bypassed by attacks written against them, with an attack success rate above 90 percent for most of the twelve tested. When the classifier is wrong, the credential is protected by whatever the model was holding at that moment. That makes a detector necessary and not sufficient, and it makes the value on the page the thing to fix next.

Can a detector be accurate enough to rely on alone?

No page reviewed here makes that claim. LlamaFirewall's paper describes PromptGuard 2 as a universal jailbreak detector with state of the art performance and reports no quantitative result behind the phrase, and an adaptive attack study found most published defenses failing once an attacker tuned against them. Accuracy also depends on the attack, so a rate measured on one benchmark does not transfer to a new phrasing. Treat a detection rate as a starting point for testing your own traffic.

Does it matter if the agent never sees a real credential?

It changes what a miss costs. If the model's context holds a placeholder such as CI_TOKEN_001, a successful injection can still make the agent do something wrong, and what it sends is a string that resolves only inside the environment that issued it, at a destination a person approved. The task can still fail and the record still shows a hijacked run. The credential does not leave, which is the difference between cleaning up a workflow and rotating a deploy token.

What does masking a value in a log actually protect?

It protects the log, not the model. GitLab replaces a masked variable with [MASKED] when a job outputs it, and the same page warns that masking is not a guaranteed way to prevent malicious users from accessing variable values. A mask is a pattern match on output, which is the same shape as a detector and has the same weakness. If the goal is that the model never receives the value, the hiding has to happen before the model reads the page.

Where should a detector sit in an agent's stack?

On the text path, before the model, wherever the text comes from, with a logged decision so a security team can see what it blocked. That placement covers page content, tool output and comments in one gate. It does not cover what the page renders after the gate passes, which is why teams pair it with approvals on consequential actions, temporary credentials, and a control over which values the model is shown on each screen.

What should I ask before trusting a detector with a credential?

Ask for the failure rate on an adaptive test rather than a static one, for what the model receives on each screen the agent uses, and for the record of what it saw. Ask whether the value on the page is real or a placeholder at the moment the model reads it, and who approves a release of the real value. An answer that stops at detection has not addressed the run that follows the miss, which is where the credential goes.

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 Missed Injection From Collecting a Credential

Adaptive attacks pass most published defenses and vendors call their detectors guardrails, yet every design reviewed leaves the value on the page for whatever injection gets through.

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

Before: the agent opens the CI/CD variables page, reveals the deploy token, and the value sits in the context a missed injection can address. Inside the governed environment, the page renders CI_TOKEN_001 and the real value reaches the pipeline only on the named approver's confirmation.

RedactSure is deploying now with enterprise and government customers. An adaptive study found most published injection defenses failing once attackers tuned against them.

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

See it on your own workflow

A detector that misses one injection leaves whatever the model holds within reach. Bring a CI task your agent runs and see, with test values, what a missed injection would find on the variables page. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.