AI Agent Guardrails: Build a Four-Control Action Gate

AI agent guardrails should not be one prompt, one classifier, or one approval button. For an agent that can change external state, the practical default is a four control action gate: decide whether the action is allowed, prove the caller has authority for this exact action, bound the attempt, then verify the external effect. Each control answers a different question. Combining them into a single safe: true flag hides whether an agent is blocked, waiting for a person, out of retry budget, or merely missing evidence after a tool call. Keep those states separate and the system can fail closed without treating every pause as an incident. Put policy at the action boundary Start by shrinking what the agent can ask a tool to do. A policy gate should receive structured action data, not prose alone: The policy result should be one of allow , deny , or unknown . Unknown is important. A missing classification is not permission, and forcing ambiguity into allow or deny makes the model invent certainty on behalf of the operator. This gate must also check whether the tool belongs in the agent's capability set. The OWASP guidance on excessive agency identifies excessive functionality, permissions, and autonomy as separate root causes. Its mitigations are correspondingly concrete: expose only necessary extensions, prefer narrow functions over open ended commands, grant minimum downstream permissions, and enforce authorization in the downstream system. That last boundary matters. An instruction such as “never delete production data” is useful context, but it is not an authorization control. A delete endpoint should reject an unauthorized identity even when an agent produces a persuasive reason. Likewise, a read only workflow should not receive a client whose credentials can write. Model guardrails still have a job, but know their timing. The OpenAI Agents SDK documentation distinguishes agent input/output guardrails from function tool guardrails. It also notes that a parallel input guardrail can finish after the agent has already consumed tokens or executed tools. For a side effect boundary, use a blocking check immediately before execution, backed by real downstream authorization. The reasonable default is: deny tools outside a per agent allowlist; calculate required scopes from the structured action; enforce those scopes outside the model; return unknown when policy inputs are incomplete; record the policy version and action digest with the decision. Content filters do not replace this gate. AWS's Connect AI guardrail documentation covers denied topics, content filters, grounding checks, word filters, and sensitive information controls, while also documenting configuration limits and latency trade offs. Those are useful safeguards for inputs and outputs. They do not prove that a release, payment, message, or file mutation is authorized. Bind approval to one action, not a conversation “Approved” is too vague to execute. A safe approval is a short lived authority envelope tied to the exact action the person reviewed. At minimum, persist: Recompute the action digest immediately before execution. If the resource, arguments, actor, tool, impact, or expiry differs, the approval does not match. Ask again rather than stretching an old decision over new work. This prevents a quiet but serious class of failures. A person may approve a release candidate for one repository, then the agent's context changes, a retry reconstructs different arguments, or another run reuses the same conversation state. A free floating boolean survives all three mistakes. An action bound receipt does not. Approval also needs an owner and a resumable state. awaiting approval is not stuck : it has a named decision, a route to the right person, and an expiry. After a decision, resume from the frozen action envelope instead of rerunning planning and hoping the model proposes the same operation. Not every action needs a human. Use impact to decide: read only, reversible, low scope actions can proceed under standing policy; changes with bounded, well tested rollback may use explicit limits and audit; public, financial, destructive, privilege changing, or otherwise high impact actions require exact approval; ambiguity about impact routes to a person. Human review is therefore one control inside the stack, not the stack itself. Bound execution even after authorization An allowed and approved action can still run badly. The executor needs hard limits that the agent cannot silently renegotiate: one absolute deadline, checked before every attempt; a maximum attempt count; an idempotency key for side effects; a resource and impact ceiling; a cancellation path; a rule for what happens when the result is ambiguous. The operation identity must remain stable across retries. If a transport timeout occurs after the destination committed a change, issuing a new operation identity may duplicate the effect. If the destination supports idempotency, reuse the same key. If it offers an authoritative lookup, reconcile before retrying. If neither exists, stop with unverified rather than guessing that another attempt is safe. Keep executor state mechanical. A model can recommend a retry, but code should decide whether attempt < maxAttempts , the deadline is fresh, the resource still matches, and the action has a usable idempotency key. This is one of the rare places where boring conditionals are exactly the right design. Limits are not only for damage containment. They preserve diagnosis. Without them, a repeated call can look like persistence, an expired operation can look like slow progress, and a duplicated effect can look like recovery. With explicit bounds, the operator can distinguish working, waiting, blocked, and uncertain states. Verify the effect independently A tool response proves what the tool reported, not necessarily what the user needed. The final gate compares an observable postcondition with the promised outcome. Prefer deterministic evidence: fetch the created object by stable ID; read the destination branch or release record; verify that the expected file exists and its hash matches; run the relevant tests; confirm that a message appears in the intended destination; compare the before and after values of the exact resource. Do not use the same weak signal twice. If the write endpoint returns { "ok": true } , copying that field into a completion record is not independent verification. Read from the authoritative destination or inspect the promised deliverable. Some outcomes cannot be verified immediately. A notification may be accepted but not delivered, an external provider may lack a read API, or an observation channel may be stale. Represent that as unverified , include the missing evidence and next safe check, and avoid reporting success. This is where operational health and security meet. Policy and authorization prevent forbidden actions; effect verification prevents false completion. An agent can obey every access rule and still fail its task. Conversely, a successful outcome does not excuse an unauthorized path. Replay nine cases before trusting the design The accompanying artifact turns the four controls into a small executable test. guardrail cases.json contains nine proposed actions. evaluate agent guardrails.mjs applies a fixed precedence: 1. policy; 2. scopes and approval authority; 3. execution bounds; 4. effect evidence. Run it with: The reproduced summary is: The interesting cases are not the clean pass or obvious denial. One approval is expired. Another was issued for a different action fingerprint. One write exhausted its retry budget. One command ran without observable effect. One policy cannot classify the action at all. Those cases show why state precedence must be explicit. Check effect evidence first and an unauthorized action might be labeled merely unverified. Check approval before policy and you might ask a person to authorize a tool that should never have been available. Collapse unknown into denial and the operator loses a repairable data quality signal; collapse it into allow and the system invents authority. Adapt the fixture to your own tools. Add cases for resource substitution, scope loss, reused approval nonces, stale policy versions, deadline expiry, partial effects, rollback failure, and a verification channel that disagrees with the tool response. The gate is ready only when those failures produce the state and next action you intended. Keep the boundary honest AI agent guardrails work when each control can veto the action for its own reason and expose evidence for that decision. The compact rule is: Policy decides whether the action belongs. Authority binds who may do exactly what. Bounds constrain the attempt. Verification proves the effect. This costs more than adding a classifier. Exact approvals add waiting time. Read after write checks add calls. Narrow tools require engineering. Unknown states need operator handling. The trade is worthwhile for side effects because ambiguity stays visible instead of becoming silent authority or false success. Sidewisp is currently in private preview. It is intended as a health layer around existing agent runtimes, but production agent health collection and recovery are not shipped in the current website repository. The control stack here is an implementation pattern you can test now, not a claim that Sidewisp currently enforces it. If you are evaluating Sidewisp for future agent health workflows, join the private preview. In the meantime, keep the action envelope and its evidence in your own runtime: the safest guardrail is the one that still holds when the model is confidently wrong.