What is a Policy Rule?

Rules are the atomic unit of policy. Each rule answers a precise question: "When an agent tries to call this tool with these arguments, what should happen?" This granularity is essential because blanket allow/deny decisions are rarely sufficient. You might want to allow an agent to create Stripe charges under £100 but deny charges above that threshold — that requires a rule with a condition, not a binary permission.

Rules follow a match-then-act pattern familiar from firewall rules, iptables, and security group configurations. When a tool call arrives, PolicyLayer looks up the entry for that tool, evaluates its conditions, and applies the outcome. This deterministic evaluation model means you can reason about policy behaviour without running the system — critical for security review and compliance.

The expressiveness of rules comes from combining per-tool entries with argument conditions. A rule can target a single tool by name, or every tool on the server through the all-tools section. Conditions in require and deny_if can compare argument values against literals, check types, validate string patterns, and enforce numerical bounds. This covers the vast majority of real-world policy requirements without requiring a full programming language.

In PolicyLayer, each rule is a per-tool entry within the policy JSON document, specifying conditions the call's arguments must satisfy (require), conditions that deny the call (deny_if), and quota limits (limits). Tools can also be hidden entirely, and a document-level default of allow or deny covers any tool without an entry. Rules are authored in the dashboard's visual policy builder — each tool gets Allow, Deny, Hide, or Custom — with a Raw JSON view for inspecting the exact document.