Prompt Injection: Direct and Indirect Attacks in AI Agents

An email your agent reads must not become permission to send another email, export customer data, or change a deal. The Open Worldwide Application Security Project (OWASP) lists prompt injection as LLM01 in its Top 10 for LLM Applications: for builders, the practical response is to constrain what the application can do even when the model follows the wrong instruction. No defense fully solves prompt injection today.

Verified against OWASP and Anthropic's live guidance on 26 October 2026. The inbox and CRM scenarios below are illustrative designs, not reported deployment results.

What Is Prompt Injection?

Prompt injection happens when input redirects a language model away from its intended instructions. A large language model, or LLM, interprets language to produce answers and propose actions. The problem begins when something it should merely read becomes something it obeys.

Imagine an employee reviewing a supplier's letter. The letter can describe a delivery problem; it cannot grant the supplier access to your customer database. An agent needs the same distinction between information and authority, with application controls enforcing it.

OWASP identifies both direct user input and indirect external content as entry points in LLM01:2025 Prompt Injection. The important boundary is who gets to set the task and permissions, not whether the suspicious text sounds professional.

A mistaken answer is not automatically an injection. The model might invent a fact without outside manipulation. Injection specifically involves input steering its behavior. Both can cause harm, but a filter looking for hostile instructions will not catch every ordinary model mistake.

How Does Prompt Injection Work in Generative AI?

The model reads instructions and task material together, and may give the task material authority it should not have. Roles and source labels help it distinguish them, but they do not replace access controls.

An agent adds a consequential next step: the application turns a proposed action into a tool call. A tool is a function for doing something outside the conversation, such as searching records or sending a message. If the application executes whatever the model proposes under broad credentials, a language error can become a business action.

That is the wall every tool-using agent reaches: understanding a request does not establish that the request is authorized.

Prompt Injection Examples: Direct and Indirect

The difference is where the hostile instruction arrives. These examples describe the attempted behavior without publishing attack text.

Direct Prompt Injection

A customer types into a support assistant and tries to persuade it to reveal a different customer's account notes by pretending the request has special internal authorization. The attacker is directly using the application's input channel.

The defense must include a records service that checks the authenticated customer's access. Even if the model accepts the story, that service should refuse the unrelated record. A refusal written into the system prompt is useful guidance; the records check is what enforces the boundary.

Indirect Prompt Injection

A sales founder asks an agent to summarize a prospect's email and suggest a next step. The email contains material designed to redirect the agent into exporting unrelated contacts from the customer relationship management system (CRM) to an outside recipient. The founder's request is legitimate; the hostile instruction comes from the email being processed.

The same delivery route can involve a webpage, document, attachment, or tool result. An internal storage location does not make every record trustworthy: a customer might have supplied the text now sitting in your CRM. Anthropic, the maker of the Claude language model, treats these third-party sources as a distinct threat model in its prompt-injection safeguards guidance.

For an inbox agent, the person who sends the email must never inherit the mailbox owner's tool permissions simply because the owner asked for a summary.

Prompt Injection vs Jailbreak

A jailbreak tries to bypass a model's safety restrictions. Prompt injection can also target the application's ordinary task or permissions. An altered sales summary or an unauthorized contact update may look harmless to a content-moderation system while still violating the business's rules.

Use both content safeguards and authorization checks. They answer different questions.

Why Prompt Injection Attacks Become a Business Risk

The damage grows with the data and actions the agent can reach. OWASP's separate Excessive Agency guidance identifies excessive functionality, permissions, and autonomy as causes of damaging agent behavior.

For an inbox or CRM system, the consequences fall into recognizable business failures:

• Private data leaves. An output, attachment, outgoing request, or message includes information the recipient should not receive.
• Records change without authority. The agent edits an account, deletes useful history, or changes a deal stage because retrieved text redirected it.
• A decision is quietly distorted. A prospect looks more qualified, a complaint disappears from a summary, or a supplier receives an unjustified recommendation.

Read-only is narrower than write access, but it does not mean confidential data cannot escape. If the application retrieves private records and can disclose them through an answer or outbound connection, confidentiality still needs protection.

Palo Alto Networks' Unit 42 documented malicious instructions embedded in live web content in research published on 3 March 2026. Finding an attempt does not prove every target followed it. It does show why external content belongs inside the threat model before an agent is allowed to act.

