The Five Doors

Door one: the prompt

The message you send. The obvious one, the one every article is about, and the one where the tooling market concentrates.

It leaks for the reason Chapter 1 gave: whole objects are convenient. A Ticket becomes a JSON blob, a Candidate becomes the raw CV text, a conversation history accumulates everything anyone said over forty turns and sends all of it, every turn, forever.

Prompt leakage has one property that makes it the easiest door to close: it is synchronous, single-shot, and entirely within your control. You construct the string. Nothing happens between your code and the network that you did not write. Chapter 12 closes it with a field projection, which is the cheapest control in the book, and Chapter 13 enforces it at a chokepoint so that the next developer cannot reopen it.

It is also the door where the least data usually sits, which is worth saying out loud. One prompt is one record. That is a small blast radius compared to what follows.

Door two: ingestion

Everything you loaded in advance. RAG corpora, embedded documents, uploaded files, fine-tuning sets.

This door is different in kind. Door one sends one record at a time, in response to a user action, and forgets it. Ingestion takes your whole support history, your whole document library, or your whole case file archive, and copies it into a new store that was built for retrieval speed and not for access control.

Three properties make ingestion the highest blast radius door in most applications.

It is bulk. You did not send one customer. You sent the corpus.

It is persistent. A prompt under a zero-retention agreement is gone. A vector index is a database. It gets backed up, replicated, snapshotted into staging, and copied onto a laptop by someone who needed realistic data.

And embeddings are not a safe representation. This is the part that surprises people. A vector looks like noise to a human, so it feels anonymised. It is not. Embedding inversion attacks recover 50% to 70% of the original input words from compromised vectors, and reconstruction reaches near-optimal accuracy with as few as a thousand samples against black-box encoders. OWASP lists vector and embedding weaknesses as a category in its own right: LLM08:2025, renumbered LLM09:2026 in the current edition. If your vector store contains customer text, it contains customer text, and encoding it did not change that.

Chapter 15 handles this door.

Door three: the tool call

The arguments your agent passes outward.

An agent takes a user's question, decides it needs the customer record, calls GetCustomer(id), receives a full record, and puts that record into its context so it can answer. Now the record is in the prompt for every subsequent turn. Then the agent decides it should file a ticket, and calls CreateTicket(summary) where summary is a paragraph it wrote containing everything it learned.

Nobody wrote that paragraph. The model composed it, and its contents are not predictable in advance, which is what makes this door structurally different from door one. With a prompt, you control the string. With a tool call, the model controls the string, and your only leverage is what you allow it to call and what you allow the result to reach.

This gets worse when the tool has an outward-facing side effect. A tool that sends an email, posts a webhook, writes to a shared document, or performs a search against a third-party API is an exfiltration path that runs at machine speed and leaves no trace in your prompt logs, because the data left through the tool rather than the completion.

The research literature is direct about this. Simple prompt injection has been shown to leak personal data that agents observed during ordinary task execution, and backdoored tool use is a demonstrated exfiltration technique. The defence is not better prompting. It is capability design: limiting what an agent can do so that a successful injection has a small blast radius. Chapter 15 again.

Door four: the log

Your own telemetry. Application logs, traces, error reports, the analytics event you fire so product can count usage.

This is the widest door in most organisations, and it is guarded least, for a specific and slightly embarrassing reason: the log is not where anyone is looking for a privacy problem. Logs are an operations concern. They live in a different tool, owned by a different team, with retention set by whoever configured the platform three years ago.

Consider what your LLM integration is logging right now. Almost certainly the request and response bodies, because when a model gives a strange answer the first thing anyone wants is the exact prompt. That means your log store holds a verbatim copy of every piece of personal data that went to the model, retained for however long the platform default is, searchable by everyone with access to the dashboard, replicated wherever the vendor replicates.

The detector makes this sharper rather than better. A PII detection service sees, by definition, 100% of your personal data. Turn on its request logging and you have built a single, indexed, centralised store of exactly the thing you were trying to protect. Chapter 14 treats this as a first-class design constraint.

