Guard starter rules
Start with an audit policy and review its findings before enabling enforcement. Rules stay inactive until an enabled policy selects them.
LLM judges
Each judge needs evidence about the current proposed action. Missing authorization in a partial history is not evidence that an action is unauthorized.
| Judge | Evidence required for a finding |
|---|---|
| Dangerous operation | A destructive effect against an identified protected resource outside the authorized task. |
| Data exfiltration | Sensitive material, an actual proposed transmission, and evidence that its destination is unauthorized. |
| Explicit boundary violation | An applicable instruction and a current action that contradicts it. |
| Following injected instructions | Instructions from tool or retrieved content, a conflicting trusted instruction, and a proposal carrying out that conflict. |
| Contradicted tool argument | A target or value established for the task and a conflicting proposed argument. |
Uncertain cases abstain. A prior judge's finding does not establish that the current action is wrong. Model evaluation adds latency; scope policies to the tools that need these checks.
Static checks
Static checks apply fixed conditions to explicit adapter evidence.
| Check | Evidence required for a finding |
|---|---|
| Malformed tool arguments | The provider adapter records a JSON parsing failure or a nonobject argument shape. |
| Arguments violate tool schema | Complete arguments contradict the exact schema supplied for this tool in the current request. |
Schema checks cover required fields, types, enums, and basic bounds. Missing, ambiguous, suppressed, or unsupported schemas are skipped. External schema references are never fetched. Fields named raw_arguments or value do not imply a parsing error.
CLI hooks do not supply an exact tool schema, so schema checks skip that missing evidence. Direct Python function annotations do not substitute for a provider's schema.
Install in audit mode
When starter-pack installation is enabled for your workspace, open Rules and select Install starter pack. Installation creates an audit policy and attaches the versioned rules. Repeating installation reuses that policy.
Review the resulting policy in Policies. You can also attach individual catalog rules to an existing scoped policy. Installation does not enable blocking or change existing policy choices.
Python rules
Use a Python rule for a condition specific to your application or a decision from your authenticated service. Python runs at evaluation time. A rule that calls an external service can depend on that service's changing state.
Python rule runs have their own allowance, separate from built-in static checks and LLM-judge evaluations. See current pricing and allowances and how usage is counted.
Review results
evaluated, skipped, abstained, and unavailable describe different outcomes. Only an evaluated policy match creates a finding. Review unavailable decisions separately from rule precision. See manual checks.