The Attack Surface Map

Lesson 3 of 3 in The Single-Channel Problem.

If every token in the stream has equal standing, then your attack surface is simple to state: every place where text you did not write can enter the stream. Walk the entry points one by one — for each, what enters, and why it is untrusted.

  • User input. The obvious channel and the only one users know they are using. Untrusted because the person typing may be an attacker — or a well-meaning user pasting text they did not read, which smuggles someone else’s words in under their identity.
  • Retrieved documents. RAG pulls from a corpus written by many hands over years — wikis, tickets, emails, PDFs. Untrusted because Retrieval selects by similarity, not by trust: whatever ranks as relevant gets read, whoever wrote it.
  • Web content. Search Grounding and browsing fetch pages controlled by their publishers. Untrusted by definition — any page author on the internet can write text your model will read, and pages can serve different content to crawlers than to humans.
  • File uploads. Document processing ingests whatever the uploader chose — including text invisible to the human who forwarded the file: white-on-white writing, metadata fields, comments, embedded content in images. The person uploading is often not the person who authored what the model reads.
  • Inter-model messages. In pipelines where one model’s output becomes another’s input, upstream output is downstream input text. Untrusted because the upstream model may already have been steered by any of the entry points above — injection composes across hops.

Greshake et al. (2023) gave the pattern its name: Indirect prompt injection — the attacker never touches your application, they plant instructions where your application will fetch them. Once you see the map, the insight is that indirection is the norm, not the exotic case: most of the text a modern LLM system reads was written by someone who never sent you a request.

Where untrusted text enters the token stream

  1. User input

    Typed or pasted by the user — who may be hostile, or an unwitting courier for someone else’s text.

  2. Retrieved documents

    Corpus content selected by semantic similarity. The retriever has no notion of authorial trust.

  3. Live web content

    Pages controlled by their publishers, fetched by grounding or browsing features.

  4. File uploads

    PDFs, office documents, images with extractable text — including text the uploader cannot see.

  5. Messages from other models

    Upstream model output — which may already carry the influence of an injection one hop earlier.

  6. Prompt assembly

    Application code concatenates all of it with the system prompt and chat template.

  7. One token stream

    Provenance is gone. Every span now has equal standing.

  8. Model

    Reads everything; trained dispositions are the only thing distinguishing instructions from data.

  9. Model output

    When output drives tools and actions, a second surface opens — the agent surface, covered by the sister AI Agent Academy.

In production

Every managed cloud feature that feeds external content into a prompt — managed RAG, web grounding, document processing — inherits the single channel by construction. The platforms ship real classifiers around the channel; none of them changes what the channel is, so the remaining mitigation surfaces are app-level and evergreen: treat fetched text as untrusted, and mediate what output may cause.

AWS

Amazon Bedrock Knowledge Bases is the managed-RAG surface: at query time it retrieves from connected sources (documented connectors include Amazon S3, SharePoint, Confluence, Google Drive, OneDrive, and a web crawler) and grounds the response on them — every connector is an authorship surface feeding the stream. Around the channel, Bedrock Guardrails evaluates inputs and responses; its documented content-filter categories include a Prompt Attack filter, alongside denied topics, sensitive-information filters, and contextual grounding checks. Those are classifiers judging text in the channel — apply them, and still handle retrieved content as untrusted in your own code.

Azure

Azure AI Foundry model serving runs prompts and completions through a built-in content filtering system powered by Azure AI Content Safety, with optional Prompt Shields that the docs split into user prompt attacks and indirect prompt-injection attacks — the platform itself naming both directions of the single-channel problem. Its grounding features ingest your files into an Azure AI Search index and feed retrieved chunks into the prompt at inference, which is exactly the retrieved-documents entry point on the map. Filters block or annotate; what a grounded answer is permitted to trigger downstream remains your application’s decision.

Google Cloud

Vertex AI’s grounding options — Grounding with Google Search, RAG Engine over ingested corpora (sources documented include local files, Cloud Storage, and Google Drive) — feed publisher- and author-controlled text straight into the stream. Configurable safety filters score prompts and responses against harm categories, and the documentation is unusually candid about the architecture: filters act as a barrier rather than changing the model, with system instructions for safety offered as the way to steer model behavior itself. That is this module’s taxonomy in vendor prose — dispositions inside the channel, classifiers around it, and app-level mediation left to you.

Key terms: Prompt injection, Indirect prompt injection, Instruction hierarchy, Adversarial suffix, System prompt, Chat template

Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.