03 Indirect Prompt Injection

In the previous lesson, you learned how Direct Prompt Injection occurs when an attacker sends manipulative instructions directly to an LLM application.

But what happens when the attacker never interacts with the AI application?

Consider an AI assistant that can:

Browse websites
Read emails
Analyze documents
Search enterprise knowledge
Retrieve RAG content
Query external APIs
Use AI agent tools

The attacker may instead place malicious instructions inside content that the AI later consumes.

The attack path becomes:

Attacker
   ↓
External Content
   ↓
AI Application Retrieves Content
   ↓
LLM Processes Content
   ↓
Model Behavior Influenced

This is known as Indirect Prompt Injection.

For enterprise AI systems, this is particularly important because modern AI applications increasingly retrieve information automatically from sources the user or application may not fully control.

The security challenge is therefore no longer simply:

Can we trust the user prompt?

It becomes:

Can we trust everything the AI reads?

Learning Objectives

By the end of this lesson, you should be able to:

Explain Indirect Prompt Injection.
Distinguish direct and indirect prompt injection.
Identify external instruction sources.
Understand document-based attacks.
Understand web-based attacks.
Understand email-based attacks.
Recognize RAG-based indirect injection.
Understand AI agent exposure.
Identify trust boundaries around retrieved content.
Understand persistent indirect prompt injection.
Recognize potential data-exfiltration scenarios.
Apply defense-in-depth controls.
Understand detection and monitoring requirements.
Perform safe indirect prompt injection testing.
Document findings professionally.

What Is Indirect Prompt Injection?

Indirect Prompt Injection occurs when attacker-controlled instructions reach an LLM through content that the application retrieves or processes.

Instead of:

Attacker
   ↓
AI Chat Interface
   ↓
LLM

the attacker may use:

Attacker
   ↓
Document / Website / Email / API
   ↓
AI Application
   ↓
LLM

The application expects the retrieved information to be:

DATA

but the content may contain text that the model interprets as:

INSTRUCTIONS

This creates the security problem.

Direct vs Indirect Prompt Injection

Direct Prompt Injection

The attacker directly supplies the malicious input.

Attacker
   ↓
Prompt
   ↓
LLM

Indirect Prompt Injection

The attacker modifies or controls information the LLM later consumes.

Attacker
   ↓
External Content
   ↓
Application Retrieves Content
   ↓
LLM

The second attack can be harder to recognize because the application user may be completely legitimate.

Example

Imagine an employee asks:

Summarize this document.

The document contains normal business information plus embedded instructions intended for the AI system.

The workflow becomes:

Employee
   ↓
Uploads Document
   ↓
AI Assistant
   ↓
Document Content
   ↓
LLM

The employee’s request is legitimate.

The dangerous input exists inside the document.

Why Indirect Prompt Injection Matters

Modern AI applications consume increasingly large amounts of external information.

Examples include:

Websites
+
Documents
+
Email
+
Search Results
+
Databases
+
RAG
+
API Responses
+
Tool Results
+
Agent Memory

Every external source that reaches the model may represent another trust boundary.

The Fundamental Problem

Suppose the application tells the model:

Summarize the following webpage.

The webpage contains:

Normal Article Content

