Failure Pattern
Secrets managers store credentials securely but cannot verify whether the workload requesting them is the legitimate one.
What We See in the Field
A compromised workload is cloned. Both original and clone retrieve secrets successfully because identity is tied to metadata, not the workload itself.
Underlying Causes
Secrets bound to roles, not devices
No cryptographic binding to workload identity
Metadata-based identity
Overprivileged secret scopes
Orchestrators issuing identical identity to clones
Trust-Native Network Resolution
DTL binds secrets retrieval to trusted workload identity. Only workloads presenting correct TrustKeys can read secrets. Clones fail identity validation.
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.