Before an agent acts, someone must have decided what it may never do, what needs a human's yes, and how to stop it mid-flight. This playbook designs that architecture — action allowlists, approval tiers keyed to irreversibility, sandbox boundaries, audit trails, and kill switches — as the design that makes guardrail operations possible.
Tier: Advanced · Hands-on time: ~35 minutes
The AWS Agentic AI Lens and the posting language behind this track ("guardrails for agentic workloads") both put this squarely in the architect's lap: the operations side runs approvals and monitors guardrails, but only if the architecture defined the tiers, boundaries, and stop mechanisms in the first place. The organizing principle is irreversibility — the cost of undoing an action, not its technical category, determines how much human oversight it earns.
Classify every action by irreversibility, not by API verb. Sending an email is technically trivial and socially irreversible; a database write with a tested restore path is technically scary and operationally reversible. For each action in the tool table, record: undo mechanism, undo window, undo cost, and worst realistic consequence. This classification drives everything downstream.
Define the approval tiers. A workable ladder: Tier A — autonomous (reversible, low-consequence, fully logged); Tier B — notify (act, then surface for async human review with easy undo); Tier C — approve-first (human sees the exact proposed action with arguments and clicks yes before execution); Tier D — never (excluded from the agent surface entirely; the agent may draft, a human executes elsewhere). Map every action to a tier and record the reasoning.
Design approvals humans can actually perform. An approval request must carry: the exact action and arguments, the agent's stated reasoning, the data it relied on, and the reversibility note. Batch low-stakes approvals, set response-time expectations, and — critically — cap the approval volume per human. A tier design that generates 400 approvals a day has designed rubber-stamping.
Draw the sandbox boundaries. Which environments can the agent touch (production vs staging), which identities does it hold there (minimum-privilege service accounts, scoped per pb-37), and which resources are physically unreachable rather than merely disallowed by policy. Prefer unreachable: a network boundary does not have prompt-injection failure modes.
Design the kill switches before the incident. Three levels: per-agent (stop this agent's task now, checkpointed per pb-36 so stopping is safe), per-tool (revoke one capability across all agents — the gateway from pb-37 is the natural enforcement point), and global (all agentic activity halts). Decide who may pull each, how fast it takes effect, and what in-flight actions do when it fires.
Generate the scenario set that tests the design. Vikram, preparing a BFSI agent design for his ARB:
Generate 15 failure scenarios for this agent approval architecture
(attached: action-tier table, approval flow, sandbox boundaries,
kill-switch design) for a service agent that can read customer
records, draft responses, create CRM cases, and issue refunds
up to a limit.
Cover at least: prompt-injected instructions arriving via retrieved
content; an approver rubber-stamping under volume; a refund loop
caused by retry logic; identity or scope drift after a tool update;
kill-switch latency during an active incident; and an action that is
individually Tier A but harmful in aggregate (1,000 small refunds).
For each: the concrete sequence, which control should catch it, and
what evidence would show the control actually fired. Flag scenarios
where NO current control catches it.
Walk every scenario through the design on paper; uncaught scenarios change the design before launch, not after.
Specify the audit trail and ship the package. Every action logged with agent, principal, tier, approval reference, arguments, and outcome — append-only, queryable by incident responders. The deliverable: action-tier table, approval-flow diagram, sandbox map, kill-switch runbook stub, and the scenario walkthrough record. Operations inherits the runbook; the design is yours.
Client engagements usually make this architecture a contractual artifact — MSAs and client risk teams may dictate tier boundaries (no autonomous writes to client systems, ever) before your analysis begins, so extract those constraints first and design within them. All scenario testing runs against sandboxes with synthetic data inside the client boundary; approval workflows integrate with the client's existing ITSM tooling rather than external SaaS. For development, the whole control stack — OPA policies, approval gates, kill switches — exercises fully offline with a local Ollama-served model driving synthetic tasks, which is also the cheapest way to demonstrate a blocked action in the design review itself.
Irreversibility sets the tier, the tier sets the human's role, and nothing ships until you have watched the design block an action, timed the kill switch, and tripped the aggregate limit in a sandbox.