{
"lesson": {
"id": "hu-204-guardrails",
"slug": "guardrails",
"title": "Guardrails: Real-Time Query Policy Enforcement",
"subtitle": "Block destructive queries at the protocol layer before they hit your database",
"summary": "A walkthrough of Hoop's guardrails feature in three acts: configure a custom rule that prevents mass deletion, attempt a destructive query as a non-admin and watch it get blocked in real time, and review the blocked attempt in the audit trail. Works equally on queries from human engineers and AI agents.",
"description_long": "Guardrails are real-time execution policies that sit at the protocol layer. Every query, regardless of whether it originates from a human engineer or an AI agent, is evaluated before it executes. This lesson shows the full lifecycle. The host configures a custom guardrail rule to prevent mass deletion, scopes it to specific resources, and saves it. Then, as a non-admin, attempts a destructive query against a Postgres demo database. The query is instantly blocked with a clear user-facing message and the database is left untouched. Finally, the host returns to the admin account to inspect the audit trail, where every blocked attempt is logged with the exact query, the user who ran it, the rule it triggered, and the timestamp. The result is automatic SOC 2, HIPAA, and PCI DSS evidence from real sessions.",
"status": "draft",
"language": "en",
"version": "1.0.0",
"published_at": null,
"updated_at": "2026-05-08T00:00:00Z"
},
"video": {
"provider": null,
"video_id": null,
"url": null,
"embed_url": null,
"thumbnail_url": null,
"duration_seconds": null,
"duration_formatted": null,
"captions_url": null,
"captions_languages": ["en"]
},
"curriculum": {
"track": "platform-fundamentals",
"module": "access-governance",
"lesson_number": 4,
"level": "intermediate",
"estimated_time_minutes": 5,
"prerequisites": [
"hu-201-access-controls",
"hu-202-ai-data-masking",
"hu-203-access-requests"
],
"next_lesson_id": null,
"previous_lesson_id": "hu-203-access-requests",
"learning_objectives": [
"Create a custom guardrail rule and assign it to one or more resources",
"Choose between preset rules and custom pattern-matching rules",
"Demonstrate that a destructive query is blocked at the protocol layer with a clear user-facing message",
"Confirm that blocked queries leave the underlying database unchanged",
"Inspect the audit trail to see the blocked query, the user, the triggered rule, and the timestamp",
"Map guardrail logs to SOC 2, HIPAA, and PCI DSS evidence requirements",
"Understand that guardrails apply equally to queries from human engineers and AI agents"
]
},
"audience": {
"primary_persona": "platform-engineer",
"secondary_personas": ["security-engineer", "compliance-officer", "data-protection-officer", "ai-platform-engineer"],
"use_cases": [
"destructive-query-prevention",
"ai-agent-governance",
"real-time-policy-enforcement",
"audit-evidence-collection",
"soc2-compliance",
"hipaa-compliance",
"pci-dss-compliance"
],
"industries": ["fintech", "saas", "healthcare", "regulated-industries"]
},
"content": {
"key_concepts": [
{
"term": "Guardrail",
"definition": "A real-time execution policy that sits at the protocol layer and evaluates every query before it executes. If a query matches the rule, it is blocked instantly."
},
{
"term": "Pattern matching",
"definition": "A guardrail rule type that compares incoming queries against a defined pattern. Matching queries are blocked at the protocol layer before reaching the database."
},
{
"term": "Preset rules",
"definition": "Built-in guardrail templates available out of the box, intended to cover common destructive query patterns without requiring custom configuration."
},
{
"term": "Custom rules",
"definition": "User-defined guardrail rules. The host uses one to prevent mass deletion in this lesson."
},
{
"term": "Resource scoping",
"definition": "Each guardrail rule is assigned to one or more specific resources. The rule only enforces on those resources."
},
{
"term": "Equal coverage for humans and AI agents",
"definition": "Guardrails evaluate queries regardless of origin. A query from an AI agent goes through the same protocol-layer policy check as a query from a human engineer."
},
{
"term": "Block-and-log",
"definition": "When a guardrail blocks a query, the user receives a clear message, the database is not touched, and the attempt is logged in the session audit trail."
}
],
"topics": [
"guardrails",
"policy-enforcement",
"destructive-queries",
"wire-protocol-proxy",
"ai-agent-governance",
"audit-log",
"compliance",
"soc2",
"hipaa",
"pci-dss"
],
"tags": ["intermediate", "guardrails", "policy", "ai-agents", "compliance", "postgres"],
"products_mentioned": ["hoop-guardrails", "hoop-web-ui", "hoop-sessions"],
"competitors_mentioned": [],
"external_references": []
},
"transcript": {
"full_text": "We've covered access control, then we moved on to AI data masking, and now we are going to discuss guardrails. I'm going to show you how to configure guardrails, then move over to a non-admin account, run a destructive query, and show you the results. Then we'll navigate back to this admin account and see what showed up in the sessions log. [Full transcript continues, see segments below for structured version]",
"word_count": 575,
"language": "en",
"auto_generated": true,
"edited": false,
"segments": [
{
"index": 0,
"start_seconds": null,
"end_seconds": null,
"speaker": "Host",
"text": "We've covered access control, then AI data masking, and now we're going to discuss guardrails. I'm going to show you how to configure them, switch to a non-admin account, run a destructive query, and show you the results. Then we'll go back to the admin account and see what showed up in the sessions log."
},
{
"index": 1,
"start_seconds": null,
"end_seconds": null,
"speaker": "Host",
"text": "Navigate to guardrails. You can see there are already a few custom rules created. We're going to focus on preventing mass deletion. To create a new guardrail you'd click create a new guardrail and get the same interface, just empty. You give it a name, assign it a resource, I've chosen two, and then enter the input rule."
},
{
"index": 2,
"start_seconds": null,
"end_seconds": null,
"speaker": "Host",
"text": "We have presets you can choose from, or you can create your own. I've created a custom rule. That's it. You hit save. Now let's see how it works in real time."
},
{
"index": 3,
"start_seconds": null,
"end_seconds": null,
"speaker": "Host",
"text": "Switching to the non-admin account. I want to work on the Postgres demo. Click connect, open it in the Web UI or terminal. Before I run a destructive command, let's look at what's in the database. Select all from users: we get emails. Check customers: more PII. Check orders too. This isn't a real database so it may not be fully realistic, but treat it as if your developer or AI agent didn't have guardrails."
},
{
"index": 4,
"start_seconds": null,
"end_seconds": null,
"speaker": "Host",
"text": "Now I run the destructive query, and we get: blocked by the following guardrail rules. This is guardrails working. It's a real-time execution policy that sits at the protocol layer. Every query, whether from a human engineer or an AI agent, is evaluated before it executes."
},
{
"index": 5,
"start_seconds": null,
"end_seconds": null,
"speaker": "Host",
"text": "We chose pattern matching, so if a query matches the rule, it's instantly blocked. The user gets a clear message, the event is logged, and the database is not impacted. If we go back and select from customers, nothing has changed. Everything is still the same. That's guardrails working in real time."
},
{
"index": 6,
"start_seconds": null,
"end_seconds": null,
"speaker": "Host",
"text": "Every blocked query is logged. So are the ones that aren't blocked. Let me show you. You see exactly what was attempted, which guardrail it triggered, which user ran it, and the time. Teo ran this. This is your audit trail for SOC 2, HIPAA, or PCI DSS, generated automatically from real sessions. That's what guardrails can do for your infrastructure."
}
]
},
"chapters": [
{
"title": "Where guardrails fit",
"start_seconds": null,
"end_seconds": null,
"summary": "Recap of the access-governance arc so far and intro to the three-act demo: configure, attempt, audit."
},
{
"title": "Configuring a mass-deletion guardrail",
"start_seconds": null,
"end_seconds": null,
"summary": "Walkthrough of the guardrails interface: name, resource assignment, preset versus custom rule, save."
},
{
"title": "Inspecting the database before the attempt",
"start_seconds": null,
"end_seconds": null,
"summary": "As a non-admin in the Postgres demo, viewing users, customers, and orders to set baseline state."
},
{
"title": "The destructive query gets blocked",
"start_seconds": null,
"end_seconds": null,
"summary": "Running the destructive query and watching it return: blocked by the following guardrail rules. User-facing message, no database impact."
},
{
"title": "How protocol-layer enforcement works",
"start_seconds": null,
"end_seconds": null,
"summary": "Why guardrails apply equally to humans and AI agents and how pattern matching evaluates queries before execution."
},
{
"title": "Audit trail review",
"start_seconds": null,
"end_seconds": null,
"summary": "Reviewing the blocked attempt in sessions: query attempted, rule triggered, user, timestamp. SOC 2, HIPAA, and PCI DSS evidence generated automatically."
}
],
"code_snippets": [
{
"id": "snippet-1",
"title": "Inspecting the users table",
"language": "sql",
"code": "SELECT * FROM users;",
"context": "Run by the non-admin to view PII before attempting the destructive query.",
"appears_at_seconds": null
},
{
"id": "snippet-2",
"title": "Inspecting the customers table",
"language": "sql",
"code": "SELECT * FROM customers;",
"context": "Used both before and after the blocked destructive query to confirm the database state is unchanged.",
"appears_at_seconds": null
}
],
"resources": [
{
"type": "documentation",
"title": "Hoop guardrails",
"url": "https://hoop.dev/docs/guardrails"
},
{
"type": "documentation",
"title": "Pattern matching reference",
"url": "https://hoop.dev/docs/guardrails/patterns"
},
{
"type": "documentation",
"title": "Session audit log",
"url": "https://hoop.dev/docs/sessions"
}
],
"quiz": {
"enabled": true,
"questions": [
{
"id": "q1",
"type": "single_choice",
"prompt": "When does a guardrail evaluate a query?",
"options": [
"After the query has executed, by analyzing the results",
"Before the query executes, at the protocol layer",
"Only if the query is flagged by an external SIEM",
"Only when the query comes from an AI agent"
],
"correct_index": 1,
"explanation": "Guardrails are real-time execution policies that sit at the protocol layer. Every query is evaluated before it executes."
},
{
"id": "q2",
"type": "single_choice",
"prompt": "What happens to the database when a guardrail blocks a query?",
"options": [
"The database is rolled back to a previous state",
"The database is locked for the offending user",
"The database is not impacted at all",
"The database receives the query but discards the response"
],
"correct_index": 2,
"explanation": "When a query is blocked it never reaches the database. The user gets a clear message, the event is logged, and the database state is unchanged."
},
{
"id": "q3",
"type": "single_choice",
"prompt": "Which queries get logged in the session audit trail?",
"options": [
"Only blocked queries",
"Only queries from AI agents",
"Only queries flagged by preset rules",
"Every query, both blocked and unblocked"
],
"correct_index": 3,
"explanation": "Every blocked query is logged, and so are the ones that aren't blocked. The audit trail captures the attempt, the rule triggered, the user, and the timestamp."
},
{
"id": "q4",
"type": "single_choice",
"prompt": "Why do guardrails apply equally to AI agents and human engineers?",
"options": [
"Because AI agents authenticate with the same credentials as humans",
"Because guardrails sit at the protocol layer and evaluate queries regardless of origin",
"Because Hoop blocks all AI-generated traffic by default",
"Because guardrails inspect intent rather than the query itself"
],
"correct_index": 1,
"explanation": "Guardrails operate at the protocol layer and evaluate every query before execution, so the same rule blocks the same query whether the source is a human or an AI agent."
}
]
},
"seo": {
"meta_title": "Guardrails in Hoop | Hoop University",
"meta_description": "Block destructive queries before they hit your database. Real-time, protocol-layer policy enforcement that works for humans and AI agents alike.",
"og_image": null,
"canonical_url": "https://hoop.dev/university/guardrails",
"keywords": [
"guardrails",
"destructive query prevention",
"ai agent governance",
"policy enforcement",
"wire protocol proxy",
"soc 2 evidence",
"hipaa",
"pci dss"
]
},
"agent_metadata": {
"extracted_at": "2026-05-08T00:00:00Z",
"extraction_model": "claude-opus-4-7",
"extraction_version": "1.0.0",
"human_reviewed": false,
"reviewer": null,
"confidence_score": 0.91,
"extraction_notes": "Source transcript is auto-generated, lacks timestamps, and has no explicit speaker label. All timing fields are null and segments are labeled 'Host'. The host opens with an explicit recap ('we've covered access control, then we moved on to AI data masking, and now we are going to discuss guardrails'), which locks the curriculum order: access controls (1), AI data masking (2), access requests (3), guardrails (4). Two literal SQL queries are present in the transcript (SELECT * FROM users and SELECT * FROM customers) and were captured as code snippets. The destructive query that triggers the block is referenced but the literal SQL is not spoken; capture from the screen recording if needed. The host names three compliance frameworks (SOC 2, HIPAA, PCI DSS) which were carried into use_cases, learning objectives, and SEO."
}
}
