Layered Guardrails for Agentic Workloads

Tier: Advanced · Workflow area: Agent operations & guardrails

This playbook builds defense-in-depth for AI agents — gateway I/O filtering, action allowlists enforced outside the model, approval tiers by blast radius, and a kill switch — then proves each layer with attack requests.

When to use

• •
  Any agent (coding, ops, support) is getting tool access to systems that matter — repos, clusters, ticketing, customer data.
• •
  You operate the pb-45 gateway and teams are about to route agent traffic through it.
• •
  Security asks "what stops the agent from X?" and the honest answer is currently "the system prompt."

Skip heavyweight layering for generate-only workloads with a human review before anything executes — there, pb-46's observability plus output filtering suffices.

Prerequisites

• •
  pb-45 LiteLLM (or Portkey) gateway carrying the agent's model traffic.
• •
  An inventory per agent: which tools it can call, what each tool touches, worst-case action per tool.
• •
  OPA/Conftest familiarity (you have this from policy-as-code work) for the action layer.
• •
  Agreement on the blast-radius ladder below with security and the owning team.

The workflow

1. 1.

   Classify actions by blast radius first — the tiers drive everything else.

   Tier	Examples	Policy
   Read	get logs, list deploys, query metrics	auto-allow, log
   Reversible write	scale within bounds, restart, open PR, draft ticket	auto-allow + audit + rate limit
   Hard-to-reverse	merge, deploy, delete resource, send external comms	human approval required
   Forbidden	prod data deletion, IAM changes, spend commitments	not exposed as a tool at all

2. 2.

   Gateway layer: filter inputs and outputs. At the gateway, attach guardrails so every agent request/response passes PII redaction and prompt-injection screening regardless of which app forgot to. In LiteLLM, guardrails are declared in config and attached per-key/request mode (pre_call/post_call), e.g. a Presidio-based PII guard and an injection detector; Portkey ships equivalent gateway guardrails. Verify the exact config schema for your pinned version. Route by data class: keys serving client-restricted workloads get redaction mandatory-on (pb-45's allowlists already control which models they can reach).

3. 3.

   Model-adjacent layer: content rails. For agents with free-text outputs to users, add a safety classifier (Llama Guard-class) or NeMo Guardrails flows for topical control. Treat this layer as advisory scoring, not your enforcement point — it lives too close to the thing being defended against.

4. 4.

   Action layer: allowlists enforced outside the model. The agent's harness (not the model) validates every tool call against policy before execution. Express it as OPA so it's testable and reviewable:

   Copy

   package agent.actions
   
   default allow := false
   
   allow if {
     input.tool == "scale_deployment"
     input.args.namespace in {"staging", "dev"}
     input.args.replicas <= 10
   }
   
   requires_approval if {
     input.tool in {"merge_pr", "deploy_service"}
   }
   

   The model never sees credentials for actions outside its allowlist (scoped service accounts — pb-50/pb-51 build this out); a jailbroken model asking for a forbidden tool gets a policy denial, not a negotiation.

5. 5.

   Approval tier: humans on the hard-to-reverse rung. Approval-required actions pause the agent and page a human with the exact proposed action and its arguments (Slack approval flow, PR review, or your incident tooling). Log the approval with the action. Design for approval fatigue: if a tier generates dozens of approvals a day, either the tier is wrong or the agent is — tune, don't rubber-stamp.

6. 6.

   Kill switch, then red-team every layer. Kill switch = disable the agent's virtual key at the gateway (one API call, pb-45) plus a harness-level stop; rehearse it. Then attack each layer and file the evidence: PII in → redacted out; injection corpus ("ignore previous instructions...", data-exfil payloads, tool-smuggling in retrieved content) → blocked or downgraded; out-of-allowlist tool call → denied and alerting; approval-tier action → actually paused; kill switch → traffic stops in seconds. Re-run this suite on every guardrail config change — it's the pb-52 CI idea applied to safety.

Tool variants

• LiteLLM guardrails (+ Presidio): OSS path integrated with the gateway you already run — default choice.
• Portkey guardrails: managed PII/jailbreak checks at the gateway layer with less assembly.
• NeMo Guardrails / Llama Guard: programmable dialogue rails and safety classification nearest the model.
• OPA/Kyverno: OPA for harness action policy; Kyverno when the action surface is K8s objects themselves (pairs with pb-50's sandboxes).

Verification

• •
  Attack-evidence file per layer (request in, observed result) checked into the agent's repo and refreshed on config change.
• •
  Audit log answers, for any past action: what was called, with what args, under which policy decision, approved by whom.
• •
  Kill-switch drill timed: minutes from decision to zero agent traffic.
• •
  False-positive rate tracked: legitimate agent actions denied per week — a guardrail that blocks the job gets bypassed culturally, which is worse than tuning it.

Pitfalls

• Prompt-only guardrails. "You must never..." in the system prompt is tier zero and defeats nobody persistent. Every real control lives outside the model.
• One giant allowlist. Per-agent, per-environment policies; the support bot and the ops agent share nothing. Scope creep in tool grants is the agent version of IAM *.
• Filtering only user input. Injection arrives in retrieved documents, tool outputs, and repo content the agent reads — screen model-bound context, not just the human's message.
• Unmonitored guardrails. A guardrail that blocks silently trains teams to route around it. Every denial emits a metric and lands in pb-46's dashboards.

Restricted-environment variant

• •
  Gateway-level PII redaction is the services-company superpower: enforce client-data redaction in config on every hosted-provider route, so compliance doesn't depend on each delivery team remembering.
• •
  Run guardrail components (Presidio, classifiers, OPA) inside the client boundary; guardrail logs contain the sensitive strings they caught — scope and retain accordingly.
• •
  Map your tiers to the client's change-management process — "human approval" may contractually mean client approval for production actions.

Success criteria

• •
  Every agent in production has: gateway I/O guardrails, an enforced action allowlist, an approval tier, and a rehearsed kill switch — none of which live in the system prompt.
• •
  The red-team suite passes and is re-run on change, with evidence auditable by security.
• •
  Blast-radius tiers are documented and the approval queue is quiet enough that approvals are real reviews.
• •
  When security asks "what stops the agent from X?", the answer is a policy file and a test, not a paragraph of prompt.