Enterprise AI Defense

The problem you already have

Your teams shipped AI agents this year. Most enterprises did — and most of them have already had an agent-related security incident to show for it. The tools that make agents useful — retrieval over your documents, the ability to call functions, MCP connections to real systems, coding agents inside your repos — are the same tools an attacker turns against you. A single sentence buried in a retrieved document, a tool description on a third-party MCP server, or an instruction planted in a project file any outside contributor can edit is enough to redirect an agent into leaking data, issuing refunds it shouldn't, or running commands you never approved.

Prompt-injection findings are up sharply year over year, and 2026 brought the first wave of named, scored CVEs in agent and MCP infrastructure — this stopped being theoretical. Meanwhile most security training aimed at AI is written for penetration testers, not for the engineers actually building these systems. That is the gap this course fills.

What makes this different

This is not a lecture on AI risk. You will attack and then harden one realistic system — a customer-support agent with a RAG pipeline, tools, an MCP gateway, and a coding-agent workflow — organized around a six-layer security blueprint covering data and retrieval, prompt and context, model I/O guardrails, tools and agents, the MCP integration boundary, and operations and governance. Every lab follows the same arc: run the vulnerable version, break it with your own hands, build the defense, then watch the same attack fail. You leave having done the thing, not having watched a slide about it.

What you will build

The course is organized around a six-layer security blueprint, and by the end you will have attacked and defended all six:

• Data & retrieval — poison a RAG pipeline with a planted document, then filter retrieval by provenance so the poison never reaches the model.
• Prompt & context — make a support bot hand over its secrets. The blunt attacks fail; the ones that land ask the model to summarize or translate its own instructions. Then defeat them by moving secrets out of context and framing untrusted input as data.
• Model I/O guardrails — build a reusable input/output guard pipeline and prove it with an automated red-team suite.
• Tools & agents — take an over-permissioned agent and lock it down with deny-by-default authorization, spending limits, and human-in-the-loop.
• Integration boundary (MCP) — catch a malicious MCP server that hides attacks in its tool descriptions, then secure the boundary with tool pinning, scopes, per-action authorization, and an audit trail.
• Operations & governance — trace agent behavior, wire a security eval suite into CI so a regression fails the build, and implement the AI-disclosure and provenance requirements regulators now check.

Two of the most current threats get their own labs: coding-agent injection (the CVE-class where poisoned repo files hijack a coding agent, with an optional extension that hardens real Claude Code) and MCP tool poisoning. The course closes with a capstone: harden the whole system end-to-end and score it against the six-layer blueprint — a scorecard you can point at your own systems the next Monday.

The progression

The model, the data, the prompt. Start by threat-modeling the system and ranking its attack surface, so the rest of the course runs in priority order. Then work the layers closest to the model: direct prompt injection, RAG poisoning through a planted document, PII that should never reach the model or the logs, a reusable guardrail pipeline with a red-team suite behind it, and an over-permissioned agent brought under a deny-by-default policy.

The boundary, the agent, and the business. Move outward: tool poisoning and rug-pulls at the MCP layer, then a scoped and audited MCP gateway; coding-agent injection through poisoned project content; blast-radius containment for the compromise that gets through anyway; observability and a security gate that fails the build on a regression; and the AI-transparency obligations regulators now check. This closes with the end-to-end capstone and scorecard.

What you'll walk away with

You leave with the complete lab code, the six-layer scorecard as a reusable artifact, working reference implementations of each defense, and a red-team test suite you can grow. More importantly, you leave with a way of seeing your AI systems — where untrusted input enters, where privilege is too broad, and where to put the control that actually contains the damage.

Being honest about scope

There is enough here to change how your team builds — not enough to make anyone a security researcher, and we won't pretend otherwise. In practice that means:

• The defenses in the labs are correct in shape but deliberately minimal — teaching implementations, chosen so the mechanism stays visible rather than hidden behind a library. They are blueprints to harden for production, not drop-in components, and we say so.
• We teach that prompt injection is not fully solvable at the prompt layer, and that a model's own refusals are not a control — you will watch a bot refuse a direct request, then comply with the same request reworded as a summary. The honest goal is defense in depth and blast-radius containment, not a promise of prevention.
• This is the builder's half of AI security — designing systems that resist attack. It is not a red-team/pen-testing certification, and it does not cover training-time attacks or formal governance programs in depth.
• Where a statistic or regulation appears, we attribute it and flag what is a vendor survey versus a primary source. You learn to check, not just to trust.

That honesty is deliberate. The reason AI-security training so often fails is that people finish it and can't apply it. This course is built the opposite way — hands on the keyboard, attacking and defending real code — so what you learn survives contact with your actual work.