Live betaAgent guardrails

Set boundaries for what your agents can do.

Check tool calls before they run. Block repeats, ask for approval, or redact sensitive results. Every decision gets a record.

Book a demo See how it works
Guard check run_2088Sample data
issue_refundorder_id=1042 · amount=180.00 · 2nd call in 10 min
Denyrefund.repeat-window v1
A policy decision

Same timeout. This time, no second refund.

Policy-protected run run_2088Example workflow · sample data
  1. Repeat callissue_refund(order_id=1042, amount=180.00), the second attempt after a timeoutBefore the tool runs
  2. MatchSame order_id + amount within 10 min, scope refund-agent, all sessionsrefund.repeat-window v1
  3. DecisionBlock the repeat call and record why.Deny
  4. Linked findingF-218: Refund retried after an issue_refund timeout12 runs
Investigation evidence

pay_req_7731: refund.completed at +12.9 s. The payment succeeded before the tool timed out. Guard counts calls; payment telemetry confirms the result.

Code fix

PR #482: add an idempotency key and check payment status before retrying.

See both fixes
The rule came from run_1042. This preview shows a later run, after the rule was activated.
Where Guard checks

Before the call. Before the agent reads the result.

Guard checks in your framework’s tool hook
Agent picks a toolpre_tool
Allow, deny, ask or rewrite the callRefund rule
Tool executespost_tool
Rewrite the result, e.g. redact PII
Agent reads the result
Works withClaude Code hooksOpenAI Agents SDKLangChainGoogle ADKFastMCP
Finding detection

Scheduled investigations find patterns in past runs. They raise findings for your team to review.

Guard enforcement

An active rule checks live tool calls: allow, deny, ask, or rewrite. Each decision links to the run.

guard decisions · refund-agent · sample data
pre_toolBash rm -rf ./exportsrule no-destructive-shelldeny
pre_toolissue_refund order_id=1042 amount=180.00rule refund.repeat-window v1: same order_id + amount within 10 mindeny
pre_toolissue_refund order_id=2210 amount=950.00rule refund.approval-limit: above $500 goes to a personask
post_toollookup_customeremail in result, replaced with [REDACTED:email]rewrite
pre_toolsearch_orders customer=8812no rule matchedallow
Every decision is recorded alongside the agent trace.
You approve the rule

From a finding to an active rule.

CtrlB proposes and tests the rule. Your team chooses the scope and turns it on.

  1. Finding reviewedYour team accepts F-218Your approval
  2. Condition definedSame order_id + amount within 10 minAutomatic
  3. Scope selectedrefund-agent, all sessionsYour approval
  4. Replay validatedCaptured calls from refund-timeouts v3Automatic
  5. Apply Guard ruleActivates refund.repeat-window v1Your approval
  6. Later call checkedIn the tool hook, before it runsAutomatic
  7. Decision recordedLinked to the run and the findingAutomatic
Action rule refund.repeat-windowProposed from F-218
Tool
issue_refund
Match on
order_id + amount
Window
10 min
Scope
refund-agent, all sessions
On match
Deny
Policy replay on refund-timeouts v3
  • Repeat attempts, same order and amountDeny expected deny
  • Partial refunds, different amountAllow expected allow
  • Retry after the window closedAllow expected allow

No legitimate refunds in the case set would be denied.

Preview with sample data
Version history refund.repeat-windowSample data
  1. v1ActiveApplied from F-218 by Platform on-call, Oct 27
  2. draftReplay passedProposed from F-218, validated on refund-timeouts v3
Review a version, or roll back to the one before it. Each change gets its own version.
Rule scope

Which repeats should the rule catch?

Switch scope to see how the same five calls are handled.

Five calls · order 1042Example workflow · sample data

Deny identical tool calls in the same session. A new session starts fresh.

  1. 0:00 Session A$180 refundFirst attemptAllow, first call
  2. 0:31 Session A$180 refundIdentical call, same sessionDeny
  3. 4:10 Session B$180 refundNew session, extra argumentAllow
  4. 6:02 Session C$40 partial refundPartial refund, different amountAllow
  5. 14:20 Session D$180 refundOutside the 10 min windowAllow

