What is Policy Linting?

Linting catches the mistakes that are easy to make and hard to spot in review. A YAML indentation error that silently changes policy structure. A condition that references a misspelled argument name. Two rules with identical conditions but different actions, making the second unreachable. A numeric comparison against a string value that will always evaluate to false. These are the kinds of errors that pass code review because YAML looks correct to the human eye but behaves incorrectly at runtime.

Policy linting is particularly valuable because policy errors fail silently in many cases. A rule with a typo in the tool name simply never matches — no error, no warning, just an unprotected tool that the policy author thought was covered. A condition with a wrong operator allows operations that should be denied, with no indication until someone checks the audit trail (if anyone does). Linting surfaces these issues before the policy is deployed.

The linting process analyses policies statically — without executing them or processing actual tool calls. This makes it fast (milliseconds for a full policy directory), safe (no side effects), and suitable for CI/CD integration. A linting step in your policy deployment pipeline catches errors as early as possible, before they can affect agent behaviour.

Intercept includes a built-in linter that analyses policy files for: YAML syntax errors, schema violations, unreachable rules (shadowed by higher-priority rules with broader conditions), conflicting rules (same match criteria, different actions, no priority difference), type mismatches in conditions (comparing a number to a string), references to unknown tools (when server schemas are available), and deprecated syntax. The linter runs as a standalone command (intercept lint) and as part of the startup validation. Exit codes make it suitable for CI/CD gate checks.