The agent attack surface

A chatbot that says something wrong is embarrassing. An agent that does something wrong has tools, so it can leak data, spend money, delete records, or email a stranger — the failure has hands. Security for agents is the study of that difference, and it starts with one idea that explains most of the attacks in this course.

The idea is a trust boundary. There is exactly one source of instructions the operator controls end to end: the system prompt. Everything else the model reads — the user's message, a document it retrieves, the output of a tool, another tenant's data — arrives from outside that boundary. It can be read, but it must never be obeyed.

Almost every attack in the next eight lessons is the same move: get instructions to cross that boundary while dressed as data. Prompt injection is untrusted text the model treats as a command. Exfiltration is a secret that was inside the boundary escaping through a channel. Tenant leakage is one customer's data reachable from another's session. Name the boundary and the attacks stop looking like a grab-bag and start looking like one failure with variations.

The risks themselves are not exotic. Agents are software on top of language models, so they inherit ordinary vulnerabilities — injection, broken access control, secret mishandling — and the LLM-specific ones. What changes is the blast radius: the same class of bug that leaked a string from a web form now leaks it through an agent that also had a database credential and an email tool.

In the lab, you classify what reaches the agent before a model does: which inputs are trusted instructions, which are untrusted data, and which are secrets that should never be in the context at all. Getting these three categories right is most of the discipline; the rest is enforcing them.