Detect Prompt Injection Attacks in AI Agents

What prompt injection actually is

A prompt injection attack feeds adversarial instructions to an AI model, attempting to override its original instructions or system prompt. In a chat-only model, the impact is limited to generating harmful or off-topic text. In an AI agent with tool access, the impact is fundamentally different: the injected instruction can trigger file reads, shell commands, API calls, or data exfiltration through the tools the agent already has permission to use.

This is what makes prompt injection in agents a security problem rather than just a reliability problem. The attack surface is not the model's text output - it is everything the agent can reach.

Direct vs indirect injection

Direct injection arrives in the user's own input. The attacker is the user (or someone with access to the input channel), and the goal is typically to bypass safety filters or extract system prompts. Direct injection matters, but for agent security it is often the less dangerous variant because the user already has some level of access.

Indirect injection arrives through data the agent fetches during its work. A web page the agent reads, a document it opens, an MCP tool result, a database record, or even an email body can contain adversarial instructions. The model processes this content as context and may follow the embedded instructions because it cannot reliably distinguish data from commands. Indirect injection is the more serious threat to agents because it allows a remote attacker to influence an agent they never directly interact with.

Why tool-using agents raise the stakes

A chat model that follows an injected instruction produces bad text. An agent that follows one can execute a shell command, write to a configuration file, send data to an external URL, read credentials from the filesystem, or call an MCP tool with crafted arguments. The gap between "the model said something wrong" and "the agent did something dangerous" is the entire difference between a chatbot vulnerability and an infrastructure vulnerability.

Agents running through the Model Context Protocol are especially exposed because MCP connects models to tools that interact with real systems: databases, file systems, cloud services, and APIs. Each connected MCP server is both a capability and a potential attack surface. A poisoned tool description, a malicious tool result, or a crafted input that tricks the model into calling the wrong tool with the wrong arguments can all result in real-world consequences.

Detection approaches

No single detection technique handles prompt injection completely. Practical defenses layer multiple approaches, each catching a different class of attacks. Here are the main categories used in the industry today. For a deeper comparison of the trade-offs between them — coverage against latency, and the false-positive economics that decide what you can leave switched on — see our prompt injection detection methods post.

Pattern and heuristic matching

The fastest detection layer. Structural patterns, encoding tricks, and known injection templates can be caught with deterministic checks that run in sub-millisecond time. This layer handles the attacks that look like attacks: role overrides, instruction resets, encoded payloads, and templated bypass attempts. The weakness is that it cannot catch novel natural-language attacks that do not match any known structure.

Intent and semantic analysis

A step beyond pattern matching: analyzing whether the input's semantic intent conflicts with the agent's legitimate task. This catches attacks that avoid structural patterns but still carry adversarial intent, such as social-engineering-style prompts that ask the agent to "just quickly check" a sensitive file. Intent analysis extends coverage beyond the template-matching ceiling, though it introduces more computational cost.

Behavioral trajectory monitoring

Instead of looking at individual inputs, trajectory monitoring watches the sequence of actions an agent takes. A single tool call might look benign in isolation, but reading a credentials file followed by an HTTP request to an external URL is a recognizable exfiltration pattern. This approach catches multi-step attacks that no single-message detector would flag.

LLM-as-judge

Using a separate model to evaluate whether an input or action looks adversarial. The judge model has the broadest coverage for novel attacks because it can reason about intent in natural language. The trade-off is cost and latency: running a second model call on every agent action is expensive, so practical implementations use the judge selectively on ambiguous cases that the faster layers flag but cannot resolve.

OS-level sandboxing

Sandboxing is not detection - it is containment. If an injection succeeds and a detector misses it, a sandbox limits the blast radius by restricting which files, network endpoints, and system calls the agent process can access. Sandboxing and detection are complementary: detection tries to catch the attack before it executes; sandboxing limits the damage if detection fails.

Where detection runs in the agent loop

The most effective placement for detection is at every trust boundary the agent crosses, not just the initial input. An agent loop typically has four boundaries worth inspecting: the user input entering the model, the tool call the model wants to execute, the result the tool returns, and the final output the model produces. Each boundary catches a different class of attack that the others structurally miss.

Input-only scanning misses indirect injection arriving through tool results. Output-only scanning cannot prevent a dangerous tool call from executing. Tool-dispatch checking cannot see a poisoned instruction embedded in the content a tool returns. Covering all four boundaries is the core idea behind multi-port runtime inspection.

Honest limits of detection

Pattern-based detection catches what it has patterns for. Novel natural-language attacks that avoid all known structural signatures will get through the fast layers. Intent analysis and LLM judges extend coverage but cannot reach every paraphrase in an unbounded language space. This is a structural ceiling, not a bug to fix.

Clawmont publishes its own numbers openly on the security page: the measured detection rate on a tested corpus, the far lower rate on novel unseen attacks, and zero false positives, with the bypasses included. The cost-gated LLM judge extends coverage for the long tail. We publish these numbers because honest defense-in-depth is more useful than a false promise of total protection.

How Clawmont approaches this for OpenClaw

Clawmont Security is a local-first security layer that runs inside the OpenClaw gateway. It inspects all four boundaries of the agent loop: user input, tool dispatch, tool results, and model output. Detection decisions are recorded in a hash-chained local audit log. Your API keys and conversation data never leave your machine.

The approach layers fast deterministic checks with a cost-gated LLM judge for ambiguous cases. It is detection, not containment - there is no sandbox or syscall filter. If a detector misses, the tool runs. That is why we recommend pairing Clawmont with whatever OS-level isolation your setup supports.

Clawmont Security is licensed under BUSL-1.1 (source-available, converting to Apache 2.0 in 2028). It is available at $9.99/month bundled with a persona setup or $19.99/month standalone, and both rates start with a 7-day free trial. See the security playground to test attack patterns interactively, or read the security architecture for the full picture.

Runtime prompt injection detection for OpenClaw

Four-boundary inspection, zero false positives, local-first privacy. See how it works.

Security architecture Try attack patterns

FAQ

What is a prompt injection attack?

A prompt injection attack is an attempt to override an AI model's instructions by embedding adversarial text in the input. In the context of AI agents with tool access, this can cause the agent to execute unauthorized commands, leak credentials, or exfiltrate data through tool calls the user never intended.

What is the difference between direct and indirect prompt injection?

Direct prompt injection comes from the user input itself. Indirect prompt injection arrives through data the agent retrieves during its work - a fetched web page, a database record, an MCP tool result, or a document the agent reads. Indirect injection is harder to detect because the malicious payload enters through a trusted data channel, not the conversation.

Can prompt injection be fully prevented?

No. Natural language is unbounded, so novel phrasings will always exist that no fixed set of patterns can catch. Realistic defenses layer multiple detection approaches and accept that some attacks will get through. Honest security tools publish their detection gaps alongside their capabilities.

How does Clawmont detect prompt injection in OpenClaw agents?

Clawmont inspects four boundaries in the agent loop: user input, tool dispatch, tool results, and model output. It applies detection checks at each boundary and blocks or flags content that matches known attack structures. On a tested corpus it catches the majority of known attacks with zero false positives, and far fewer of the novel, unseen ones, which is why layered defenses matter. The exact measured rates and full red-team methodology are published on the security page (clawmont.com/security).

Does Clawmont replace model-level safety features?

No. Model-level safety (RLHF alignment, system prompt enforcement) and runtime detection like Clawmont work at different layers. Model safety shapes the model's tendencies; runtime detection inspects the actual inputs and outputs as they move through the agent loop. They are complementary - run both.

How to Detect Prompt Injection Attacks in AI Agents