Layered detection, enforced authorization and a test plan for autonomous agents.
The short answer. Detect prompt injection in layers: inspect untrusted content, check every tool call the model proposes, watch sequences of actions, and keep protected logs. Then rely on controls outside the model, such as least privilege, independent authorization and human approval, because detectors will miss some attacks.
Autonomous agents read emails, search knowledge bases, query databases and call APIs. An attacker may never touch the agent directly. They can place instructions in a web page, document, support ticket or API response that the agent later reads.
If the agent treats those instructions as trustworthy and holds broad permissions, ordinary-looking content can trigger unauthorized actions. A stronger system prompt does not fix that. You need detection and, more importantly, controls that still hold when detection fails. For the basics, see what prompt injection is. For the "can it be fully prevented" question, see can prompt injection be prevented. This guide focuses on detection and containment for agents.
Detection works better when you know how untrusted content becomes an action.
Not every injection succeeds, and not every success causes damage. The outcome depends on the model, the tools, the access controls and the approval steps. That is why the application, not the model, has to decide what executes. See AI agent prompt injection for agent-specific vectors.
No single detector catches everything. OWASP's guidance is direct that screening "is not a security boundary," that a guardrail model is itself an LLM that can be attacked, and that passing a smoke test does not show resistance to a persistent adversary. Use several signals.
Check external content before it reaches the model. Warning signs include:
Use semantic checks, not just keywords, because attackers rephrase, hide and split payloads. Treat filtering as risk reduction. It does not make the remaining content safe.
Inspect what the model asks to do before it runs. A CRM agent that normally looks up one customer's status should raise a flag if it suddenly asks for thousands of records, a different department's data, or to send data to an unfamiliar destination.
Useful signals: unexpected tool choice, unusual parameters or resource IDs, widened scope, data unrelated to the user's task, repeated calls, and bulk retrieval combined with outside communication. A tool call can be well-formed and still unauthorized.
Some attacks chain steps that are each allowed. Retrieve customer records, build a report, send it outside may pass every individual check and still be data theft. Monitor the whole workflow, not only single API calls.
Record the initiating user, agent identity, tool, authorized scope, parameters, approval decision, result and destination. Protect the logs from the agent, and redact credentials and unneeded sensitive content. Independent logs let you reconstruct what happened without trusting the model's own account.
A detector can miss an attack. An enforced authorization boundary can still prevent harm.
MCP and function calling make it easier to connect tools, and add trust boundaries. Authenticate every connection, review third-party servers and their tools, limit tools by role, validate arguments in deterministic code, log and rate-limit tool activity, separate sensitive systems, require approval for high-impact operations, and watch for unexpected changes in tool descriptions. Using MCP or a popular framework does not make an integration secure. See AI agent tool security.
Use an authorized environment with mock APIs, synthetic data and harmless canary records.
| Test | Question |
|---|---|
| Direct injection | Can a user make the agent drop its task or reveal restricted information? |
| Indirect injection | Does it handle hostile instructions in documents, emails, pages and API responses? |
| Tool authorization | Can it call a restricted function or reach data outside the user's rights? |
| Tool chaining | Can allowed steps combine into an unauthorized result? |
| Exfiltration | Can canary data reach an unapproved destination? |
| Approval bypass | Can a high-risk action run without approval? |
| Regression | Do controls still work after model, prompt or tool changes? |
Measure whether the unauthorized action was blocked, not only whether a detector fired. A high alert count is not evidence of security if the action still completes. Our partial model comparison shows why: in single runs on our test apps, hardening cut indirect prompt injection from 12.5% to 0% but left format leakage at 23%. Read the limits there before quoting numbers.
If several of these are "no," close the gaps before giving the agent more autonomy.
HexTyx tests agents for prompt injection, token smuggling, RAG poisoning and tool abuse across 33 attack modules, and Aegis checks traffic at five points including the tool call. The goal is not to claim an agent is immune. It is to produce evidence that attacks are detected, unauthorized actions are blocked and failures are contained. Try the free playground or read how to test an AI system for security.
Run the free playground scanner against your AI application and see what an attacker could make it do.