Failure Pattern: API Gateways Trust Stolen Tokens
API gateways validate tokens but not workload provenance. Attackers use stolen credentials to impersonate services.
What We See in the Field
A compromised VM uses a valid API token to call internal APIs. The gateway accepts the call because token validation passes. Attackers escalate privileges inside the API mesh.
Underlying Causes
Token theft
No workload-bound identity
Flat trust within API mesh
Overprivileged microservices
Inherited identity from orchestrators
Trust-Native Network Resolution
DTL requires verified TrustKeys for API sessions. Even valid tokens cannot be used by untrusted workloads. API calls enforce true origin identity.
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.