Founders should approve the maximum damage a workflow is allowed to cause. Builders should make that limit enforceable at data and tool boundaries. Operators need a way to pause execution and investigate when those boundaries are tested.

How to Prevent Prompt Injection From Becoming an Incident

Design for the possibility that an injection gets through. The following is a recommended control design for an inbox or CRM agent, applying OWASP's privilege and approval guidance to a concrete workflow. It is not a product benchmark or a guarantee of immunity.

Start with the tool's actual permissions. A function named “summarize inbox” is not limited to summarization if the credential behind it can send messages and delete mail. Check the underlying account and service configuration, not just the function name.

Next, control data leaving the application. A network allowlist, a list of permitted destinations, helps reduce the routes available for disclosure. But allowing a mail service does not authorize every recipient, and allowing a CRM domain does not authorize every account or export operation. Validate the request within the allowed service as well.

Anthropic's secure-deployment guidance describes keeping credentials outside the agent's environment, restricting network access, and validating requests through a proxy. A proxy is an intermediary that can apply policy before forwarding a request. For a hosted inbox integration, the equivalent boundary may be your own tool service: it holds the credential and rejects out-of-scope operations.

For the wider set of input, output, and execution checks, see AI guardrails.

What Anthropic's Guidance Means for Retrieved Content

Anthropic recommends passing third-party material in tool_result blocks, identifying its source, setting an explicit untrusted-content policy, and JSON-encoding strings instead of inserting them into free-form instructions. Its guidance also calls for screening tool outputs and monitoring behavior. See the current Claude guidance.

For the sales example, keep the prospect's email body identifiable as an email from that sender. Do not copy it into a privileged instruction just because a previous model step summarized it. Preserve the source reference when passing extracted information to another step.

JSON is a structured data format. Escaping its text correctly prevents text from breaking the surrounding serialization; it does not prevent the model from being persuaded by the text's meaning. Treat the encoding recommendation as one layer, with authorization still enforced elsewhere.

Make Approval Bind to the Exact Action

A review button protects the business only if execution depends on what the person reviewed. “Continue processing this account” is too vague for an agent that can send attachments or rewrite customer records.

Consider a proposal to reply to a prospect and update a deal. The reviewer needs the actual recipient, message, attachment list, affected record, and before-and-after field values. The application should preserve the approved proposal and execute that version. If the model changes the recipient or attachment afterward, require another review.

Approval must also come from an authenticated person with the right authority. A statement inside an email that someone already approved the work is source content, not an approval event. The model must not be able to create its own approval record or reach a second tool that bypasses the gate.

Keep the action pending if the reviewer declines, the approval expires, or the review system is unavailable. A timeout must not silently turn into permission. Design retries so that a delivery failure does not cause the same approved message to be sent repeatedly.

These are implementation recommendations for the workflow, not a claim that human review catches every attack. The human-in-the-loop AI guide explains how to staff review queues and handle escalation.

A Short Checklist for an Inbox or CRM Agent

Ship the narrowest useful workflow first. Use this checklist before enabling autonomous external actions:

• Identity: Every read and change is scoped to the authenticated user and authorized business account. The model cannot select a more privileged identity.
• Data: Retrieve only the records and fields needed for the task. Keep secrets out of model-visible content and preserve the origin of email, document, and CRM text.
• Tools: Reading, drafting, sending, exporting, and editing are separate permissions. Remove capabilities the workflow does not need.
• Release: Check answers and tool arguments before they leave. Validate recipients, attachments, destinations, and allowed record changes.
• Approval: High-impact actions require an exact-action review enforced by application code. Missing or changed approval means hold.
• Operations: Keep a privacy-conscious action log, assign an alert owner, provide a pause mechanism, and test the full workflow before expanding access.

For a founder's sales assistant, a sensible starting scope is reading a selected prospect thread and proposing a draft. A mass export, automatic send, or bulk deal update should be a separately justified capability. Scope permissions around the job you intend to offer, rather than everything the integration makes possible.

The production AI-agent blast-radius playbook develops the broader containment architecture. Blast radius means how far a failure can spread through connected systems.

Prompt Injection Testing: Check the Effects, Not Just the Reply

A test passes when the forbidden outcome does not happen. An assistant can print a refusal after a tool call has already changed a record. Inspect the tool service and resulting state, not only the chat transcript.

Use synthetic contacts, test mailboxes, and a controlled environment for a launch rehearsal. The following is an application test plan, not a set of attack payloads.

