What is a YAML Policy?

Policy-as-code is a well-established practice in infrastructure (Terraform, Kubernetes admission controllers, OPA/Rego), but AI agent governance has largely relied on system prompts and hope. System prompts are not enforceable — they are suggestions to the model, not hard constraints. A determined or hallucinating agent can ignore them entirely.

YAML policies solve this by moving enforcement out of the model and into infrastructure. A YAML policy is evaluated by Intercept at the proxy layer, meaning it cannot be bypassed by the agent regardless of what the model decides to do. The policy is a hard boundary, not a suggestion.

YAML was chosen deliberately over JSON, Rego, or custom DSLs. It is human-readable, widely understood by developers and operations teams, natively supported by every CI/CD system, and trivially diffable in version control. A security engineer who has never worked with AI agents can read a YAML policy and understand exactly what it permits.

Each policy file targets a specific MCP server and contains a list of rules. Each rule targets a tool (or pattern of tools), specifies conditions on arguments, and declares an action: allow, deny, or log. This structure maps naturally to how teams think about permissions — "allow read operations on the database server, deny writes except to the staging schema."

YAML policies are the core configuration primitive in Intercept. Each policy file lives alongside your project configuration, is version-controlled in git, and is loaded by Intercept at startup (and reloaded on change via hot-reload). Intercept parses, validates, and indexes policies for fast lookup during tool call evaluation. The format supports server-level defaults, tool-level overrides, argument conditions with comparison operators, and glob patterns for matching tool names.