series

Securing AI agents

How to give an AI agent real tools without handing it the keys, in watch order: locking down MCP tools first. Hand-drawn doodle explainers, theory then a practical example.

4 videos · 41 min · Play all on YouTube

  1. 1. MCP Server Security: Scoping Tools So an Agent Can't Wreck Things

    Whatever your MCP server can do, your agent can do. Remove tools, pin descriptions, confirm writes, give the agent its own role, check every call and log it.

  2. 2. Supply-Chain Attacks on AI Apps: How a pip install Steals Your Keys

    How a poisoned LiteLLM release ran at Python startup without an import, how attackers got it through an official pipeline, and how pins, hashes, cooldowns and digests stop it.

  3. 3. Prompt Injection Explained: What Actually Stops the Bad Tool Call

    Why an LLM obeys instructions hidden in a web page or email, how a markdown image leaks your chat, why filters fall to adaptive attacks, and the design patterns that actually hold.

  4. 4. How to Sandbox AI Agents (and What It Won't Stop)

    Your agent's commands run as you. How a file wall and a network wall contain it, how strong the wall should be, and the four gaps a sandbox leaves open.

play with it

Walls, not prompts

Edit the walls, then see what an agent's actions would do.

  • read ~/.ssh/id_ed25519 blocked (file wall: denied read)
  • read ./src/app.ts allowed (reads are open unless denied)
  • write ./docs/notes.md allowed (inside an allowed write folder)
  • write ~/.bashrc blocked (file wall: writes only where allowed)
  • fetch registry.npmjs.org allowed (on the domain allowlist)
  • fetch attacker.example blocked (network wall: not on the allowlist)

A simplified model of the walls in the sandbox episode, not the exact matching rules of any sandbox tool. An allowed domain can still carry your data out.