How should security teams govern AI agents that use multiple identity layers?

Why This Matters for Security Teams

AI agents do not rely on a single identity path. They can hold a workload identity, borrow a session token, call tools through embedded service accounts, and inherit authority from another agent. That makes governance a layered problem, not a checkbox exercise. If one layer is tightly controlled but another remains broad, the agent still has a viable route to act, exfiltrate data, or chain into higher privilege.

That is why current guidance increasingly treats agents as autonomous workloads with dynamic access needs, not static users. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a strong warning sign for layered agent estates where controls drift across tools and teams. External frameworks such as the OWASP Top 10 for Agentic Applications 2026 and NIST AI Risk Management Framework both point toward context-aware controls, but there is no universal standard for this yet. In practice, many security teams encounter layered identity abuse only after an agent has already crossed from one trust domain into another.

How It Works in Practice

Governance should start with an identity map for each agent: what it is, what it can assume, what it can delegate, and what it can invoke. The right control plane is usually a combination of workload identity, intent-based authorisation, and short-lived credentials. Workload identity establishes cryptographic proof of the agent itself, while runtime policy decides whether a specific action is allowed in that moment. This is more defensible than broad RBAC alone because the agent’s path is goal-driven and may change from task to task.

Practitioners should separate identity layers and govern each one differently. For example: use workload identity for the agent runtime, issue JIT credentials only for a bounded task, and revoke them automatically when the task completes. Keep embedded tool identities scoped to a single function, and treat agent-to-agent delegation as a privileged relationship that requires explicit approval and logging. The CSA MAESTRO agentic AI threat modeling framework is useful for mapping those trust edges, while the OWASP Agentic Applications Top 10 reinforces the need to treat tool use, delegation, and over-permissioned action paths as separate risk surfaces. The operational goal is zero standing privilege, not merely fewer privileges.

A practical pattern is policy-as-code at request time, using context such as task type, data sensitivity, destination system, and current human approval state. That is the difference between static IAM and agent governance: the decision is based on intent, not just identity. These controls tend to break down when agent workflows are stitched across legacy SaaS, unmanaged scripts, and loosely governed tool plugins because the weakest identity layer becomes invisible.

Common Variations and Edge Cases

Tighter identity layering often increases operational overhead, requiring organisations to balance control strength against delegation speed and developer friction. That tradeoff is real, especially when agents support customer operations, software delivery, or SOC automation. Current guidance suggests prioritising the highest-risk paths first, rather than trying to redesign every agent at once.

One edge case is multi-agent orchestration, where one agent brokers work for others. In those environments, the broker can become a hidden super-user unless delegation is explicitly bounded and reviewed. Another is long-running agents that cache tokens or secrets for convenience; that creates a standing-access problem even if the original provisioning was short-lived. The AI LLM hijack breach and the 52 NHI Breaches Analysis are reminders that compromise often spreads through the least visible identity path first. For environments using MCP, vendor plugins, or unmanaged tool chains, the governance model should assume that one compromised layer can unlock others unless policy is enforced at runtime and every credential is ephemeral.

Best practice is evolving, but the direction is clear: treat each identity layer as independently dangerous, validate each action at runtime, and design for revocation at the same speed that agents can act.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that use OAuth access?
• How should security teams govern machine identity credentials in agentic AI environments?
• How should teams govern AI agents that use MCP?
• How should security teams govern AI agents that can access enterprise systems?