Guided security lab

Email Prompt Injection

A guided mailbox trust exercise: separate message content from connector, sender and transport facts, decide which fact the application may rely on, then apply capability and recipient policy to a model proposal.

Conceptual simulationIntermediate15 minutes2026-09-26

Conceptual simulation

This exercise uses authored, deterministic examples with fictional addresses. It connects to no mailbox, calls no model or tools and does not predict how any real model behaves.

Step 3 of 63/6

Learning objectives

Explain why a trusted mailbox connector does not make message body content trusted.
Treat sender, authentication and transport metadata as origin evidence, not as instruction authority over the AI workflow.
Keep the provenance of quoted and forwarded content separate from the message that carries it.
Distinguish drafting from sending as separate capabilities.
Use recipient validation, mailbox scope, authorization and human approval to constrain impact.

Prerequisites

Trust Boundaries and Model Context lab (recommended)
Email Prompt Injection attack article (optional)

Choose a scenario

Each fictional scenario shows message content the model sees and connector, sender and policy facts the application recorded separately. Security decisions belong to the second column.

Unknown external sender asks for a fileA message from an unfamiliar external address asks the assistant to share a project file.Forwarded thread with quoted third-party textA colleague forwards a thread; the quoted part was written by an outside vendor.Authenticated connector, message written by someone elseThe mailbox connector authenticates correctly and returns a message that passed domain authentication.Drafting assistant versus sending assistantThe user asks for help replying to a customer. The workflow may draft but not send.Message asks for unrelated mailbox data to go outsideAn inbound message asks the assistant to collect recent invoices from the mailbox and send them to an external address.

Mail path and trust flow

Messages pass through transport and connector components before the model sees them. Components are system; message content and the model's proposal stay variable.

Inbound messageVariable content->
Mail connectorSystem component->
Context assemblySystem component->
ModelSystem component->
ProposalVariable content->
AuthorizationSystem component

Model-visible message content

Message text the model reads. Bracketed text is a neutral placeholder, not a real instruction.

Message body
Hello, please attach the latest project plan in your reply. [synthetic instruction-like text attempting to redirect the assistant]

Application-side evidence and policy

Recorded by the connector, transport and application outside model text. Origin facts are evidence about where mail came from, not permission.

Sender domain: partner.example.test, external, no prior correspondence
User task: Triage the inbox and summarize new messages
Sharing policy: Files leave the organization only with the file owner's decision