What breaks when certification is based only on assigned access?

The programme misses the difference between paper entitlement and effective authority. For agentic systems, the real privilege is assembled from multiple runtime relationships, so a correct approval can still hide a wider operational blast radius than the reviewer intended.

Why This Matters for Security Teams

Certification based only on assigned access assumes the approval list is the same as the real authority boundary. For human users, that shortcut is already risky. For agents, it is worse because execution paths are assembled at runtime through tools, tokens, and downstream services. That means a clean-looking review can still miss lateral movement, chained actions, and unintended data reach.

NHI Management Group’s research shows why this matters in practice: 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. The OWASP Non-Human Identity Top 10 treats over-privilege and weak lifecycle control as recurring failure modes, not edge cases.

In practice, many security teams discover the gap only after a service account or agent has already exercised authority far beyond the reviewer’s intent.

How It Works in Practice

Assigned access is a static snapshot. Effective authority is the set of actions an identity can actually perform once it starts calling APIs, assuming roles, invoking tools, and passing tokens to other systems. That is why agentic systems expose a certification problem that traditional IAM does not solve: the access review may be accurate for one account, yet incomplete for the full runtime chain.

Current guidance suggests evaluating the workload, not just the account. That means reviewing workload identity, token scopes, trust relationships, delegation paths, and the policy engine that will decide access at request time. The strongest implementations combine short-lived credentials, intent-based approval, and policy-as-code so the agent can only act within the current task context. In this model, identity is not merely a username or service principal. It is cryptographic proof of what the agent is, paired with what it is allowed to do right now.

Practitioners usually map this into four checks:

• What the agent can start with, such as a bootstrap credential or workload token.
• What the agent can obtain next, including role assumptions and delegated scopes.
• What tools and data stores are reachable through those downstream grants.
• What is automatically revoked when the task ends or the context changes.

That is why standards such as NIST SP 800-53 Rev. 5 Security and Privacy Controls and the 52 NHI Breaches Analysis are useful together: one gives the control language, the other shows how hidden privilege paths fail in the real world. These controls tend to break down when agents are allowed to chain multiple short-lived authorisations across loosely governed tools, because the compounded blast radius is larger than any single approval record suggests.

Common Variations and Edge Cases

Tighter certification often increases operational overhead, requiring organisations to balance faster delivery against stronger authority validation. That tradeoff is real, especially where teams are running event-driven automation, multi-agent workflows, or temporary break-glass access for incident response.

There is no universal standard for this yet, but current guidance suggests treating the following as special cases rather than exceptions to ignore:

• Ephemeral agents that are approved for minutes, not days, and whose authority should expire with the task.
• Federated environments where one agent can inherit privilege from another system through token exchange or delegation.
• CI/CD pipelines where assigned access looks narrow, yet secrets, build credentials, and deployment roles combine into broader runtime power.
• Third-party or vendor-hosted automations where the approval record does not reveal the full downstream service chain.

This is where certification based only on assigned access becomes misleading. The better question is not “what was granted?” but “what can this identity assemble at runtime?” That distinction is central to the Ultimate Guide to NHIs — Key Challenges and Risks and aligns with the agent-focused view in the OWASP Non-Human Identity Top 10 and the control-oriented approach of NIST. In highly dynamic agent meshes, assigned access alone is not enough because the effective authority graph changes faster than any manual review cycle.

Related resources from NHI Mgmt Group

• What breaks when access is assigned through broad group-based provisioning?
• When is it crucial to implement least-privilege access for AI agents?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• When does AI agent access create more risk than it reduces?