What is Alert Escalation?

Not all policy violations are equal. An agent being denied access to a non-critical tool is a routine event — the policy worked as designed. An agent repeatedly attempting to access production infrastructure tools after business hours, despite being denied, is a potential security incident. These events need different response levels, and alert escalation ensures they get them.

Escalation typically follows a tiered model. Tier 1: routine events logged and reviewed in batch — a Slack notification to a monitoring channel. Tier 2: unusual patterns that need investigation within hours — a ticket created in the incident management system. Tier 3: critical events requiring immediate response — a page to the on-call security engineer, potentially triggering automated containment.

For AI agents, escalation criteria should consider the blast radius. A denial on a read-only tool is lower severity than a denial on a tool that can modify data. Repeated denials suggest something systematic — either a misconfigured agent (operational issue) or an attack (security issue). The escalation path should route operational issues to the engineering team and security issues to the security team, with clear criteria for distinguishing between them.

Intercept's structured decision logs include the severity context needed for escalation — tool name, policy rule, decision type, and agent identity. When forwarded to alerting platforms (PagerDuty, Opsgenie, Slack) via SIEM or direct integration, organisations configure escalation policies based on these fields. For example: denials on tools tagged 'critical' escalate to Tier 3 immediately, while denials on general tools only escalate if the count exceeds a threshold within a time window. This leverages existing incident management infrastructure rather than building escalation logic into the proxy.