Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Lakera Protect My Credentials From a Hijacked Agent?
Partly: Lakera screens the prompts, responses and tool calls routed through its Guard API, and a missed injection reaches an agent that still holds the credential on the page it opened. Ask what the model reads on each rendered screen and who approves the payee change before crediting a filter with custody.
A payments team connects an agent to its console to add suppliers and chase invoices. The agent signs in with a saved session, opens the vendor bank account page, and holds a live payments API token in the same context because the task told it to call the console's API. One supplier's remittance note carries an instruction the agent was never given, and the run follows it. The question is whether the guardrail the team bought stands between that instruction and the token, and the answer depends on a distinction the pages blur: a check that inspects a prompt is a different control from a substitution made on the page the prompt describes. Lakera's documentation is unusually specific about which of the two it sells, and clear enough to show what it leaves to the team: the route each step takes, the policy that decides what a match means, and the value the model holds when no match happens. A screen with an account number sits outside that check, and the token the agent submits with is in its context either way.
Key findings
- For a screen-reading agent to be safe behind a detector, the values on the rendered page would have to be replaced with consistent tokens before any model reads it, so a miss collects a placeholder and not the account number (What Can a Hijacked Agent Leak If It Only Has Placeholders?).
- It would also require a named person approving each payee addition, and a record of what the model read on each screen, because a filter's pass says nothing about the value the model holds (Why Should Submitting a Credential Require Its Own Permission?).
- Check Point's pages describe screening, blocking and masking on the request path and do not describe replacing a value on the screen an agent opens, so a hijacked run collects what the route and the policy let through (Check Point, Introduction, 2026).
- Check Point AI Agent Security "secures the AI applications and agents your organization builds and deploys," and the Guard API provides "real-time detection and flagging of prompt attacks, data leakage, content violations, and off-policy agent behavior" (Check Point, Introduction, 2026).
- Its agent page says the product "acts as an inline enforcement layer for AI agent interactions" and can "inspect prompts, model responses, external content, and agent tool calls in real time" (Check Point, Agentic, 2026).
Where does Lakera's guard sit in an agent's run, and what does it read?
Lakera Guard is sold today as Check Point AI Agent Security, and its documentation is direct about where the work happens. An AI gateway or the application itself calls the Guard API "for each user interaction or agent step" (Check Point, Introduction, 2026), and the product "acts as an inline enforcement layer for AI agent interactions" that can inspect a prompt, a tool call or a response as it passes (Check Point, Agentic, 2026). A value a policy matches "can be blocked, redacted, or controlled before it is sent to a model" (Check Point, Agentic, 2026).
That placement is a control over text. What the guard sees is what an application sends it: a prompt assembled from a page, a tool call and its arguments. It does not draw the page. When an agent opens a vendor bank account page, the console renders the account number and the payee name, and that text reaches the model only if the step routes through something that calls the guard. Whether it is masked, blocked or passed is a policy decision about the text that arrived, taken by a rule and not a person.
The control this page keeps returning to is narrower than an agent's workspace. A governed browser environment covers what the agent reads and does on a rendered page: a payments console's payee page, a hosting dashboard, an API keys page, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. Private data, untrusted content and a way out make a hijacked run worth attempting (What Is the Lethal Trifecta for AI Agents?).
What does the model receive when a check passes?
The record is a payments console's vendor bank account page, opened by an agent whose task gives it a live API token. A supplier's remittance note, read earlier, asks the agent to add a second account and to put the token in the memo. OWASP's agentic list puts Agent Goal Hijack first, as ASI01 (OWASP GenAI Security Project, 2025). The agent has been redirected, and the question is what it holds when that happens.
If the step routes through the guard, the prompt carrying the note is screened. A classifier that recognizes the phrasing blocks the step, and a policy that covers the account number masks it. Both are policy events on inspected text, and the leakage page describes the options as blocking the interaction or masking sensitive information (Check Point, Data Leakage, 2026). Neither changes what the console rendered, and the token is still in the model's context.
When the classifier misses and no rule covers the account field, the model reads both values and can act on both. A placeholder changes the second half: the model would hold ACCT_001 and TOKEN_001, the injection would collect strings that resolve only where a person approved their use, and the change would stop there (What Can a Hijacked Agent Leak If It Only Has Placeholders?). The same miss then costs a failed task, not a bank account. Willison's patterns "constrain the actions of agents to explicitly prevent them from solving arbitrary tasks," and one keeps an agent from being "exposed to or act on the responses from those tools" (Willison, 2025). Does a Prompt Injection Detector Protect My Credentials? makes that comparison for a coding agent.
What do the vendors themselves say?
The table takes each statement from Check Point's pages and pairs it with the question a buyer still has to answer. Quotations use the pages' wording, and the last column is the part the vendor's page does not settle.
| Dimension | Check Point Lakera, per its documentation | What a buyer should verify |
|---|---|---|
| Where the check runs | "have your AI gateway or GenAI application(s) make an API request to the Guard API for each user interaction or agent step" | Whether every step routes through a gateway that makes that call |
| What it inspects | "prompts, model responses, external content, and agent tool calls in real time" | Whether the rendered page is among the four things inspected |
| What it does with a match | "can either block the interaction or mask sensitive information" | What the model receives when no rule matches |
| Detector coverage | US-specific on some entities, and non-US numbers are not recognized | The countries of the account numbers the agent reads |
| Who approves an action | A policy blocks, redacts, allows or logs the interaction, and no person is named | The name on the approval for a payee change |
| The record | Flags and policy decisions on inspected traffic | Whether it shows what the model read on the page |
The Guard API is called per interaction, which makes coverage a routing question before a detection question, and the pages reviewed name no person who approves an action (Check Point, Introduction, 2026). Lakera's account of the joint architecture adds that "at runtime, Check Point operates inline with agent interactions to evaluate behavior and enforce decisions in context" (Lakera, Outcome Control, 2026). That describes a check on the interaction, and it is the check this page is asking about.
The detector list is narrower than a payments operation needs, since the page says non-US numbers are not recognized (Check Point, Data Leakage, 2026). A supplier account in another country is the value a payment fraud attempt targets, and the mask depends on the detector recognizing the number as sensitive first. What the guard would need in order to answer this page's question is a statement that the account number it inspects is the number on the screen, and the pages reviewed describe the interaction instead.
What can a hijacked agent do with a token it already holds?
A token's power is separate from what the model read. AWS's AssumeRole "returns a set of temporary security credentials," and "role chaining limits your AWS CLI or AWS API role session to a maximum of one hour" (AWS, 2026). A session's permissions are "the intersection of the role's identity-based policy and the session policies" (AWS, 2026). Scoping lowers the price of a miss without changing the text the model reads. Adaptive attacks got past most of 12 published defenses more than 90% of the time, so a guard that misses one injection still meets an agent holding the credential (How Often Do AI Agents Follow Injected Instructions?).
Doppler takes the same angle: "give every coding agent its own scoped, read-only, expiring set of credentials" (Doppler, 2026). Its page says values are "injected at runtime instead of written to a .env, so agents can't read, log, or commit them," and does not say whether the agent can read the variables in its own process (Doppler, 2026).
The allowlist has the same shape. Anthropic's permission rules "don't apply to a command that reads files without naming them, such as grep -r pattern . run from the directory that holds the file," the gap a rule list has (Anthropic, 2026). A rule names a path, and a command that reads without one goes around it.
The value on the page is what a substitution at the render layer changes (How Do You Let an AI Agent Manage API Keys Without Reading Them?). Giving every agent its own expiring credential is the second step (How Do I Roll Out Coding Agents to a Team Without Sharing Credentials?; Why Should Submitting a Credential Require Its Own Permission?).
What does a governed environment change?
The control class is four clauses. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so a model on a vendor bank account page sees ACCT_001 and TOKEN_001. Real values resolve only at the approved destination, at the moment of an approved action, so the account number reaches the bank form and not the memo. A named person confirms what is tokenized and approves each payee addition, payment and record change. Every screen as tokens, every action and every approval exports to the organization's own monitoring as a record.
For this page's question, the first clause does the work. A missed injection still reaches a model holding something, and the design decides what. If the model held the account number, the injection collects the account number. If the model held ACCT_001, the same successful injection collects a string that resolves only where a person approved its use, and the run ends as a blocked payee addition with a record. Detection in front of custody is a filter; detection in front of placeholders is a second layer over a page that no longer carries the value.
That is the difference between a control that decides whether a request proceeds and one that decides what the agent holds. Only one of them changes the text a hijacked model can read. The difference between a check and a substitution on the screen is set out in (RedactSure vs Check Point Lakera: 2026 Comparison & Alternative).
What the record shows
A hijacked run collects what the model was holding, so the useful question about any check is what it leaves on the screen behind it. The vendor's pages put the guard on the request path, inspecting prompts, tool calls and responses, and masking or blocking when a policy matches; the console still renders the real account number, and the token is still in the model's context. That makes the guard a filter on a route and the page the place a value has to change. Run one payee page as a test: capture the prompt text the model read, compare the account number in it with the number the console draws, and write down who approved the change.
Methodology and limitations
This page rests on Check Point's AI Agent Security and Lakera Guard documentation, vendor documentation from Anthropic, AWS and Doppler, one standard from the OWASP GenAI Security Project, one practitioner analysis by Simon Willison, and RedactSure research pages. Documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 20, 2026 and October 23, 2026, and each Sources line carries the date for its page.
No product on this page was tested for it, and where the page says a behavior is not described in the pages reviewed, it means the recorded pages do not state it, not that a vendor does not do 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 payments console's vendor bank account page, not an organization. Determinations about contractual or audit requirements belong to counsel and compliance officers.
Frequently asked questions
Does Lakera protect my credentials from an agent that gets hijacked?
Partly. It screens the prompts, tool calls and tool responses that reach its Guard API and blocks or masks what its policies recognize, which can stop an attempt before it lands. When a step does not route through the guard, or no rule matches, the model is holding whatever the page rendered, including the account number and any token the task put in its context. The protection is a function of the route and the policy, not a property of the run.
What does the Guard API actually see?
It sees the text an application sends it: a prompt, a model response, external content, or the arguments and results of a tool call. That is the interaction, not the screen behind it. If the console renders a bank account and the agent's step forwards that text, the guard can inspect it and apply a policy. If the step never reaches the API, the guard has nothing to inspect, and the same page text goes to the model unscreened, with no flag recorded.
Can masking keep a value away from the model?
Only when a policy matches the text being inspected. The data leakage page describes two outcomes, blocking the interaction or masking the sensitive information, and both happen to screened inputs and outputs. Masking is a decision about a request, so a value on a page a policy does not cover reaches the model as written. The page also says its detector list is US-specific on some entities.
Who approves a payee change an agent proposes?
Not from the pages reviewed: the documentation describes a policy that blocks, allows, redacts or logs an interaction, and it names no person who approves an individual action. That leaves the approval wherever the console or the team put it, often a session the agent inherited from an employee. A named approver outside the model is a different control, and it is the one an audit asks about after a payee is added.
What record does a screened run leave?
It leaves the guard's decisions: flags, blocks, redactions and policy outcomes on the traffic it inspected. That is a record of what the guard did with a request, not a per-screen record of what the model read, so an incident review that asks which account number the agent saw, on which page, at which step, has to get that answer elsewhere.
What should a team ask a vendor to show about what an agent reads?
One page, rendered as the model's prompt carried it, with the values visible in the position the model read them. Then the rule that matched, the person who approved the resulting action, and the record that holds both. Ask which of the agent's steps call the guard and which do not, because the answer decides what the check covers. A vendor that can show the page and name the approver is answering the question this page asks.
How RedactSure Keeps a Missed Injection From Reaching a Live Token
A guardrail decides whether a request proceeds, and the request it lets through still carries the account number and the token behind it. Check Point describes blocking and masking as policy outcomes on the inspected interaction (Check Point, Data Leakage, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the vendor bank account page with a live token in its context and reads the supplier's real number. Inside, the page renders ACCT_001 and TOKEN_001, and the real number is released at the bank form when a named person approves.
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
A missed injection costs the account number and the token behind it, and what the model received decides which one leaves. Bring a payments task and see, with test values, what the model reads and who approves the release. Book a demo