When does identity-based Zero Trust fail to stop attackers?

Why Identity-Based Zero Trust Still Misses Real Attack Paths

Identity-based zero trust works only when identity state is current. If a service account still exists after a workload is retired, if RBAC grants more than the workload needs, or if a secret remains valid after offboarding, an attacker can authenticate normally and move inside the trust model. That is why Zero Trust is a control system, not a slogan: the decisions must reflect live identity, active privileges, and real credential status. NHI Mgmt Group research shows that Ultimate Guide to NHIs identifies 97% of NHIs as carrying excessive privileges, which turns identity-based access into an easy abuse path rather than a barrier.

NIST’s NIST SP 800-207 Zero Trust Architecture emphasises continuous evaluation, but many deployments still behave like static perimeter replacements. In practice, many security teams encounter this failure only after a stale API key or over-broad service account has already been used to blend into normal traffic. The breach looks legitimate because the attacker is using the organisation’s own authentication path.

How It Breaks Down in Workload and Agent Operations

The failure mode is usually operational, not theoretical. A workload identity may be created at deployment, granted RBAC roles for convenience, and then forgotten when the service changes. The same pattern becomes more dangerous with AI agents and other autonomous systems because they do not follow fixed request patterns. An agent can chain tools, request additional context, and act on goals rather than a narrow human workflow. That makes static access assumptions fragile. Guidance from OWASP NHI Top 10 and the Guide to SPIFFE and SPIRE points toward workload identity, short-lived tokens, and tighter runtime verification instead of standing access.

• Use JIT credential provisioning so access exists only for the current task.
• Prefer ephemeral secrets and short TTLs over long-lived API keys and certificates.
• Bind authorisation to current intent, context, and workload identity, not just to a role name.
• Revoke credentials automatically when a task completes, a policy changes, or the workload is retired.
• Log every decision point so anomalies can be tied back to a specific agent action or service call.

For attacker behaviour, CISA’s CISA cyber threat advisories and Anthropic’s report on Anthropic — first AI-orchestrated cyber espionage campaign report show why runtime control matters: once credentials are exposed, adversaries move quickly and exploit legitimate access paths. These controls tend to break down when organisations keep standing secrets in CI/CD, code, or shared vault paths because revocation is too slow to matter.

Where the Standard Answer Becomes Too Simple

Tighter identity controls often increase operational overhead, so organisations must balance security gain against deployment friction, especially for high-churn workloads. Current guidance suggests that identity-based Zero Trust is strongest when identity, privilege, and secret lifecycle are managed together; it is weaker when one of those layers is handled manually. That is why the issue is not only “does the policy exist?” but “does the policy reflect the workload’s current state?”

There is no universal standard yet for intent-based authorisation in autonomous systems, but the direction is clear: evaluate access at request time, issue only what is needed, and assume the workload may behave in ways the original designer did not predict. The 52 NHI Breaches Analysis and Top 10 NHI Issues both reinforce the same pattern: most failures are lifecycle failures, not cryptographic ones. Where governance is weak, even strong policy language cannot stop a valid credential from being used the wrong way. Best practice is evolving toward continuous, context-aware controls, but legacy systems with long-lived service accounts and broad trust zones remain the hardest cases.

Related resources from NHI Mgmt Group

• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• Why do NHIs complicate zero trust and least privilege efforts?
• What is the difference between zero trust for users and zero trust for NHIs?