Phase 4: RAG & Agent Security · 5-7 hours · Python · MITRE ATLAS · OWASP GenAI Security Project

Project: Agent Security Audit

A security review that doesn't produce a re-test with before/after evidence is an opinion, not an audit.

Hiring signal: Being able to hand an interviewer a severity-ranked audit of a multi-agent RAG + MCP system — with a threat model, reproducible findings, implemented fixes, and re-test evidence rather than a bullet-point list of concerns — is exactly the work sample AI security engineer and red team roles ask for, and almost no candidate arrives with one already built.

What you will learn

Build a threat model that identifies every trust boundary in a multi-agent + RAG + MCP system
Consolidate the RAG poisoning, tenant isolation, tool escalation, multi-agent/memory, and MCP checks from lessons 1-5 into a single auditor
Produce a severity-ranked, reproducible vulnerability report from automated findings
Implement fixes for the highest-severity findings and generate concrete before/after re-test evidence

The Problem

Every lesson so far in this phase tested one layer in isolation: poison a RAG store, break tenant isolation, chain a tool-privilege escalation, hijack a planner, poison shared memory, review an MCP manifest. That's how you learn each attack class, but it's not how a real audit target looks. Nobody ships a system with exactly one vulnerability class. A production multi-agent system has a document store that ingests from multiple tenants, a planner that calls tools, a memory layer that persists across turns, and — increasingly — an MCP server or two wired in for external integrations. The five trust boundaries you've been testing separately all exist in the same system at the same time, and an attacker doesn't respect your lesson plan's boundaries either.

This project is the actual work sample: consolidate the checks from lessons 1-5 into one AgentSecurityAuditor, point it at a single realistic composite target — SupportCopilot, a helpdesk agent with a shared RAG knowledge base, a tool registry, a planner/executor with persistent memory, and an MCP-connected filesystem and email tool — and produce the four things a client or employer actually pays for: a threat model, a severity-ranked reproducible vulnerability report, implemented fixes for the worst findings, and re-test evidence proving each fix closes its corresponding gap. A bullet list of concerns titled "security review" is an opinion. This is an audit because every finding has a reproduction step and every fix has a before/after number attached to it.

Building the Threat Model First

A threat model comes before a single check runs, because it's what tells you where to even look. AgentSecurityAuditor.build_threat_model() names seven trust boundaries in SupportCopilot, and each one maps directly to a lesson in this phase:

Ingestion boundary — untrusted documents enter the knowledge base from multiple tenants with no described sanitization step (lesson 1).
Retrieval boundary — retrieved text crosses from "data" into the agent's prompt context, becoming indistinguishable from instructions the moment it's inside the context window (lesson 1).
Tenant boundary — multiple tenants share one vector store, so a misconfigured retrieval path can leak one tenant's documents into another tenant's session (lesson 2).
Tool execution boundary — agent reasoning becomes real-world side effects the instant a tool call is invoked, with the tool registry as the only gate (lesson 3).
Planner/executor boundary — a plan produced from untrusted-influenced reasoning becomes a sequence of real actions unless the executor independently re-validates each step (lesson 4).
Memory boundary — facts written by one agent persist and get treated as ground truth by other agents, regardless of whether the original writer's source was ever verified (lesson 4).
MCP server boundary — an external server's tool manifest is read directly into the model's context and trusted as documentation, even though it's attacker-influenceable if the server is malicious or compromised (lesson 5).

Notice boundaries 2 and 3 are listed separately even though they're both about retrieval. That's deliberate, and it's the same distinction you saw in lesson 2: the retrieval boundary is about content becoming instructions (a poisoning problem, fixed by ingestion-time scanning), and the tenant boundary is about content becoming visible to the wrong audience (an access-control problem, fixed by pre-ranking filtering). A system can fix one without touching the other, so an audit has to name them as separate lines in the threat model or a client reading the report can't tell which fix addresses which risk.

Why does build_threat_model() run and get reported independent of whether any checks find findings at all — i.e., why is a threat model with zero vulnerability findings still a deliverable worth writing down?

A threat model names structural facts about the system — where untrusted content enters, where it crosses into contexts the model treats as instructions, where a boundary separates two audiences that shouldn't see each other's data. Those facts are true regardless of whether the current configuration happens to have a control in place. If SupportCopilot passes every check today because tenant isolation is enforced, the tenant boundary itself hasn't disappeared — it's still the place a future regression would land. That's exactly why generate_markdown_report() always includes the threat model section before the findings, independent of how many findings there are: it's the map a re-reviewer uses six months from now to know what to re-check, not just a list of what happened to be broken on the day of this audit.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Running the Five-Layer Audit, Fixes and Re-Test Evidence, The Executive Summary, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.