1. 1

   Establish the authorized baseline

   Run an ordinary prospect-summary task. Confirm that the right records are retrieved, the draft is useful, and approval is required exactly where your policy says it is. Legitimate work must still succeed.

2. 2

   Exercise both delivery routes

   Include an unauthorized request at the user-input boundary and a third-party message that attempts to redirect the task. Check that unrelated records remain inaccessible and prohibited tool operations are denied.

3. 3

   Challenge approval and failure handling

   Try changed action details after approval, a declined review, an unavailable policy service, and a retried execution. Confirm that the application holds or rejects the action and avoids duplicate effects.

4. 4

   Inspect evidence and alerting

   Check the final CRM state, outgoing messages, attempted destinations, approval record, and policy log. Confirm that the operator can identify the source and stop the workflow without relying on the model's explanation.

Repeat the relevant tests when prompts, models, retrieval, tools, or permissions change. A result belongs to the tested configuration; it does not certify every future version.

Log enough to reconstruct the decision without turning the audit trail into another copy of the entire inbox. Prefer stable record references, necessary action details, policy versions, and access-controlled evidence. Give someone responsibility for investigating blocked destinations, unexpected exports, and repeated approval failures.

What Is Overhyped, and What Remains Unsolved?

No model, prompt, filter, or guardrail product should be treated as a complete solution. OWASP explicitly notes that retrieval-augmented generation and fine-tuning do not fully mitigate prompt injection. Retrieval-augmented generation, or RAG, supplies documents to help a model answer; it does not grant those documents authority to change the task.

A stronger system prompt can improve behavior. It cannot make a broad credential narrow. A classifier can flag suspicious content. It cannot decide whether a particular employee may disclose a particular attachment. A second model reviewing the first adds a check, but it still needs independent application policy.

There is also no universal detection percentage that tells you whether your inbox agent is ready. Useful limits are workflow-specific: which accounts it can read, which fields it can change, where data can go, and which actions require review. A vendor result on a different task is not evidence that your approval path cannot be bypassed.

The defensible claim is narrower and more useful: layered controls reduce exposure and limit consequences, while testing and monitoring reveal failures. Residual risk remains.

Act now if an agent already reads outside content and can disclose private information or change business state. Wait on broader autonomy until permissions, approval, and failure handling are enforced. A public-document summarizer with no private data or action tools has a narrower consequence profile, but still needs protection against manipulated answers.

Frequently Asked Questions

How to protect against prompt injection attacks?

Limit data access and tools, separate untrusted content from instructions, validate outputs and actions, require review for high-impact operations, and monitor outcomes. Enforce permissions outside the model; no single layer eliminates the risk.

What is an example of a prompt?

“Summarize this prospect's email and draft a reply for review” is an ordinary prompt. The prospect's email is task material, not permission to change the request.

Is SQL injection still used?

Yes. SQL injection remains relevant to applications that build unsafe database queries. It needs database-specific defenses as well as any prompt-injection controls; see OWASP's injection guidance.

What is injection in coding?

In security, injection means untrusted input changes what an interpreter executes or processes. Prompt injection targets a model's behavior; other injection flaws target database queries, commands, or browser code.

What is injection in simple terms?

It is input crossing a boundary and being treated as an instruction it was never authorized to give.

What are the different types of code injections?

Examples include SQL, operating-system command, and script injection. The defenses depend on the interpreter involved. Prompt injection is related by the trust-boundary problem, but is not a synonym for all code injection.

What are the different types of prompt injections?

The main delivery distinction is direct versus indirect: the attack arrives through the user's input or through content the application retrieves. Text in images and other media can also carry instructions; delivery route and media format are different dimensions.

What are the 7 main types of hackers?

Hacker labels are not a useful permission policy for an agent. Base controls on who is authenticated, who can influence the content, and what the application may access or change.

What is DDoS and SQL injection?

DDoS means distributed denial of service, an attack on availability using distributed sources. SQL injection manipulates database queries. They are separate problems from prompt injection; OWASP's denial-of-service guidance addresses availability defenses.

Your Monday Move

Pick a live inbox or CRM workflow and list its reachable data, tools, and external destinations. Remove unnecessary access, make consequential actions wait for exact-action approval, and demonstrate that a rejected proposal produces no external effect. Expand autonomy only after the useful task and the denial paths both work.

Get practical guides to building AI workflows in the newsletter.