Mapping your app's attack surface

Why this matters

You cannot defend an attack surface you haven't drawn. Every LLM application has a handful of trust boundaries where untrusted content crosses into the model's context or where the model's output crosses back into the rest of your system, and beginners consistently miss the ones that aren't the obvious 'chat box.' Retrieved documents, tool call results, uploaded files, other agents' messages, and even fine-tuning data are all injection surfaces just as real as the user's typed prompt — and each one needs its own answer to 'who controls this content, and do we trust them?' Drawing this map before you write a single guardrail is what turns security work from reactive patching into a systematic audit you can actually finish.

Demo

The demo models a RAG support-agent's boundaries as a small graph: each surface, who controls the content that flows through it, and whether it's trusted by default. Untrusted surfaces are exactly the places later modules will attack and defend.

Try it yourself

1. Run it and count how many surfaces you would have listed before reading this task -- most people list one.
2. Add a code_execution_output surface for an agent that runs a sandboxed interpreter, and decide whether it should default to trusted or untrusted.
3. For your own current or hypothetical LLM app, write your own SURFACES list with at least five entries.
4. Add a reaches field to Surface (e.g. 'model context', 'downstream renderer', 'shell') and group surfaces by where they ultimately land.

References

• OWASP — LLM Top 10 (2025)
• Greshake et al. — Not what you've signed up for (indirect prompt injection)