[Instructions attempting to change
the AI application's behavior]

More Article Content

From the application’s perspective:

Everything = Web Content

But from the model’s perspective, all of it is natural language.

The model must determine:

Is this information?

or

Is this an instruction?

This ambiguity creates the attack surface.

Trust Boundaries

Indirect Prompt Injection is fundamentally a trust-boundary problem.

Consider:

Trusted Application
       │
       ▼
       LLM
       ▲
       │
Untrusted Website

The website exists outside the application’s trust boundary.

If website content enters the model context, the trust boundary has effectively been crossed.

External Content Should Be Untrusted

A useful security principle is:

Content retrieved from external sources should be treated as untrusted input.

This includes:

Websites
Email
Uploaded files
Search results
Third-party APIs
User-generated content
External knowledge bases

Even if the source appears legitimate.

Internal Content Is Not Automatically Safe

Suppose an enterprise uses:

SharePoint
Confluence
Internal Wiki
Document Repository

as RAG sources.

You might assume:

Internal = Trusted

But internal documents may be:

User-editable
Compromised
Outdated
Incorrect
Imported externally
Created by another automated system

Therefore:

Trusted Repository
       ≠
Trusted Instructions

This distinction is extremely important.

Attack Surface 1 — Documents

Document-processing applications are common.

Example:

User
 ↓
Upload PDF
 ↓
AI Document Assistant
 ↓
Extract Text
 ↓
LLM

The document itself becomes part of the LLM context.

Potential document sources include:

PDF
Word
PowerPoint
Markdown
Text files
Source code
Spreadsheets

The security question is:

Can attacker-controlled document content influence model behavior beyond the intended document-processing task?

Document Scenario

Imagine an organization uses AI to review resumes.

Candidate
   ↓
Resume
   ↓
Recruitment AI
   ↓
Candidate Evaluation

The candidate controls the resume.

Therefore:

Resume Content
      =
Untrusted Input

Security architecture should assume the document may contain content designed specifically for an AI reader.

Attack Surface 2 — Websites

AI browsing assistants may automatically retrieve web content.

User
 ↓
AI Assistant
 ↓
Web Search
 ↓
Website
 ↓
LLM

The website operator may control the text the model sees.

This creates a potential indirect attack path:

Attacker
   ↓
Controls Web Content
   ↓
AI Visits Website
   ↓
LLM Processes Content

Search Results

Even search results can introduce untrusted content.

AI Agent
   ↓
Search Engine
   ↓
Search Results
   ↓
Website Content
   ↓
LLM

An attacker may attempt to make malicious content discoverable by the AI.

This means security architects should not assume:

Search Result
      =
Trusted Information

Attack Surface 3 — Email

Email assistants represent another important example.

Consider:

External Sender
      ↓
Employee Email
      ↓
AI Email Assistant
      ↓
LLM

The external sender controls the message.

The employee may ask:

Summarize my unread emails.

The AI processes attacker-controlled content even though the employee never entered a malicious prompt.

Email + Agent Risk

Now suppose the assistant can also:

Send email
Access documents
Create calendar events
Search enterprise information

The architecture becomes:

External Sender
      ↓
Email
      ↓
AI Assistant
      ↓
LLM
      ↓
Tools
      ↓
Enterprise Systems

The potential impact has increased significantly.

Attack Surface 4 — RAG

RAG is one of the most important indirect prompt injection surfaces.

Recall:

User Question
      ↓
Retriever
      ↓
Vector Database
      ↓
Relevant Documents
      ↓
LLM

If a malicious document enters the knowledge base:

Attacker
   ↓
Malicious Document
   ↓
Knowledge Base
   ↓
Embedding
   ↓
Vector Database
   ↓
Retrieved Context
   ↓
LLM

The malicious content may influence responses whenever it is retrieved.

Persistent Indirect Prompt Injection

This introduces an important concept:

Persistence.

Direct prompt injection may exist only during one interaction.

But poisoned RAG content may remain stored.

Malicious Content
      ↓
Knowledge Base
      ↓
Vector Database
      ↓
Retrieved Repeatedly

The same malicious content could potentially influence multiple future sessions.

This makes content governance extremely important.

RAG Poisoning vs Prompt Injection

These concepts can overlap.

RAG Poisoning

Focuses on introducing malicious or misleading content into the knowledge source.

Attacker
   ↓
Knowledge Base

Indirect Prompt Injection

Focuses on instructions inside retrieved content influencing model behavior.

Malicious Content
      ↓
LLM
      ↓
Behavior Changes

A single attack may involve both.

Attack Surface 5 — API Responses

AI agents increasingly consume API data.

AI Agent
   ↓
External API
   ↓
Response
   ↓
LLM

If the response includes attacker-controlled natural language, it may become another indirect input channel.

For example:

Customer Record
Support Ticket
Product Description
Issue Description

may contain user-controlled text.

Attack Surface 6 — Databases

Enterprise AI may query databases.

LLM Application
      ↓
Database
      ↓
Record
      ↓
LLM Context

A database may contain user-generated content.

For example:

Support Ticket:
User-Controlled Description

If the AI processes the description, the content should not automatically be trusted.

Attack Surface 7 — Source Code

AI coding assistants may analyze repositories.

Repository
   ↓
Source Code
   ↓
AI Coding Assistant
   ↓
LLM

Repository content may include:

Comments
Documentation
Configuration
Issues
Commit messages

Some of this may be attacker-controlled.

The repository therefore becomes another input surface.

Attack Surface 8 — Tool Output

Agents may invoke tools and feed the result back to the LLM.

LLM
 ↓
Tool
 ↓
Result
 ↓
LLM

If the tool returns untrusted content:

LLM
 ↓
Web Search Tool
 ↓
External Website
 ↓
Result
 ↓
LLM

the tool response becomes an indirect prompt injection channel.

Agent Feedback Loops

Agents may operate iteratively:

LLM
 ↓
Choose Tool
 ↓
Tool Result
 ↓
LLM
 ↓
Choose Next Tool
 ↓
Tool Result
 ↓
LLM

A malicious tool result may influence subsequent reasoning and tool selection.

This can create a dangerous feedback loop.

Why AI Agents Increase Risk

A basic LLM might only generate:

Text

An AI agent may:

Read
Write
Search
Send
Execute
Modify
Delete

Therefore:

Indirect Prompt Injection
        +
Agent Capability
        +
Enterprise Permission
        =
Potential Operational Impact

This is why agent security becomes critical.

Example — AI Research Assistant

Consider:

Employee
   ↓
AI Research Assistant
   ↓
Web Search
   ↓
External Websites

The assistant only produces summaries.

Potential impact:

Incorrect information
Manipulated response
Misleading recommendation

Now add:

Email Tool

The assistant can send reports.

Impact increases.

Now add:

Cloud Administration Tool

Impact increases dramatically.

The attack class did not change.

The available capability changed.

Indirect Injection Attack Path

A professional security engineer should map the complete path.

Example:

Attacker
   ↓
Controls Website
   ↓
AI Agent Reads Website
   ↓
Malicious Content Enters Context
   ↓
Model Behavior Influenced
   ↓
Agent Selects Tool
   ↓
Tool Uses Enterprise Identity
   ↓
Enterprise Resource

This identifies where security controls should exist.

Attack Path Analysis

Break the path into stages:

Stage 1
Attacker Controls Content

Stage 2
Application Retrieves Content

Stage 3
Content Enters LLM Context

Stage 4
Model Behavior Changes

Stage 5
Agent Attempts Action

Stage 6
Security Control Allows or Blocks Action

Notice something important:

Even if stages 1–4 succeed, the attack does not necessarily need to succeed at stages 5–6.

That is where architecture can contain the risk.

Security Objective

The goal should not be:

Guarantee the LLM can never
interpret malicious instructions.

A stronger security objective is:

Even if untrusted content
influences the model,
security boundaries remain enforced.

This is a much more resilient design.

Defense 1 — Identify Untrusted Sources

First identify every source that can introduce content.

Create an inventory:

Source               Trust

User Prompt           Untrusted
Uploaded Document     Untrusted
External Website      Untrusted
External Email        Untrusted
Third-Party API       Depends
Internal Wiki         Controlled Data
System Prompt         Trusted Instruction

The exact classification depends on the organization.

The important point is to make trust explicit.

Defense 2 — Minimize Retrieved Content

Do not automatically send entire documents or websites to the model.

Prefer:

Source
  ↓
Relevant Content
  ↓
Minimum Required Context
  ↓
LLM

instead of:

Entire Data Source
      ↓
LLM

This reduces the amount of untrusted content reaching the model.

Defense 3 — Content Processing

Applications may preprocess retrieved content.

Possible controls include:

Content extraction
Sanitization
Metadata validation
Source validation
Content classification

These controls may reduce risk.

However:

Content filtering should not be treated as a perfect defense against indirect prompt injection.

Natural language can express the same intent in many forms.

Defense 4 — Preserve Source Provenance

The application should know where information came from.

For example:

Content:
Password policy information

Source:
security-policy.md

Owner:
Security Team

Classification:
Internal

Last Updated:
Approved Version

Source provenance helps applications and security teams understand trust.

Defense 5 — Separate Data From Instructions

The application should clearly structure retrieved content as reference data.

Conceptually:

Trusted Application Instruction
        ↓
"Use the following content
only as reference material."

        +

Untrusted Retrieved Content

This can improve model behavior.

But remember:

Prompt structure is not a complete security boundary.

Architecture controls remain necessary.

Defense 6 — Authorization-Aware RAG

RAG should enforce access before retrieval.

User
 ↓
Identity
 ↓
Authorization
 ↓
Allowed Collection
 ↓
Retriever
 ↓
LLM

This protects confidentiality even if prompt manipulation occurs.

Defense 7 — Control RAG Ingestion

Do not allow arbitrary content to enter enterprise RAG without governance.

A stronger ingestion pipeline:

Source
  ↓
Approved Source?
  ↓
Content Validation
  ↓
Classification
  ↓
Ownership
  ↓
Security Metadata
  ↓
Embedding
  ↓
Vector Database

This reduces poisoning opportunities.

Defense 8 — Tool Authorization

The LLM should not decide security policy.

Weak:

LLM
 ↓
"I should send this file."
 ↓
Email Tool

Stronger:

LLM
 ↓
Proposed Tool Call
 ↓
Authorization Layer
 ↓
Policy Check
 ↓
Allowed / Denied

Tool authorization should exist independently from model reasoning.

Defense 9 — Least Privilege

If an agent only needs:

Read Security Alerts

give it:

Read Security Alerts

not:

Security Administrator

If indirect prompt injection influences the model, least privilege limits the available damage.

Defense 10 — Tool Allowlisting

Agents should only have approved tools.

Example:

SOC Assistant
   │
   ├── Read SIEM Alerts
   ├── Search Runbooks
   └── Draft Incident Report

rather than:

SOC Assistant
   │
   ├── Shell
   ├── Cloud Admin
   ├── Email
   ├── Production Database
   └── File System

Capability minimization reduces attack surface.

Defense 11 — Human Approval

Sensitive actions may require approval.

AI Agent
   ↓
Proposed Action
   ↓
Human Review
   ↓
Approve?
  ├── No → Stop
  └── Yes
        ↓
     Execute

Useful for:

Production changes
Sending sensitive information
Deleting resources
Modifying IAM
Disabling users
Financial transactions

Defense 12 — Output Validation

Suppose malicious content influences an LLM to generate:

Command
SQL
URL
API Request

Do not automatically execute it.

Use:

LLM Output
    ↓
Validation
    ↓
Policy Enforcement
    ↓
Execution

The model output itself should cross another trust boundary.

Defense 13 — Limit External Communication

An AI agent may attempt to communicate with external systems.

Consider restricting:

Outbound Network Access
External URLs
Email Recipients
External APIs

according to business requirements.

This can reduce data-exfiltration opportunities.

Indirect Prompt Injection and Data Exfiltration

One concerning attack path is:

Malicious External Content
        ↓
LLM
        ↓
Model Has Access to Sensitive Data
        ↓
Agent Has External Communication
        ↓
Potential Data Exposure

The strongest controls may therefore be:

Data Authorization
+
Context Minimization
+
Restricted External Communication
+
Tool Authorization

rather than relying only on detecting malicious wording.

Defense 14 — Separate Read and Write Agents

Where practical:

Research Agent
      ↓
Read Only

and:

Action Workflow
      ↓
Separate Approval
      ↓
Write Capability

This reduces the ability of untrusted content to directly cause state changes.

Defense 15 — Sandbox Untrusted Content Processing

Where appropriate:

External Content
      ↓
Restricted Processing Environment
      ↓
Extracted Information
      ↓
AI Application

The sandbox may restrict:

Network access
File access
Credentials
Enterprise systems

This is especially useful when processing complex files or executing generated code.

Defense 16 — Monitor Agent Actions

Security monitoring should include:

User Identity
+
Content Source
+
Retrieved Document
+
Model Interaction
+
Tool Invocation
+
Authorization Decision
+
Action Result

This creates an investigation trail.

Detection Challenges

Indirect prompt injection can be difficult to detect because malicious instructions may look like ordinary language.

Simple keyword detection may miss:

Reworded instructions
Multiple languages
Encoded content
Context-dependent instructions

Detection should therefore combine:

Content Signals
+
Behavior Signals
+
Tool Activity
+
Authorization Events

Behavioral Detection

Instead of only asking:

Does this document contain
a suspicious phrase?

also ask:

Why is this summarization assistant
trying to send email?

This may be a stronger signal.

Example Detection

Expected behavior:

Document Assistant
      ↓
Read Document
      ↓
Generate Summary

Observed behavior:

Document Assistant
      ↓
Read Document
      ↓
Attempts External Tool

This deviation may warrant investigation.

Secure Agent Architecture

A strong design might look like:

User
 │
 ▼
Authenticated Application
 │
 ▼
AI Agent
 │
 ├── Untrusted Content
 │
 ▼
LLM
 │
 ▼
Proposed Action
 │
 ▼
Policy Enforcement
 │
 ▼
Authorization
 │
 ▼
Human Approval if Required
 │
 ▼
Restricted Tool

The model is surrounded by independent controls.

Enterprise Scenario — Email Assistant

Imagine an organization deploys:

Employee
   ↓
AI Email Assistant
   │
   ├── Read Email
   ├── Search Documents
   └── Draft Responses

External senders can control email content.

Therefore:

External Email
      =
Untrusted Input

Security Design

Email Content

Treat as untrusted.

Enterprise Documents

Enforce user authorization.

Drafting

Allow AI to create drafts.

Sending

Require user confirmation.

Architecture:

External Email
      ↓
LLM
      ↓
Draft Response
      ↓
Employee Review
      ↓
Send

This significantly reduces risk compared with:

External Email
      ↓
LLM
      ↓
Automatically Send

Enterprise Scenario — RAG Assistant

Consider:

Employee
   ↓
Enterprise AI
   ↓
RAG
   ↓
Internal Knowledge Base

Security requirements:

Only approved repositories are indexed.
Document ownership is tracked.
User permissions are preserved.
Sensitive collections are isolated.
RAG activity is logged.

This creates several independent security boundaries.

Enterprise Scenario — Cloud AI Agent

Consider:

Engineer
   ↓
AI Cloud Assistant
   ↓
Documentation Search
   ↓
External Website
   ↓
LLM
   ↓
Cloud Tool

This is high risk because:

External Content
      ↓
AI Reasoning
      ↓
Production Capability

A stronger architecture might use:

External Content
      ↓
AI Recommendation
      ↓
Engineer Review
      ↓
Existing Cloud Change Process

rather than allowing external content to indirectly influence autonomous production changes.

Persistent Injection Scenario

Imagine a user adds a malicious document to a shared knowledge base.

User
 ↓
Document Repository
 ↓
RAG Ingestion
 ↓
Vector Database

Later:

Employee A
 ↓
Question
 ↓
Malicious Document Retrieved

and later:

Employee B
 ↓
Question
 ↓
Same Document Retrieved

The attack may persist beyond the original interaction.

This demonstrates why:

RAG ingestion is part of the security boundary.

Safe Testing Methodology

Indirect prompt injection testing should only be performed in authorized environments.

Prefer:

Dedicated labs
Synthetic documents
Test websites
Test mailboxes
Non-production RAG collections
Restricted agent permissions

Step 1 — Map External Inputs

Identify:

Documents
Websites
Email
APIs
Databases
RAG Sources
Tool Results

Step 2 — Determine Content Ownership

For each source ask:

Who can modify this?

Can external users influence it?

Can internal users modify it?

Is content reviewed before ingestion?

Step 3 — Map Data Flow

Example:

External Website
      ↓
Browser Tool
      ↓
Content Extraction
      ↓
LLM
      ↓
Agent

Step 4 — Identify Security Boundaries

Determine what retrieved content should never be able to influence.

Example:

Website Content
      ↓
May Influence Summary

Website Content
      ↓
Must Not Authorize Cloud Changes

Step 5 — Use Synthetic Test Content

Create controlled test content that attempts to influence the AI application’s expected task.

Do not use:

Real credentials
Real confidential information
Destructive production actions

Step 6 — Observe Model Behavior

Determine whether the external content:

Changes the expected task
Influences retrieval
Influences tool selection
Influences output
Persists across interactions

Step 7 — Validate Security Impact

Ask:

Was sensitive data exposed?

Was authorization bypassed?

Was a tool invoked?

Could external communication occur?

Could an enterprise resource be modified?

Behavioral deviation alone does not automatically determine severity.

Step 8 — Review Compensating Controls

Even if model behavior changes, determine whether:

Authorization blocked access

Tool policy blocked action

Least privilege limited capability

Human approval prevented execution

These controls significantly affect risk.

Step 9 — Document the Finding

A professional finding should explain the complete attack path.

Example Finding

Finding:
Indirect Prompt Injection Through Retrieved Documents

Affected Component:
Enterprise RAG Assistant

Attack Source:
User-controlled knowledge-base document

Attack Path:
Document
→ RAG Retrieval
→ LLM Context
→ Model Behavior

Observed Behavior:
Instructions contained in retrieved content influenced
the model beyond the intended document-processing task.

Potential Impact:
Depending on connected capabilities, malicious content
could influence responses or downstream agent actions.

Root Cause:
Retrieved content is processed by the LLM without
sufficient separation between reference data and instructions.

Recommendations:
- Restrict RAG ingestion sources.
- Preserve source provenance.
- Enforce authorization-aware retrieval.
- Minimize retrieved context.
- Restrict agent tools and permissions.
- Apply independent authorization to sensitive actions.
- Monitor unusual tool behavior.

Indirect Prompt Injection Assessment Checklist

External Sources

External content sources identified.
Source ownership documented.
User-controlled content identified.
Third-party content identified.

Documents

Uploaded files treated as untrusted.
Content processing occurs safely.
Document provenance is tracked.

Web

External websites treated as untrusted.
Browser tools have restricted permissions.
External communication is controlled.

Email

Email content treated as untrusted.
External senders cannot directly trigger privileged actions.
Sensitive actions require confirmation.

RAG

Ingestion sources are controlled.
Authorization is preserved.
Document ownership is known.
Poisoned content can be removed.
Indexes can be rebuilt.

Agents

Agent tools are allowlisted.
Tool permissions follow least privilege.
Security policy exists outside the LLM.
High-risk actions require approval.

Monitoring

Content source can be identified.
Retrieval activity is logged.
Tool invocation is logged.
Policy denials are visible.
Suspicious behavior can be investigated.

Common Beginner Mistakes

Mistake 1 — Only Testing the Chat Box

Indirect attacks may arrive through documents, websites, email and APIs.

Mistake 2 — Trusting Internal Documents Automatically

Internal repositories may still contain user-controlled or compromised content.

Mistake 3 — Trying to Solve Everything With Content Filtering

Natural language is difficult to perfectly classify.

Mistake 4 — Ignoring RAG Ingestion

Security starts before documents enter the vector database.

Mistake 5 — Giving Browsing Agents Powerful Tools

Untrusted internet content should not easily influence privileged enterprise actions.

Mistake 6 — Ignoring Tool Output

Tool responses can themselves contain attacker-controlled information.

Mistake 7 — Ignoring Persistence

Poisoned RAG content may affect multiple future users.

Mistake 8 — Treating Every Model Deviation as Critical

Actual severity depends on available data, tools, permissions and business impact.

Mistake 9 — Relying on the LLM to Authorize Actions

Authorization should exist independently of model reasoning.

Mistake 10 — Forgetting Recovery

Organizations should be able to remove poisoned content and rebuild affected indexes.

AI Security Engineer Perspective

When reviewing an AI application, do not only ask:

What can the user type?

Ask:

What can the AI read?

Who controls that information?

Can websites influence it?

Can documents influence it?

Can email influence it?

Can RAG influence it?

Can tool responses influence it?

What happens if the model follows
instructions from those sources?

What data could become accessible?

What tools could be invoked?

What independent controls prevent impact?

This is the mindset required for enterprise AI security.

Interview Perspective

You may be asked:

What is Indirect Prompt Injection?

A strong answer is:

Indirect Prompt Injection occurs when attacker-controlled instructions reach an LLM through external content such as documents, websites, emails, RAG sources, API responses or tool output rather than through a direct user prompt. The model may interpret the malicious content as instructions and alter its behavior.

Another question may be:

Why is Indirect Prompt Injection particularly dangerous for AI agents?

A strong answer is:

Agents consume external information and may also have access to tools. If malicious content influences the model’s reasoning or tool selection, the attack can potentially move from manipulating generated text to influencing real actions. Least privilege, independent tool authorization and approval controls are therefore critical.

Another question may be:

How would you protect a RAG system from Indirect Prompt Injection?

A strong answer is:

I would control document ingestion, preserve source provenance, enforce authorization-aware retrieval, minimize retrieved context, treat retrieved documents as untrusted data rather than instructions, restrict downstream agent capabilities and monitor retrieval and tool activity.

Another question may be:

Can Indirect Prompt Injection be completely solved by filtering malicious instructions from documents?

A strong answer is:

Filtering can reduce risk but should not be considered a complete security boundary because natural language instructions can be expressed in many ways. The architecture should assume some malicious content may reach the model and use authorization, least privilege, tool restrictions, output validation and approval controls to contain the impact.

Key Takeaways

Direct Prompt Injection looks like:

Attacker
   ↓
Prompt
   ↓
LLM

Indirect Prompt Injection looks like:

Attacker
   ↓
External Content
   ↓
AI Retrieves Content
   ↓
LLM

Potential sources include:

Documents
+
Websites
+
Email
+
RAG
+
APIs
+
Databases
+
Source Code
+
Tool Results

The risk becomes much greater when combined with:

Sensitive Data
+
AI Agents
+
Powerful Tools
+
Excessive Permissions
+
Autonomous Actions

The strongest security strategy is not simply:

Detect Every Malicious Instruction

It is:

Treat External Content as Untrusted
        ↓
Control What Reaches the Model
        ↓
Preserve Authorization
        ↓
Restrict Agent Capabilities
        ↓
Enforce Tool Policy
        ↓
Require Approval Where Needed
        ↓
Monitor Actions

Most importantly:

The AI may need to read untrusted content, but untrusted content should never automatically gain authority over enterprise systems.

What’s Next?

➡️ 04 — Jailbreaking and Safety Bypass

You now understand two major prompt-based attack paths:

Direct Prompt Injection
        +
Indirect Prompt Injection

Next, we will examine Jailbreaking and Safety Bypass.

You will learn:

What AI jailbreaking means
Jailbreaking vs prompt injection
Model safety controls
Common jailbreak concepts
Role and context manipulation
Obfuscation
Multi-turn attacks
Model behavior testing
Why successful jailbreaks do not always represent enterprise compromise
Security vs AI safety
Risk assessment
Defense-in-depth strategies
Safe and authorized testing methodology

You will move from:

Can Untrusted Instructions
Influence the Application?

to:

Can Adversarial Inputs
Bypass Intended Model
Behavior and Safety Controls?

➡️ Next: 04 — Jailbreaking and Safety Bypass