Best AI Agent Guardrails for Pre-Action Authorization

Summary: The best AI agent guardrails for a team are the ones that cover its actual action paths. A filter that rejects harmful text, a sandbox that restricts network access, and a policy that rejects a payment recipient answer different questions. Start with the operation you need to control, then prove a denial stops it. APort's decision-versus-enforcement contract explains why a recorded denial and a blocked action are separate facts.

Several products can intervene before tools execute. This comparison uses documented behavior, not a head-to-head benchmark. APort publishes it and provides one of the options. The buyer's test is whether the chosen integration sees the relevant parameters and leaves evidence of both the policy result and the runtime outcome.

The four layers

A useful comparison begins with four jobs: inspecting content, evaluating behavior, containing execution, and authorizing actions. These are control responsibilities, not exclusive vendor categories. A single product can implement several.

Agent receives input and proposes work
  | content checks: inspect inputs, retrieved text and outputs
  v
Proposed tool + arguments
  | action check: evaluate identity, target and operation
  | runtime: honor deny before dispatch
  v
Tool executes inside filesystem / process / network restrictions
  | sandbox: restrict resources the process can reach
  v
Observed result and trace
    evaluation: replay, score and investigate regressions

This diagram is a conceptual deployment model. Content checks can run at several points, including around tools; evaluation can inform a runtime policy. It does not represent a measured execution trace or assert that every integration has this coverage.

For example, an isolated process might legitimately reach a payments endpoint while proposing the wrong recipient. Conversely, a URL policy may approve an allowed hostname while lacking control over DNS and the eventual connection. The policy and isolation controls have different inputs and should be tested separately.

Content inspection and programmable rails

LlamaGuard and LlamaFirewall

Meta's LlamaFirewall repository describes a collection of scanners for inputs, agent alignment and code. Its scope is broader than a single text classifier. Inspect which scanner is connected, which messages it sees and what the calling application does with its decision.

Evaluate this approach when untrusted content or generated code needs inspection. A detector's result can be used to stop downstream work, but its existence does not prove that the application checks every payment amount or recipient. Test those requirements at the operation that owns them.

NVIDIA NeMo Guardrails

NeMo supports input, dialog, retrieval, execution and output rails. Its maintainer README explicitly places execution rails around custom action inputs and outputs. A configuration without active rails does not add the intended restrictions merely because the library is installed.

Evaluate NeMo when the application needs programmable conversational flows and tool checks within that runtime. Review the configured flows, custom actions and error behavior. Do not assume a signed OAP receipt or portability of a Colang flow to another host without an integration that provides it.

Guardrails AI

The Guard abstraction validates LLM outputs against configured requirements and handles validation failures. It is useful when downstream code needs structured or validated output. A successful validation result describes that output; the service executing a side effect still needs to apply its own authorization.

When evaluating any content control, use both unacceptable content and legitimate input. Inspect how rejection, transformation and retry are surfaced. A retry that silently changes the user's task can be an application correctness problem even when its final output validates.

Evaluation and runtime controls can overlap

Galileo Agent Control

Galileo's Agent Control announcement documents decorated functions and centrally managed policies. Denial raises ControlViolationError before the governed function proceeds. Evaluators can include custom business logic, regex or model-backed checks; describing the decision basis as exclusively learned behavioral drift would be inaccurate.

For a buyer, the relevant questions are where decorators run, which policy is active, and what happens if the server or configured cache is unavailable. Compare those answers with APort's passport, policy-pack and signed-hosted-decision model. Neither product name proves that an unconnected tool is governed.

Promptfoo and adversarial testing

Promptfoo's red-team documentation covers generating and evaluating attacks against an application. Use that work to find missing policies and to replay regressions after changing a model, prompt, adapter or tool.

Testing and inline enforcement answer different questions. An evaluation can discover that an agent invokes an alternate export route; an operation check must then cover that route if it is forbidden. Keep a legitimate-task set alongside attack fixtures so that rejecting everything is not mistaken for a useful deployment.

Sandboxes and callback frameworks

E2B and Modal Sandboxes provide isolated environments for executing code. NVIDIA NemoClaw documents sandbox and network-policy controls for agent deployments. Compare filesystem access, egress, mounted credentials and lifecycle behavior in the exact configuration you will run.

Do not use a generic cold-start or overhead number as a ranking. Startup, network checks, tool execution and authorization latency are different measurements. A sandbox may prevent an outbound request entirely, or allow a processor endpoint whose individual transactions still need amount and recipient controls.

Google ADK callbacks include a before-tool point where application code can intervene. A callback is an integration opportunity. Its security behavior comes from the checks attached to it and from whether every relevant tool passes through it. That distinction is the same one to test for a custom service wrapper.

Pre-action policy and portable decision evidence

