Preview draft. Copy and visuals are pending review and may change before launch.

Practice

Privilege escalation detection in runtime monitoring

No design review catches every path to unauthorized privilege in advance. Detecting it after the fact is a distinct, necessary layer — not an admission that prevention failed.

← Back to the library

Governance, Incident Response, and Resilience · Published 2026-09-07

The same end state, reached through very different paths

Privilege escalation is a principal ending up with more access than they were originally granted, whether through a software bug, a misconfiguration, or a deliberate attack chaining together several smaller flaws to reach a broader outcome than any single flaw would allow on its own. The end state looks identical regardless of the cause — an account or process with more authority than it should have — which is exactly what makes detection valuable independent of which specific path led there.

A system of any real size can't rely on preventing every possible path to escalation through design review alone; the surface for these paths grows with the system, and new ones open with every change. This isn't a failure of prevention efforts — it's a recognition that prevention alone is never fully sufficient at scale, on its own.

Watching for the effect, not enumerating every cause

Runtime monitoring for privilege escalation looks for a principal's effective access actually changing unexpectedly — comparing what a principal is supposed to hold against what they're currently able to do, checked on an ongoing basis rather than assumed to stay in sync once granted correctly. This has a real advantage over trying to enumerate every specific escalation technique in advance: it catches the effect directly, regardless of which particular bug, misconfiguration, or attack path actually produced it, including paths nobody had specifically anticipated.