Policy attributes and effects

Read a real request first

A rule can be valid and still never match the intended action. Inspect an observed decision’s model, source, tool, target, environment, and attributes before choosing conditions. Do not invent a tool spelling from an agent’s marketing name.

Common context

Context	How to use it
x-kastra-attr-tool	Canonical tool name supplied by a hook or gateway
x-kastra-attr-tool-input	Tool arguments/text in the integration’s supported representation
File-path attributes	Prefer declared structured targets; inspect the actual key/value from your hook
model / model prefix	Scope to the integration’s actual model identifier
environment	Policy scope uses the environment contract, often a name
principal / customer	Distinguish caller claims from server-bound identity
Proxy output fields	Use the supported output tool-call schema and post-inference trigger

Supported ingress canonicalizes aliases, but this does not make all surfaces semantically identical. A field available to one hook may be absent on another. Unknown or contradictory attribute spellings must not silently become an assumed match.

Effects and triggers

Deny and HOLD govern supported pre-action flows. Post-action hooks record events after execution. Proxy post-inference rules evaluate supported model output before the application dispatches tools. Content scan, hide, rate-limit, and spend-cap effects have their own surface and entitlement limits.

Pattern boundaries

String matching does not parse shell semantics. A mention of a protected path is not necessarily a mutation of that path. Prefer structured file/tool targets where available, preserve editor exemptions, and test both a known blocked case and a benign near-match with the actual evaluator.

Verify a policy change

Check the resulting decision’s matched rule, policy revision, and outcome. Repeat in the intended environment and integration. Do not equate a generated rule’s self-test with exhaustive threat detection.