APort Agent Guardrails and OAP

The Open Agent Passport specification defines agent identity and authorization concepts. APort's integrations connect supported runtime hooks to those checks. A passport declares capabilities and limits; a connected verifier evaluates them for a proposed action.

Hosted signed decisions provide a common record across connected frameworks. Local/offline guardrails have a different persistence and signing boundary. Neither mode makes an editable hook or an unguarded alternate path impossible to bypass. The runtime must protect its configuration and honor the result.

The March 20, 2026 Before the Tool Call paper reports a measured median authorization latency of 53 ms (N=1,000). This is the study measurement recorded in APort's public research summary, not a service-level guarantee or an end-to-end latency budget for your application. Measure the complete connected path, including network and tool time, before setting a production budget.

Microsoft Agent Governance Toolkit

The Microsoft repository describes policy enforcement, agent identity, execution controls and framework integrations, and labels its current release public preview. It is a relevant option to evaluate alongside APort for policy at tool boundaries.

Compare the deployed adapter, policy inputs, enforcement result and audit format. Shared use of identity or signed records does not establish OAP interoperability. Require a demonstrated mapping before assuming that a policy or credential from either system works in the other. No Azure preference or production support guarantee follows simply from repository ownership.

Application-owned authorization

A payment service can enforce its own amount and recipient restrictions. A document API can enforce resource-level permissions. Those controls may already satisfy the requirement. A separate agent policy is useful where it adds missing scope or shared evidence, rather than duplicating an existing check without an identified gap.

If you implement the boundary yourself, place the check immediately before dispatch, pass the same normalized arguments to both verifier and tool, and prevent the caller from choosing a weaker policy or enforcement mode. Treat retries and background jobs as additional call sites to examine.

A shortlist by decision boundary

NeMo and Galileo should not be described as evaluation-only tools. Product boundaries overlap. If an existing control covers the action and provides the evidence you need, an additional service may add operational cost without closing a gap.

How to pick

Start with a representative task, not a product ranking. A customer-facing assistant may need content validation and API authorization. A coding agent needs resource isolation as well as checks on commands, files and repository changes. A payment agent needs transaction rules even when it runs inside a sandbox.

These are starting points inferred from the linked documentation, not exclusive assignments or performance rankings. Compare deployment effort as well: who owns policy updates, how configuration is protected, which logs leave the environment, and which failure mode the operator accepts.

Why we built APort at the action layer

APort's owned payment evidence tests a specific proposed-action boundary. The September 18, 2026 Vault paper reports, at Levels 2 to 4 across both replay tracks, unpermitted transfers in 140 of 76,842 completed model-alone evaluations and 0 of 69,297 guarded evaluations. Across 68,970 matched model, prompt and track triples, the counts are 105 and 0.

The distinction matters: the model may request a prohibited transfer while the tool wrapper rejects it. The result supports that architecture under the tested policies. It does not establish that all prompt injections are blocked, that every runtime is covered, or that a deployment has no false denials. The study has no benign-workload evaluation.

The earlier Vault CTF report and Before the Tool Call paper remain useful background. They must not be described as a matched experiment with identical prompts and only one changing variable across policy levels. Use the newer benchmark reading guide to keep cohorts and outcome definitions separate.

Four questions to ask during a demo

First, ask the demonstrator to submit a permitted call and a nearly identical forbidden call. Changing only the target repository, file root or payment recipient makes the policy distinction visible. A broad rejection of every call proves little about usefulness.

Second, inspect the input that reaches the authorizer. A tool name without its target or arguments cannot prove a target-specific restriction. In the MCP allowlist example, server and tool scoping are tested explicitly; arbitrary business rules inside tool arguments still need their own enforcement.

Third, disconnect the verifier in a test environment. An infrastructure failure is different from a policy denial. Record whether the runtime blocks, retries or continues, and choose that behavior deliberately.

Finally, inspect the record after execution. A signed OAP deny in report-only mode remains a deny even though the runtime may continue. Do not turn it into an allow to make a dashboard look consistent.

Keep containment and evaluation in the design

An authorization policy checks the inputs it receives. It cannot substitute for operating-system isolation or trustworthy network enforcement. The web-fetch boundary is a concrete limit: approving a URL does not prove which IP address a later fetch will contact.

Evaluation helps find missing policies and regressions across runs. Runtime policy checks apply those restrictions when an action is proposed. Test the combined system, including legitimate work that should remain possible.

Start with a call you can inspect

The Claude Code hook walkthrough includes a harmless allow and a denied fixture read. Hosted audit is a separate setup choice; a local hook test does not produce a signed hosted receipt.

The Team Pilot scope is available for teams reviewing hosted decisions and rollout ownership.

Install my guardrail and test one tool boundary before adding the next framework.