Rules and policies

Rules describe what to check. Policies decide where those checks run and whether a match is audited or blocked.

Open Rules to review checks, then Policies to choose where they run. A template or saved custom rule does nothing until it is attached to an enabled policy whose scope matches the proposed call.

Set up your first policy

On Rules, choose a check that fits the evidence your integration supplies. You can also create your own Python rule or configured LLM judge.
On Policies, create a policy in Audit mode. Scope it to the environment, agent, and tool you want to review.
Add the rule to that policy. Check that the policy is enabled and the proposed call falls within its scope. An empty policy has nothing to evaluate.
Run a supported, non-streaming tool proposal that supplies the evidence the rule needs. Inspect the Guard finding and its linked trace. A nonmatch, skip, abstention, or unavailable evaluation is not a would-block finding.
Review false positives before changing the policy to Enforce where your plan allows it. Handle st.GuardBlocked in the provider path or check decision.action for a direct tool call.

For a fixed example of the same rule under both modes, try the no-login demo. It uses sample data, not a live Guard evaluation.

Rule templates

The catalog contains Static checks and LLM judges. Custom Python rules express application-specific conditions. Each type needs different evidence:

Type	Use it for	Evidence boundary
Static check	Fixed checks, such as malformed arguments or arguments that contradict the supplied tool schema.	Requires explicit adapter evidence. Missing, unsupported, or suppressed schemas are skipped. CLI hooks do not supply the exact schema needed for schema checks.
LLM judge	A written instruction that needs judgment about the proposed action and available context.	Current tool call uses current input and available evidence. Available history is bounded and may be incomplete; an uncertain judge can abstain.
Python rule	A condition you write for your own tool arguments, or a call to your authenticated decision service.	Runs only when the isolated runner and admission are available. The current tool output does not exist before execution.

Suppressed tool arguments and schemas are excluded from Guard transport. A missing field is not proof of a violation. See the rules catalog for the built-in checks and Python rules for input and code examples.

Built-in static checks, Python rule runs, and LLM-judge evaluations have separate allowances. Creating or saving a custom rule consumes no runs; saved-rule count limits still apply. See current pricing and allowances and how usage is counted.

The dashboard is the source of truth for the templates available to your organization and the inputs each template evaluates. See the rules catalog for the launch-facing categories.

For the launch quickstart, choose a rule shown for your organization and attach it to an audit policy scoped to the sample agent and environment. The lookup_order sample produces a supported proposal and trace; a finding requires evidence that meets the selected rule. No matching active rule means no would-block finding.

When Install starter pack is available on Rules, it creates an audit policy with the versioned starter rules. Repeating installation reuses that policy. Review its scope on Policies before relying on its findings.

Policy scope

Attach a policy to the organization, selected agents, environments, and tools. Only proposed tool calls matching that scope are evaluated by the policy. Keep the first scope narrow enough to review each finding.

Audit

Use audit mode first. When a rule matches:

The provider response is allowed through.
The top-level Guard wire result remains allow.
The evaluated policy match is recorded.
The trace gets a guard:would-block:<tool> child span.

Audit gives you evidence without changing agent behavior.

Skipped and abstained evaluations create no finding. Service failures and exhausted allowances are unavailable evaluations and follow the configured failure policy. A fail-closed unavailable decision can stop execution, but it is not a policy match.

Enforce block

After reviewing audit results, switch a policy to enforce when your plan allows it and matching calls should stop. A blocked supported provider proposal raises st.GuardBlocked before the normal dispatch loop receives it. @st.tool observes an executed Python function; it does not block a direct call by itself.

try:
    response = client.messages.create(...)
except st.GuardBlocked as blocked:
    log(blocked.reason)
    return safe_fallback()

Failure behavior

Guard fails open when no policy decision is available by default. Use the optional fail-closed setting for actions that must stop on explicit degradation. A failed or timed-out Python run after dispatch consumes an admitted run; creating or saving a rule does not. Current allowances and saved-rule limits come from the pricing page. See manual checks for result fields and failure behavior.