Attack surface
Mapping where an AI system can be attacked: every input channel, every tool, every trust boundary — and the security engineer's habit of thinking in adversaries.
To defend a system you must first see it as an attacker does — as a collection of entry points and trust boundaries, each a place where something untrusted meets something powerful. This lesson is the shift from builder's eyes to attacker's eyes, the core habit of the discipline.
Every input is an attack channel
The builder sees inputs as sources of information; the attacker sees them as injection points. In the Harbor Lane AI, list them all — and notice how many are attacker-controlled:
- The direct user message — the obvious one: a customer typing into the chat. Attacker-controlled, always.
- Retrieved documents (RAG) — a help-center article, a product review, a support-ticket history the agent reads. If any of that content can be influenced by an outsider (a product review! a submitted ticket!), it's an injection channel that arrives inside trusted-looking context. This is the one builders forget.
- Tool results — an order record, an API response, a database row. A
customer_notefield the customer wrote is untrusted text the agent reads as it works (you met this in Agentic AI). - Memory / conversation history — earlier turns, possibly poisoned, replayed into later ones.
- Uploaded files, images, linked pages — anything the system ingests. Each format is a channel; images and PDFs can carry hidden text.
Trust boundaries: where the damage is decided
An input channel is only dangerous where it crosses into power. Map the boundaries: user text → the model (can it change behavior?); model output → your code (do you execute/render/trust it?); model decision → a tool (can it take an action?); tool → a real system (with what privileges?). The severity of any vulnerability is set at the boundary: injection into a read-only chatbot is embarrassing; injection into an agent that can issue_refund is money. Attack surface × privilege = blast radius.
Here is a description of my AI system: [describe yours — inputs, what the model can do, what tools/data it touches]. Think like an attacker. Enumerate every input channel including the non-obvious ones (retrieved content, tool results, memory), and for each, what an attacker could attempt. Then rank the trust boundaries by blast radius: where would a successful attack cause the most damage?
Getting a model to red-team your own architecture is a legitimate first pass — it's fast and thorough on the obvious surface. It won't replace the adversarial creativity of Module 5, but it's an excellent way to stop thinking like the builder.
Teams defend the direct user message and forget that a RAG system will dutifully retrieve and a model will dutifully read an attacker's payload planted in a product review, a public webpage, or a submitted ticket — content that looks trusted because it came from 'our own documents'. Indirect injection through retrieved or tool-supplied content is the attack that gets past teams who only guarded the front door.