Rules and Policies

Guard ships with proprietary static rules and LLM-judge rules out of the box, plus you can add your own.

import staso as st
from staso.integrations import patch_anthropic

st.init(api_key="...", agent_name="refunds-agent")
patch_anthropic()  # rules and policies are evaluated automatically

There is no SDK configuration for rules — everything is defined in the dashboard and attached to your org, agents, or environments.

Static rules

Fast, deterministic, zero-config. Staso ships a curated library covering the common blast radii:

• Dangerous shell commands (rm -rf /, dd, forkbombs).
• Destructive SQL (DROP TABLE, unscoped DELETE, mass UPDATE).
• Known PII leakage patterns in tool outputs.
• File-system writes to protected paths.

Static rules run in sub-millisecond time and make zero LLM calls. They are always on once your plan includes Guard.

Quota — static_guard_evals_per_month:

LLM-judge rules

Model-based checks for decisions that need semantic understanding:

• Intent drift (is this call consistent with the user's request?).
• Prompt injection and jailbreak detection.
• Hallucinated facts being passed into tools.
• Sensitive-topic guardrails.

LLM-judge rules are slower (a few hundred ms per call) and cost more. Use them for high-stakes tools.

Quota — llm_guard_evals_per_month:

Custom rules

Define your own rules in the dashboard. Each rule specifies: matched tool names, evaluation logic (static or LLM judge), mode (audit or enforce), and the action (block, modify, escalate).

Quota — custom_rules_per_org:

Custom rules run on the LLM-judge counter — they share quota with the managed LLM-judge rules above.

Policies

A policy is a bundle of rules you attach to specific agents, environments, or the whole org. Policies are the recommended way to roll out rule changes — flip a policy instead of editing individual rules.

Quota — policies_per_org:

Managing rules

Rules and policies live in the Staso dashboard under Settings → Guard. Who can edit them is controlled by role-based permissions — see Team and Roles.

Two rule modes matter in practice:

• Audit — the rule fires but the tool call still proceeds. A guard:would-block:* span is added to the trace so you see what would have been blocked.
• Enforce — the rule fires and the tool call is blocked, modified, or escalated per the rule action.

Start new rules in audit mode, check the dashboard for false positives, then flip to enforce.

Plan gating

All of this requires a paid plan. Orgs on no_plan get HTTP 403 on every /v1/guard/evaluate request. See pricing.

Next

• Manual Guard Checks — evaluate rules from custom dispatch code.
• Guard Overview — how the action model works.
• Pricing