✓ Human-authored analysis; AI used for formatting and proofreading.
The Okta support system breach in 2023 was caused by time.
Originally, support access was tightly scoped. Access was temporary. Logs were reviewed. The purpose was clear. Intent was strong and recent.
Over months and years: support tools gained more features. Access paths multiplied. Temporary access became semi-permanent. Legacy accounts remained active. Documentation lagged reality. Engineers changed roles or left.
No single change was malicious or single decision was wrong. Each action was locally reasonable.
But ORDER DECAYED. A support session artifact was exposed that granted broader access than originally intended. No invariant enforced scope, time, or context. The system still worked, but it no longer reflected its original intent.
Attackers obtained the artifact. Used legitimate access paths. Operated inside trusted systems. They didn't break in. They STEPPED INTO ENTROPY.
Entropy in security is not randomness
Randomness is unpredictable. You can't forecast what happens next.
Entropy in security is the OPPOSITE. It's directional and predictable:
Structure will decay
Constraints will weaken
Trust will expand
Context will be lost
Exceptions will accumulate
Ownership will blur
You can PREDICT that these will happen. You just can't predict WHEN or WHERE: only that they WILL. Given enough time, every system drifts from its intended state toward a less constrained, less safe state.
This isn't randomness. It's a thermodynamic-style force: without continuous energy input (enforcement), order degrades. The question isn't WHETHER entropy appears. It's how fast and where.
The universal breach pattern
Every major breach follows the same four-step sequence:
Step 1: Clear intent (low entropy). The system is designed with purpose. Access is scoped. Boundaries are firm. Ownership is known. Documentation is current.
Step 2: Entropy accumulates. Features grow. Paths multiply. Temporary access becomes permanent. Legacy remains active. Documents lag. Engineers rotate. No single change is wrong. Each is locally reasonable.
Step 3: A weak door emerges. An artifact is exposed. A scope is exceeded. A combination of individually-safe changes creates an unsafe path. No invariant prevents it. The system still works, but it no longer reflects its original intent.
Step 4: Attacker steps into the gap. Using legitimate paths. Using valid credentials. Operating inside trusted systems. Nothing technically anomalous. The breach uses the system as designed. It's just that the design has decayed.
Clear intent → Exceptions accumulate → Context lost → Controls weaken → BREACH
↑ |
└────────── Each step was locally correct ─────────────────────────┘
Why detection doesn't save it
Security tools saw: valid support workflows. Legitimate access paths. Normal-looking activity.
The problem wasn't ANOMALY. The problem was LOSS OF CONSTRAINT. Detection tools look for things that are technically wrong. Entropy produces things that are technically RIGHT but semantically DANGEROUS. Every API call is authorized. Every path is legitimate. Every credential is valid. The breach is in the MEANING of what's happening, not the mechanics.
This is why the Okta breach and breaches like it evade sophisticated detection. There's nothing to detect. The attacker used the system correctly. The system was just no longer correct.
Why entropy is emergent
Entropy satisfies every property of emergent behavior:
✅ Not designed explicitly — nobody designs credential sprawl
✅ Not attributable to one component — no single service caused the drift
✅ Arises from interactions over time — each subsystem evolves independently
✅ Only visible at the system level — each component looks fine locally
No engineer designs privilege creep, trust expansion, policy drift, or forgotten exceptions. Yet they appear RELIABLY in every system that operates long enough. They emerge from the normal operation of distributed systems.
Distributed systems AMPLIFY entropy because of their fundamental properties:
Partial failure: Some components change while others don't
Asynchronous communication: Components don't have a shared clock
Eventual consistency: State diverges between nodes
Independent ownership: Different teams evolve different subsystems
Independent evolution: Subsystems change at different rates
Each subsystem behaves correctly LOCAL to itself. Service A, B, C and D works. The GLOBAL system, the combination, drifts toward less constraint, safety and alignment with original intent.
Local correctness does NOT guarantee global safety. This is the fundamental emergence property that produces entropy.
Time is the enabling variable
Entropy is driven by TIME:
Day 1: "Grant temp access for the deploy" (reasonable)
Day 30: Exception undocumented (oversight, not malice)
Day 90: Original owner left the team (normal turnover)
Day 180: "That's how it's always been" (institutional forgetting)
Day 365: Breach threshold crossed (entropy accumulated)
No single day was the mistake. The breach is the cumulative result of 365 days of normal operation. Time doesn't attack the system. It ENABLES the drift that attackers exploit.
Time works FOR attackers: drift, entropy, and trust expansion accumulate silently. Attackers can wait. Waiting is cheap.
Time works AGAINST defenders: context decays, response latency grows, enforcement weakens. Defenders can't wait. Every day without enforcement is a day entropy advances.
Time BIASES the system toward failure unless continuously regulated. Because time is the medium through which structure degrades without energy input to maintain it.
Emergent failure — not negligence
This class of breach has a specific property: NO SINGLE HUMAN MADE A MISTAKE.
Person A: "Grant temp access" → Reasonable given the deploy deadline
Person B: "Keep it, deploy urgent" → Reasonable given the outage
Person C: "Skip review this time" → Reasonable given the workload
Person D: "Reuse old path" → Reasonable given the time pressure
Combined result: BREACH
Who is at fault?
No one. Each action was locally correct.
The failure is EMERGENT from their combination over time.
This is the same failure mode seen in aviation accidents, industrial disasters, and financial system collapses. The investigation finds no single root cause. Each decision was reasonable. The failure emerged from their INTERACTION over TIME.
Blaming humans misses the mechanism. The mechanism is entropy. Entropy operates regardless of human careful, training or good intentions.
Why training, checklists, and documentation can't fix it
If breaches were caused mainly by MISTAKES:
→ Training would fix them (teach people the right thing)
→ Checklists would work (ensure nothing is forgotten)
→ Better reviews would suffice (catch errors before deploy)
But entropy:
→ Cannot be trained away (it emerges from normal operation, not from errors)
→ Cannot be reviewed away (each review is point-in-time; entropy continues after)
→ Cannot be documented away (documentation itself drifts from reality)
Training addresses human errors. Entropy isn't a human error. It's a structural force. You can train every engineer perfectly and entropy still accumulates. Because entropy comes from TIME acting on DISTRIBUTED SYSTEMS, not from humans making mistakes.
The missing invariant
In the Okta breach, the invariants that would have prevented exploitation existed IN PEOPLE'S HEADS:
"Support access must be time-bounded, scoped, and non-replayable"
"No support artifact may access production identity systems"
"Temporary access must expire after the session ends"
Each was understood. None was ENFORCED. Entropy operates between the gap of understood and enforced. Understanding decays (people leave, forget, rotate). Enforcement doesn't (machines don't forget, rotate or get tired).
The fix is to ENCODE invariants as machine-enforced constraints that evaluate CONTINUOUSLY against actual state. The invariant doesn't exist in someone's head. It exists in the catalog, evaluated by the kernel, producing verdicts that pipelines act on.
Entropy must be continuously counteracted
WITHOUT continuous enforcement: WITH continuous enforcement:
System drifts Invariants hold
████████ ════════════════════
██████ ════════════════════
████ ════════════════════
███
██ Continuous enforcement
█ blocks drift
(entropy wins)
Intent → forgotten Intent → encoded as invariant
Context → lost Context → enforced continuously
Constraints → eroded Constraints → machine-verified
Entropy is INEVITABLE. Enforcement makes it IRRELEVANT.
The parallel is thermodynamic: a refrigerator doesn't eliminate heat. It continuously counteracts heat transfer. Without the refrigerator running, the interior warms to ambient. Without continuous enforcement running, the system drifts to ambient entropy.
The enforcement must be CONTINUOUS because entropy is continuous. Point-in-time checks (annual audits, quarterly reviews, monthly scans) are the security equivalent of turning the refrigerator on for one hour per day and expecting the food to stay cold.
Entropy as architectural requirement
If entropy is emergent and inevitable, then the architecture must be designed to counteract it:
Encode intent as invariants. What lives in people's heads must be externalized as machine-evaluable predicates. People forget. Machines don't.
Evaluate continuously. Point-in-time checks leave gaps. Entropy fills gaps. Every deployment evaluation + periodic drift checks minimize the window entropy operates in.
Enforce mechanically. Human enforcement degrades under fatigue, turnover, and workload. Mechanical enforcement doesn't. The kernel evaluates the same way at 3 AM as at 10 AM.
Catch combinations, not just individuals. Entropy produces unsafe COMBINATIONS of individually-safe components. Compound controls (chain controls evaluating multi-asset patterns) catch the emergent failures that single-resource checks miss.
Make time a variable in evaluation. Credentials that were safe on day 1 may be unsafe on day 180. Time-bound predicates in the catalog catch the temporal dimension of entropy. "This credential must have been rotated within N days" evaluates the TIME SINCE the last state change, not just the current state.
For your organization
1. Accept that entropy is inevitable. Stop treating breaches as human failures. Start treating them as the predictable result of time acting on distributed systems without continuous enforcement.
2. Identify your head-only invariants. What safety conditions does your team UNDERSTAND but hasn't ENCODED? "Support access should be scoped." "Temporary permissions should expire." "No dev account should access prod data." Each is an invariant waiting to be written.
3. Encode and enforce. Write the invariants as machine-evaluable predicates. Evaluate them against actual state — not against the configuration files (which drift), not against the documentation (which lags), but against SNAPSHOTS of what the system looks like right now.
4. Make enforcement continuous. On every deployment + periodic drift checks between deployments. The more frequently you evaluate, the less time entropy has to accumulate between evaluations.
5. Stop blaming people. Each action was locally correct. The breach was emergent. The fix is structural — continuous enforcement of invariants that counteract the entropy humans cannot prevent by being more careful.
Security fails because entropy is patient. Attackers don't need to break in. They need to WAIT — until drift, forgotten assumptions, and accumulated exceptions create a gap wide enough to step through. The gap is inevitable without continuous enforcement. The enforcement makes entropy irrelevant.
Counteracting entropy continuously — 3,000+ CEL-predicate invariants encoding intent that would otherwise live in people's heads, evaluated against air-gapped snapshots of actual cloud state on every deployment + periodic drift checks, catching combinations that emerge from time acting on distributed systems. Standardized facts (JSONL, SMT-LIB) exported for external reasoning engines. Stave, an open-source risk reasoning engine. Entropy is inevitable. Enforcement makes it irrelevant. Try it: bash examples/demo-ai-security/run.sh
Top comments (0)