What is an Alert Rule?

Policy enforcement without alerting is like a burglar alarm that locks the door but doesn't sound the siren. The immediate threat is contained — the tool call is blocked — but no one knows it happened. If an agent is repeatedly hitting policy denials, that's a signal. It might be a misconfigured agent, a compromised credential, or a prompt injection attack. Without alerts, these signals go unnoticed until someone manually reviews the logs — which, at scale, means they go unnoticed entirely.

Alert rules bridge the gap between enforcement and response. They define the conditions under which a policy event should trigger human attention. A single denial might be normal — an agent tried something outside its scope and the policy caught it. But ten denials in a minute from the same agent is an anomaly that demands investigation. An access attempt to a tool marked as critical — like a production database admin interface — might warrant an alert regardless of whether the call was allowed or denied.

Effective alert rules balance sensitivity and noise. Too many alerts and the security team develops alert fatigue, ignoring genuine threats. Too few and critical events slip through. The best approach is tiered: informational alerts for policy events that should be logged, warning alerts for unusual patterns that merit review, and critical alerts for events that require immediate response.

Intercept's structured decision logs provide the raw events that alert rules operate on. When forwarded to a SIEM or monitoring platform, these events can trigger alerts based on configurable conditions — denial frequency thresholds, specific tool names, agent identities, or policy rule matches. Organisations define alert rules in their SIEM or alerting platform (PagerDuty, Opsgenie, Slack webhooks) using Intercept's structured log fields as the trigger criteria. This separation keeps Intercept focused on enforcement while leveraging existing alerting infrastructure.