CoursesPro56 min of video

Secure AI Agents with Guardrails

An agent that can read your issues and docs can also leak them, or obey an instruction hidden inside them. Most teams give every agent one shared API key and hope the prompt holds. Live, I give each agent its own identity in Keycloak, check every action against the user's permissions with OpenFGA, and block a prompt injection planted in a GitHub issue.

The lessons, in order

Each lesson is one idea from the live build, cut to a few minutes, with chapters and the full transcript. The first is free once you sign in; Pro opens the rest.

  1. 1

    Why AI agents need different guardrails than APIs

    Why are AI agents harder to secure than an API? Param Harrison explains why guardrails for AI agents differ from the checks you already put on a web or mobile API. An API has a known path, middleware and a short life cycle; an agent acts on your behalf, so a wrong action cannot be taken back with an apology. After this lesson you can define the identity an agent acts for, the permissions it is allowed and denied, and the five stages an input passes through. You will also see real incidents, including a pull request that planted a wipe prompt in an Amazon VS Code extension, and why an agent that loops needs limits you can watch.

    Out
  2. 2

    Stop prompt injection by taking away capability

    How do you stop a prompt injection from reaching your tools? Param Harrison starts from a support ticket that tells the agent to ignore its goals, query the admin table and forward the rows. A stronger system prompt and a classifier on the input both help, but taking away the capability is the one that holds, because a model reads a prompt differently each time and an agent loop can take a different path. After this lesson you can add a guardrail model or a typed schema that accepts only the values you expect, send anything outside your boundary to a human, and authorize who is asking before a tool runs.

    Out
  3. 3

    Keep a human in the loop when agents change state

    When should an AI agent act without a human? Param Harrison walks through the three ways an agent gets attacked: untrusted input, sensitive access and changing state. Sensitive access means saying exactly what an agent and each sub-agent can read, down to the table. Changing state is the trickiest: from an AI SRE agent he built on ClickHouse data, the lesson is to let the agent triage and find the root cause and leave the last mile to a human. After this lesson you can classify each write as low, medium or high risk, keep a human in the loop for medium and high, and automate only after you trace and evaluate the runs.

    Out
  4. 4

    Make AI agents answer from your data, not their own

    What should an AI agent do when your data has two answers? Param Harrison covers hidden prompts in images and email, and why an agent should deny by default, allow by domain, and draft instead of send until a review passes. Then the Air Canada case: its chatbot invented a refund policy and Air Canada had to give the refund, so an agent's promise is your promise. After this lesson you can bound an agent to answer from your data, and you will see the harder problem from immigration work: when 2025 and 2026 visa rules both sit in your data, the agent needs a way to pick the current one or ask a human.

    Out
  5. 5

    Limit what an AI agent can reach: tenants, schemas, PII

    How much of your data should an AI agent be able to reach? Param Harrison explains that tool calls, CLIs and MCP are all fine ways to expose data; what matters is who is acting and what access they have. Tenant data gets filtered in the agent and at the database, with short-lived access. After this lesson you can build a text-to-SQL agent that sends only the schema shape through an MCP gateway, runs the query in a sandbox and charts the result without the model seeing your rows. You will also see why zero data retention alone does not keep personal data compliant when an agent sends it to a third-party model.

    Out
  6. 6

    Enforce AI agent permissions in code, not the prompt

    Why is a rule in the prompt not a permission? Param Harrison shows how to forbid a request inside the tool when the permission is not there, with fine-grained permissions such as OpenFGA, and how to test in CI that cross-tenant access is blocked. An agent from CodeWall found API docs and routes with no login, so your tests should check every endpoint that is open. As teams move from AI-assisted coding to an AI-native factory where tickets run in the cloud, those checks have to come first. After this lesson you can replace a prompt line like do not modify production with an explicit deny at the system level, the lesson Replit learned after a production database was deleted by accident.

    Out
  7. 7

    Cap AI agent loops and move defenses out of the model

    What stops your AI agent from looping all night? Param Harrison covers the part most teams skip: how the agent runs. An agent that calls a tool again and again is a while true loop unless you set its maximum time, budget and timeout. He shows it from his own Claude Code workflows, where a drafting step that loops until a rubric scores 95 needs a cap of three tries and a fallback, or it burns tokens with nobody watching. After this lesson you can place each defense in one of four stages, design, build, deploy and operate, route each step to the right model, and keep identity and access decisions in code rather than in the prompt.

    Out

What the course covers

Engineers whose agent demo now has to pass a security review, and the tech leads and platform engineers responsible for what agents may see and do.

Give every agent its own identity
Each agent signs in with its own scoped credentials, never a shared key.
Check each action against the user's permissions
The agent sees and does only what the person it works for may.
Block prompt injection hidden in your data
Catch an instruction planted in an issue before the agent follows it.