Failure Pattern: API Gateways Mistrust Services They Cannot Authenticate
API gateways mistrust tokens or certificates but do not confirm the identity of the workload presenting them. Attackers use stolen credentials to impersonate services.
What We See in the Field
A compromised microservice uses a valid API token to access sensitive routes. The gateway accepts the request because the token is correct. Attackers move deeper using trusted API paths.
Underlying Causes
API tokens not bound to workload identity
Overprivileged API roles
Lack of device-level trust validation
Poor visibility into service behavior
Gateways trusting metadata rather than verified identity
Trust-Native Network Resolution
DTL enforces workload identity at session creation. API requests must include verifiable TrustKeys. Even valid tokens are rejected if the workload identity is untrusted.
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.