AI & Agent Application Security
The attack surface LLM and agent systems add: the instruction/data boundary and prompt injection, data leakage and tenant isolation, tool-permission boundaries and sandboxing — taught as detection and defence.
An LLM application does something no previous system did: it takes text from an untrusted source — a web page, a support ticket, a PDF a user uploaded — and feeds it to a component that cannot reliably tell the difference between information and orders. Give that component tools, and a sentence buried in a retrieved document becomes a request to your API, made with your agent's credentials. This domain is about that boundary, and about the fact that no amount of prompt wording closes it.
The defence is structural rather than linguistic, and this domain builds it in three moves. First, the instruction channel: keep what you wrote separate from what arrived, quarantine retrieved content so it is clearly data, and separate privilege in the way the prompt is assembled — plus the leakage question of what travels outward, from PII in a log to a system prompt exfiltrated on request to one tenant's documents surfacing in another's answer. Second, the tool boundary, which is the load-bearing idea of the whole pillar: the model proposes, your code decides. A least-privilege toolset, a human in the loop for anything irreversible, and a sandbox as the isolation floor for code you did not write. Third, the whole system at once — STRIDE adapted to LLM and agent architectures, walking assets, trust boundaries and abuse cases into a threat model you produce yourself in the capstone. Every technique here is taught so you can defend a system you are responsible for.