Door four is also where provider-side retention lives: what the model vendor keeps, for how long, and who can look at it. That is a contract question rather than a code question, and Chapter 16 covers both halves.

Door five: the output

What the model emits, and where that lands.

The output door has three distinct failure modes, and they are worth separating.

Regurgitation. The model returns personal data it was given, to a user who should not see it. A support agent asks for a summary of similar past cases and gets another customer's details, because retrieval pulled them in and nothing checked the answer before rendering.

Inference. The model states something about a person that was not in the input. A summary that concludes a customer is in financial difficulty is an inference about an identified person, which is personal data, generated by you.

Rendered exfiltration. The most technically interesting, and the one most teams have never considered. The model's output is not just text. It is text you render. If your client renders markdown, an output containing an image tag causes the browser to fetch a URL, and the attacker chose the URL. Put data in the query string and it leaves silently. The user sees a small broken thumbnail, if they see anything.

This is not theoretical. EchoLeak, CVE-2025-32711, was zero-click data exfiltration from Microsoft 365 Copilot: a crafted email, reference-style markdown that slipped past link redaction, and auto-fetched images that carried the data out. No click, no dialogue, no user error. Disclosed by Aim Security in June 2025 and rated CVSS 9.3, it was patched server-side by Microsoft that month, with no exploitation observed in the wild. Cite it as a demonstrated technique rather than a live exposure: the pattern outlived the specific bug.

Chapter 13 filters this door in the gateway, in the same place and the same way as door one, which is the argument for having a gateway at all.

Which door to close first

Not the one you are thinking of.

Two things fall out of that table.

The prompt is the most-guarded door and neither the widest nor the most persistent. That is not an argument for ignoring it, since it is cheap to close and it is where the sensitive text originates. It is an argument against stopping there.

The log is low effort and almost never done. If you read one chapter of this book after this one, make it Chapter 16. Turning off request-body logging and redacting at the sink is an afternoon of work that closes the exit holding the largest volume of personal data in most companies.

There is a sixth path worth naming and dismissing, because it comes up in every security review. Training-data memorisation: models can be induced to emit verbatim training data, including personal data. One study collected thousands of email addresses, phone numbers and URLs this way, and combining attack techniques roughly doubles extraction rates. That is a real risk and it is a training-time risk, which makes it someone else's threat model unless you are fine-tuning on customer data. For you, it reduces to a contract term: confirm the provider does not train on your API traffic, and Chapter 16 tells you how to check rather than assume.

Start with door one, because everyone does and because the tooling promises the most there. That promise is where Part II begins, and it does not survive contact with the evidence.

Sources for this chapter

• Embedding inversion recovers 50–70% of original input words; near-optimal reconstruction from ~1,000 samples — Transferable Embedding Inversion Attack, arXiv 2406.10280: https://arxiv.org/pdf/2406.10280 · summary: https://www.promptfoo.dev/lm-security-db/vuln/embedding-inversion-privacy-leak-bd566a31/
• OWASP 2026 top ten for LLM applications lists vector and embedding weaknesses — https://genai.owasp.org/ · Numbered LLM08 in the 2025 edition and LLM09 in the 2026 edition; the book gives both.
• EchoLeak, CVE-2025-32711: zero-click exfiltration from M365 Copilot via markdown images. Disclosed by Aim Security June 2025, CVSS 9.3, patched server-side by Microsoft in the June 2025 update, no exploitation in the wild — peer-reviewed write-up: EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System, arXiv 2509.10540: https://arxiv.org/abs/2509.10540 · narrative account: https://wraith.sh/learn/markdown-image-exfiltration
• Training-data extraction yielding thousands of emails, phone numbers and URLs; combining attacks roughly doubles extraction risk — arXiv 2409.12367: https://arxiv.org/pdf/2409.12367 · TACL: https://direct.mit.edu/tacl/article/doi/10.1162/TACL.a.62/134536/
• Agent tool-call leakage — arXiv 2506.01055: https://arxiv.org/pdf/2506.01055

The five-door taxonomy is the author's framing, as is the table ranking doors by volume and effort. The claim that the log is the widest and least-guarded door is an assertion from practice, not a measured result.