This rule counts attempts. Check payment telemetry to see whether a refund completed.

Compare both scopes in a table
Five refund calls for order 1042Sample data
TimeCallSession-localArgument-keyed
0:00Session Aissue_refund(1042, 180.00)First attemptAllow, first callAllow, first call
0:31Session Aissue_refund(1042, 180.00)Identical call, same sessionDenyDeny
4:10Session Bissue_refund(1042, 180.00, note="retry")New session, extra argumentAllowDeny
6:02Session Cissue_refund(1042, 40.00)Partial refund, different amountAllowAllow
14:20Session Dissue_refund(1042, 180.00)Outside the 10 min windowAllowAllow
Policies

Choose what to check.

AllowDenyAsk a personRewrite
  • Tool allow listsWhich tools an agent may call
    Where
    pre_tool
    On a match
    Deny, or ask a person
    Recorded
    Rule version and the blocked call
  • Sensitive data and PIIPII in tool arguments and tool results
    Where
    pre_tool and post_tool
    On a match
    Deny the call, or rewrite the result to redact it
    Recorded
    Decision and a redaction marker in the result
  • Repeated calls and loopsThe same tool and arguments in one session
    Where
    pre_tool
    On a match
    Deny, or ask a person
    Recorded
    Matched call count and the session
  • Argument-keyed time windowsChosen arguments across sessions, within a window
    Where
    pre_tool
    On a match
    Deny, or ask a person
    Recorded
    Matched key, the window and the earlier call
  • Finding-linked action rulesA condition proposed from a finding
    Where
    pre_tool
    On a match
    Allow, deny, ask or rewrite, as configured
    Recorded
    Link to the finding and its frozen case set
Audit trail

See what Guard blocked, and why.

Finding F-218 per daySample data
  • Repeat attempts
  • Denied by Guard
  • Legitimate refunds allowed
Table view
Finding F-218: repeat refund attempts per day, sample data
DayRepeat attemptsDenied by GuardLegitimate refunds allowed
Oct 21903
Oct 221104
Oct 23803
Oct 241005
Oct 251204
Oct 26903
Oct 27 · Rule v1 active10104
Oct 28993
Oct 29885
Oct 30664
Oct 31 · PR #482 deployed223
Nov 1114
Nov 2114
Nov 3003

Sample data: denies begin when v1 is activated; attempts fall after PR #482 deploys. The trend alone does not establish cause.

Decision recordSample data
Rule
refund.repeat-window v1
Matched condition
Same order_id + amount within 10 min
Decision
Deny
Tool call
issue_refund(order_id=1042, amount=180.00)
Agent run
run_2088
Earlier call
31 s before, same session
Finding
F-218: Refund retried after an issue_refund timeout
Operations

How Guard runs in production.

  • In the request pathGuard runs in your framework's tool hook. Every check happens before the call executes, or before the agent reads the result.
  • Versioned configurationEach Apply Guard rule creates a version with its scope, who applied it and when. Earlier versions stay for review and rollback.
  • Failure behavior per ruleWhat happens if a check cannot complete is part of each rule's configuration. You set it when you apply the rule.
Keep going
FAQ

Common questions

Where are policies enforced?

In the request path, inside your framework's tool hook. Guard checks a tool call before it executes and handles the result after it returns. It works with Claude Code hooks, the OpenAI Agents SDK, LangChain, Google ADK and FastMCP.

How are policies configured?

Choose a rule type, condition and scope, then select Apply Guard rule. For time windows, also choose the argument key and duration. Each activation creates a version you can review or roll back.

How much latency does a check add?

Guard runs in the request path, so every check adds time to the tool call. How much depends on the rules in scope. Measure it on your own workload during the beta.

How is data handled?

Rewrite rules can redact sensitive data from a tool result before the agent reads it. Decision records are written to your lake, next to the agent trace.

How do Guardrails relate to Evals?

Before you apply a rule, Guard replays the frozen case set's captured calls through it and compares the decisions with the expected outcomes. After you apply it, the finding's trend shows what happened next.

Live beta

Put your first Guard rule to the test.

Live beta. From $499/month, plus usage.

Book a demo See how it works