Failure Pattern: Cloud IAM
Cloud IAM validates roles but not workload provenance. Attackers exploit this to steal service identities and impersonate cloud workloads.
What We See in the Field
A compromised VM retrieves cloud IAM tokens and uses them to access sensitive APIs. The cloud sees an authorized action. SOC tools see valid credentials. No one sees the attacker behind the request.
Underlying Causes
Tokens not bound to specific workloads
Overprivileged IAM roles
No session validation against device identity
Metadata services easy to exploit
Identity living outside the workload
Trust-Native Network Resolution
DTL enforces cryptographic workload identity before any IAM-based authorization is considered. Tokens alone cannot establish trust. The workload must present a valid TrustKey.
Broken Trust Assumption
This failure pattern has played out repeatedly in real security incidents—not because of missing tools, but because of how trust is assigned.
In breaches such as SolarWinds, Capital One, Okta, and MOVEit, attackers did not bypass security controls. They operated through them, using valid identities, trusted credentials, signed code, and encrypted sessions. Security systems accepted these signals as proof of legitimacy, allowing malicious behavior to proceed.
The common thread across these incidents is structural: identity was assumed based on trust signals, not proven at the moment of execution.