AI Security
Prompt Injection in Agentic AI: Risks, Examples, and Defenses
A practical guide to direct and indirect injection, safe testing, and layered defenses for tool-using agents.
Prompt injection becomes more dangerous when an LLM can call tools, access internal data, or take actions. The model is no longer only generating text; it is participating in a workflow.
Indirect prompt injection can arrive through documents, web pages, emails, tickets, or retrieved knowledge. Treat retrieved content as untrusted data rather than trusted instructions.
Use least-privilege tools, explicit allowlists, strong authorization outside the model, and human approval for high-impact actions.
Logging should capture tool requests, data sources, policy decisions, and outcomes without exposing sensitive information.
Security testing should include realistic multi-step scenarios rather than only isolated jailbreak prompts.
Table of Contents
- Why agents change the threat model
- What prompt injection is
- Safe example
- Business impact
- Testing approach
- Layered remediation
Why Agents Change the Threat Model
A conventional chatbot mainly returns text. An agent can retrieve information, call APIs, create records, send messages, or change a workflow. That capability creates a security boundary between untrusted content and the tools that can affect the business.
A model must never be the only authorization decision-maker. Every tool needs its own server-side policy checks for identity, purpose, scope, and allowed parameters.
What Prompt Injection Is
Prompt injection attempts to manipulate an AI system through text that it processes. Direct injection comes from a user message; indirect injection can arrive in a document, web page, email, ticket, or retrieved knowledge-base item.
The problem is not that untrusted content contains instructions. The problem occurs when the application lets that content change authority, expose data, or trigger a sensitive action.
Safe Illustrative Example
Imagine a support agent that summarizes an invoice and can create a draft refund request. A malicious document may try to steer the agent toward a different account or an unapproved action.
The secure design lets the agent summarize the document, but requires a verified user to select an approved order and confirm the action. The back end independently enforces authorization and amount limits.
User or document → AI agent → policy layer → approved tool → business system
↑
untrusted instructionsBusiness Impact and Risk
| Severity | Description |
|---|---|
| Critical | Agent performs high-impact actions across privileged systems. |
| High | Sensitive records are exposed or unauthorized communications are sent. |
| Medium | A workflow is manipulated or a misleading summary affects decisions. |
| Low | Non-sensitive output quality is degraded. |
How to Test Safely
Use an isolated environment and synthetic data. Create benign adversarial documents that try to redirect intent, request unapproved tools, or expand the requested data scope.
Verify that the system blocks the attempt, asks for confirmation when required, logs the policy decision, and keeps tool parameters within approved bounds.
Layered Remediation
- Give each tool a narrow, purpose-built permission.
- Enforce authorization and parameter validation in the tool service, not in a prompt.
- Separate trusted instructions from retrieved and user-provided data.
- Require human confirmation for consequential actions.
- Log policy denials, tool attempts, confirmations, and outcomes.
AI Agent Security Checklist
- Tools have least-privilege credentials and narrow schemas.
- Retrieved content is treated as data, not authority.
- Sensitive actions require independent user confirmation.
- Tenant and data-classification boundaries are enforced before retrieval.
- Adversarial evaluations cover tools, RAG, and multi-step workflows.