Overview

​

What Is IPI?

Indirect Prompt Injection (IPI) is a research library that lets you test whether AI systems are vulnerable to hidden instructions embedded in external documents. You create adversarial documents, deploy them to a target system, and track execution via HTTP callbacks — proof that the hidden payload actually ran. IPI is the surface where documents may be uploaded to third-party AI services. This requires explicit authorization.

​

How It Works

1. Start the callback listener — Run python -m q_ai.ipi listen on a host you control. This opens an HTTP endpoint that receives proof-of-execution callbacks. The listener can also run with --tunnel cloudflare to receive callbacks from cloud / remote targets — see Remote callbacks via Cloudflare Tunnel.
2. Generate poisoned documents — Use python -m q_ai.ipi generate to create documents with hidden payloads using your choice of format (PDF, Word, Markdown, etc.) and hiding technique (white ink text, metadata, comments, etc.).
3. Deploy to target — Upload the poisoned document to the target system’s document ingestion pipeline (knowledge base, RAG system, email service, calendar app, etc.).
4. Trigger payload execution — Send a prompt that causes the target to ingest and process your document.
5. Verify execution — Monitor your callback listener for HTTP requests. A callback confirms the target executed your hidden payload.

​

What to Expect

IPI is a research harness, not an automated exploit tool. The tool generates poisoned documents and proves execution when it happens, but the researcher does the hard part: figuring out which combination of format, technique, style, and trigger prompt will cause a specific target to execute. This is inherent to indirect prompt injection — every target model, system prompt, and ingestion pipeline changes the attack surface. Expect to iterate across multiple attempts.

​

What You Can Test

IPI supports 7 document formats and 3+ techniques per format:

• PDF — Two phases of techniques: white ink, metadata, form fields, JavaScript, etc.
• DOCX (Word) — Hidden text, comments, metadata, headers/footers
• Markdown — HTML comments, zero-width Unicode, hidden blocks
• HTML — Meta tags, data attributes, CSS positioning tricks
• Image (PNG/JPG) — Visible/subtle text overlays, EXIF metadata
• ICS (Calendar) — Event descriptions, alarms, custom properties
• EML (Email) — Headers, hidden HTML, attachments

Each technique hides your payload in a different way, making it harder to detect by automated scanning tools.

​

Payload Styles and Types

You control how the payload is presented and what it does: Payload Styles (how it blends into the document):

• Obvious — Direct injection markers for baseline testing
• Citation — Disguised as a document reference
• Reviewer — Appears as a note to an editor
• Helpful — Framed as helpful supplementary content
• Academic — Academic cross-reference format
• Compliance — Looks like a verification requirement
• Datasource — Appears as data source attribution

Payload Types (attack objectives):

• callback — Proof of execution (safe, default)
• exfil_summary — Attempts to extract document summary
• exfil_context — Attempts to extract conversation context
• ssrf_internal — Server-side request forgery to internal endpoints
• instruction_override — Attempts to override system instructions
• tool_abuse — Attempts to misuse agent tools
• persistence — Attempts to persist instructions across sessions

Non-callback types require the --dangerous flag and are intended for authorized security testing only.

​

Callback Tracking

The callback listener records incoming HTTP requests and assigns a confidence level to each:

• HIGH — Valid campaign token present in the callback URL. Strong proof that the specific poisoned document was executed.
• MEDIUM — No token, but User-Agent indicates a programmatic HTTP client (python-requests, httpx, curl, etc.). Likely automated execution.
• LOW — No token and browser/scanner User-Agent. May be incidental traffic or scanner noise, not definitive proof.

All hits are stored in the database and accessible via python -m q_ai.ipi status.

​

Retrieval pre-validation (removed)

Phase 1 removed the RXP module and the RXP→IPI retrieval gating path. IPI generation runs without retrieval pre-validation. Historical docs that referred to an RXP pipeline no longer apply.

​

Safety and Authorization

Non-callback payload types (exfil, SSRF, instruction override, etc.) require the --dangerous flag. This is a safety gate to ensure you’re intentionally running a high-risk test. The callback listener returns a spoofed HTTP 404 response to avoid alerting the target system that the payload was detected.

​

Key Components

• Library CLI (python -m q_ai.ipi) — Generate payloads, manage campaigns, monitor hits
• Callback Server — FastAPI listener that receives and logs execution confirmations
• Database — Stores campaigns, hits, and campaign metadata
• Guidance Builder — Generates deployment workflows and trigger prompts tailored to your format and target platform

​

Next Steps

• CLI Reference — Library CLI commands and options (python -m q_ai.ipi)
• Techniques — Detailed breakdown of all hiding techniques by format
• Formats — Implementation status and format-specific capabilities
• Templates — Document context templates that frame payloads in realistic content
• Payloads — Payload styles, types, and the --dangerous safety gate
• Callbacks — Listener setup, hit tracking, and confidence scoring
• Deployment Playbook — Guided workflow for poisoning and monitoring