In this chapter
Not new facts — the pattern underneath the facts Parts III and IV already established.
Four Controls, Four Different Ways to Fail
Permission
Over-scoped by default
Isolation
One chokepoint, no backup
Credentials
Static, ambient, everywhere
Monitoring
Not in place at all
None of these four needed to fail for the others to matter. Each one alone would have slowed the intrusion down. None of them existed.
The Pattern, Stated Plainly
- Permission — Kubernetes tokens, IAM keys, and platform tokens were all reachable from a single compromised worker, because nothing scoped them tighter (Ch. 04, Ch. 14).
- Isolation — the evaluation had exactly one sanctioned egress path, so one flaw in it removed the whole boundary at once (Ch. 08, Ch. 09).
- Credentials — static passwords and long-lived keys sat in plain environment variables, available the moment any code ran in that pod (Ch. 04, Ch. 14).
- Monitoring — trajectory monitoring wasn't in place during the evaluation, so nothing measured the gap between the first probe and the first working exploit (Ch. 08).
Claims in This Chapter
No single layer in this security model was designed to hold if the layer before it failed — each depended on the one before it working perfectly.
InferenceSourceBizTechLab's own analysis, synthesizing Parts III and IV
This is our own inference from the documented architecture, not a statement either company has made in these terms.