What is a Policy Violation Event?
A policy violation event is emitted when a tool call is denied by policy, signalling that an agent attempted an operation outside its permitted boundaries. These events can trigger alerts, webhooks, or incident response workflows.
WHY IT MATTERS
A denied tool call is not just a log entry — it is a signal that an agent attempted something it should not have. In a well-configured system, violations are rare and significant. They might indicate a prompt injection attack, a misconfigured agent, a compromised credential, or a legitimate edge case that the policy did not anticipate. Each violation deserves attention.
Policy violation events bridge the gap between passive logging and active monitoring. While audit logs require someone to query them, violation events push notifications to the people who need to respond. A Slack alert when an agent attempts to delete a production database. A PagerDuty incident when payment amounts exceed policy limits. A webhook to a security orchestration platform when an agent repeatedly violates the same policy.
The pattern of violations is often more informative than individual events. A single violation might be an agent adapting to a constraint. Repeated violations of the same policy might indicate a systematic issue — an agent that was not updated after a policy change, or an adversarial prompt probing boundaries. Violation events enable this pattern analysis by feeding into monitoring and analytics systems.
HOW POLICYLAYER USES THIS
Intercept emits a structured policy violation event for every denied tool call. The event includes the full decision log entry (matched rule, conditions, arguments) plus additional metadata: the violation severity (configurable per rule), the number of recent violations from the same agent, and the policy file and line number of the denying rule. Events can be forwarded to webhooks, written to a dedicated violation log, or emitted as structured events for consumption by monitoring platforms.