Prompt-Injection.net
ENDE

Learning Paths

Indirect Prompt Injection

Follow external content from websites, email and documents into model context, then see how provenance, inspection, detection and authorization limit what that content can cause.

Audience
Developers integrating external content, security reviewers, red teamers
Approximate time
About 2 to 3 hours
Prerequisites
Foundations path or equivalent understanding of trust boundaries

Learning objectives

  • Trace how external content becomes model-visible
  • Compare website, email and document delivery channels
  • Explain what provenance, inspection and detection can and cannot establish
  • Read a real case with its evidence classification intact

Path sequence

01 Refresher and overview

  1. 01 - LearnTrust Boundaries and Model Context

    Explains how context is assembled and why controls sit outside the model.

  2. 02 - AttackIndirect Prompt Injection

    The pillar article that maps all indirect delivery channels.

02 Delivery channels

  1. 03 - AttackWebsite Prompt Injection

    Web content as untrusted context for browsing and summarizing assistants.

  2. 04 - Lab - Controlled simulationWebsite Prompt Injection (Lab)

    Apply the website trust path in a controlled simulation.

  3. 05 - AttackEmail Prompt Injection

    Inbound email as attacker-reachable content in mailbox assistants.

  4. 06 - Lab - Controlled simulationEmail Prompt Injection (Lab)

    Reason about sender, content and action scope in a controlled simulation.

  5. 07 - AttackDocument Prompt Injection

    Shared and uploaded documents as a context source.

  6. 08 - Lab - Controlled simulationDocument / PDF Prompt Injection (Lab)

    Separate extracted content from its trust level in a controlled simulation.

03 Defenses

  1. 09 - DefenseData Provenance

    Tracks where content came from so later decisions can use origin as evidence.

  2. 10 - DefenseInput / Content Inspection

    Inspection produces probabilistic evidence, not authorization.

  3. 11 - DefensePrompt Injection Detection

    Detection findings are signals to act on, not proof of compromise or a permission decision.

04 Evidence case

  1. 12 - Incident - Read with its evidence classificationEchoLeak - Microsoft 365 Copilot

    A disclosed vulnerability (CVE-2025-32711) involving email as indirect input; the record lists no known in-the-wild exploitation.

Go deeper (optional)

Knowledge check

Think through each question, then open it to compare with the expected reasoning. There is no score.

An email is from a known colleague. Does that make its text safe as model instructions?

No. Sender identity is provenance evidence, not authority to instruct the assistant. The content remains data for the task.

A detector flags instruction-like text in a document. What does that establish?

A signal worth preserving and acting on. It does not prove compromise, and a missed detection does not prove safety.

Why read EchoLeak as a disclosed vulnerability rather than a breach?

The record documents a reported and remediated issue with no known in-the-wild exploitation. Evidence classification should not be upgraded without evidence.

After this path, you should be able to...

  • Trace an external source into model context
  • Explain why source identity is not instruction authority
  • Place provenance, inspection and detection correctly as evidence
  • Describe a real case without overstating its evidence