How should security teams govern agent access when directory identity is not enough?

Why This Matters for Security Teams

Directory identity tells a team who registered the agent, but it does not tell the system what the agent is allowed to do at the moment a token is minted. That gap matters because agent access is often more dynamic than human access: the same agent may call different tools, act on different tenants, and request broader scopes as tasks evolve. Static directory groups and long-lived roles tend to blur those differences.

Current guidance from NHI Management Group emphasizes treating identity as a visibility layer, not a standing entitlement model. That aligns with findings in the Ultimate Guide to NHIs, where 97% of NHIs carry excessive privileges and 71% are not rotated within recommended time frames. Once an agent is trusted broadly at the directory layer, the blast radius is usually determined by tokens and secrets, not by the account name attached to them. The practical control point is therefore issuance, scope, and revocation. In practice, many security teams encounter overbroad agent access only after a downstream tool chain has already been used to expand privilege, rather than through intentional access design.

How It Works in Practice

Security teams should govern agent access at the token issuance boundary, where the system can evaluate the requesting principal, tenant, resource, action, and context together. This is where directory identity becomes useful for registration and audit, but not sufficient for authorization. For autonomous workloads, the stronger pattern is to combine workload identity with runtime policy decisions so the agent proves what it is, then earns only the scope needed for the current task.

That approach usually includes short-lived, just-in-time credentials, policy-as-code, and per-request evaluation rather than pre-granted access. Standards and industry guidance increasingly point this way. The OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework both reflect the need to evaluate intent, tool use, and runtime context, while NIST AI Risk Management Framework supports governance that is tied to measurable behavior rather than static labels.

• Use directory identity for registration, inventory, and traceability.
• Use workload identity, such as signed assertions or OIDC-backed proof, to establish the agent’s cryptographic identity.
• Issue ephemeral tokens per task, with narrow scopes and automatic revocation on completion.
• Evaluate policy at runtime using tenant, resource, action, and risk context.
• Log each token issuance decision so investigators can reconstruct why access was granted.

NHIMG research shows why this matters operationally: in the State of Non-Human Identity Security, only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, and 85% lack full visibility into third-party vendors connected via OAuth apps. These controls tend to break down when agents are allowed to chain tools across multiple SaaS environments because each hop can inherit or amplify the original scope.

Common Variations and Edge Cases

Tighter token governance often increases orchestration overhead, so organisations must balance operational speed against reduced standing privilege. That tradeoff becomes sharper in multi-agent systems, delegated workflows, and third-party integrations where an agent may need to act across several services in quick succession. There is no universal standard for this yet, but current guidance suggests the safest pattern is to minimise standing permissions and make escalation explicit, time-bound, and reviewable.

Edge cases appear when directory identity is shared across workloads, when one agent can impersonate another, or when legacy systems cannot evaluate context at token issuance. In those environments, security teams often have to layer compensating controls such as narrow brokered access, tenant-specific tokens, and step-up approval for sensitive actions. The governance model should also distinguish between human-approved delegation and fully autonomous execution, since the risk profile is not the same.

For teams building agentic systems, the main lesson is that directory identity is necessary for recordkeeping but insufficient for safety. The control must follow the action, not the account. That is especially true in environments with long-lived API keys, broad OAuth grants, or tools that can be chained without human review.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern Active Directory service accounts?
• How should security teams govern agent access when identity controls must be API-first?