Author and test policies

Start with an action and an environment

Choose the action you want to govern, the integration that observes it, and the environment where the rule should apply. Inspect a representative decision before authoring: use its real model, tool name, path, and arguments rather than a guessed schema.

Policies are versioned sets of rules. Rules can use scoped predicates and structured conditions. Their effects include deny, hold, monitor, redact, hide, rate limits, and spend caps, with supported effects varying by surface and plan.

Choose an effect for the control objective

Objective	Effect to consider	Read before enabling
Stop a disallowed action	Deny	Integration and trigger scope
Involve an authorized reviewer	HOLD	Approval lifecycle and timeout behavior
Observe a matched condition	Monitor or deliberate shadow evaluation	Shadow mode
Remove supported sensitive spans in proxy content	Redact	Detector and content-surface coverage
Restrict MCP discovery	Hide, paired with the required call-time control	Tool catalogs and permissions
Apply a windowed request or spending threshold	Rate limit or spend cap	Identity, concurrency, and metering scope

Select the surface and trigger before assuming an effect applies. Monitoring a match and blocking an action are different rollout outcomes.

Prefer structured targets

For a protected file, match the declared file path from a supported Write/Edit operation. A shell command that mentions a path in a comment, quoted string, or diagnostic output is not necessarily modifying it. Broad command regexes can create approval noise and still miss real mutations.

Tool attributes are canonicalized on supported ingress paths, but action schemas remain different. Attribute reference explains hook, proxy, and MCP context.

Draft and validate

Use the console editor, a safety pack, an AI draft, or policy as code. Test an action that should match, a nearby action that should not, and a known observed case. A model-generated test set is not a proof over all possible inputs.

Observe, then activate

Review the rule in shadow mode before enabling enforcement. Check the policy revision and environment before activation. Use an explicitly narrow test rule for an initial deny/HOLD check; do not run destructive commands to prove that a detector works.

Rule interaction

Rule priority and effect semantics matter. Test the combined policy: for example, a request below a rate limit must still reach a later blocking rule. Check the deployed release’s behavior with your acceptance cases. Billing observe-only can withhold enforcement even when a policy matches.

Keep a change record

Record the rule’s purpose, owner, representative matching and non-matching cases, selected environment, reviewed revision, and rollback revision. Have the designated reviewer assess scope changes before activation. This is an operating practice your team defines; AI suggestions and generated examples do not replace that review.

Policy as code · Pilot acceptance criteria