What should identity teams review first when adopting multi-agent systems?

Why This Matters for Security Teams

Multi-agent systems change the identity problem from “who authenticated” to “what authority can be delegated, by whom, and for how long.” A single user request can fan out across planners, tool-using agents, and approval agents, each with different execution paths. That means the first review is not just access inventory, but delegation boundaries, approval points, and state-changing tools. Current guidance from the OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modelling framework both point to the same operational risk: authority expands faster than most IAM reviews can track.

NHIMG research shows how often identity control breaks down in practice. In the Ultimate Guide to NHIs, only 5.7% of organisations report full visibility into service accounts, and 97% of NHIs carry excessive privileges. That matters here because multi-agent systems often inherit the same blind spots, but with more unpredictable execution and more opportunities for handoff. In practice, many security teams encounter privilege expansion only after an agent chain has already created a state change, rather than through intentional design review.

How It Works in Practice

The first review should map the delegation chain end to end: user request, orchestrator, planner, tool executor, approval gate, and any downstream agent that can re-use context or credentials. Identity teams should identify every tool that can create state changes, such as ticket updates, code commits, payments, infrastructure actions, token minting, or secret retrieval. Those tools should be treated as privilege boundaries, not mere integrations.

For multi-agent systems, static RBAC is often too blunt because agents do not follow fixed human job patterns. Better practice is emerging around intent-based authorization and real-time policy evaluation, where access is granted based on the specific task, data context, and risk signals at request time. That usually means pairing policy-as-code with workload identity, so the system can prove what an agent is before granting what it may do. Standards and research from NIST AI Risk Management Framework and OWASP Agentic AI Top 10 both reinforce the need for runtime controls rather than trust-by-design.

• Inventory every agent, sub-agent, and tool with state-changing capability.
• Mark where approvals are enforced and whether they are bypassable by chained prompts or tool calls.
• Use short-lived credentials and revoke them when the task completes.
• Prefer workload identity and cryptographic proof over long-lived static secrets.

NHI Mgmt Group’s 52 NHI Breaches Analysis is a useful reminder that identity incidents often start with overbroad access and weak visibility, then spread through overlooked service paths. These controls tend to break down when agents can spawn nested tools across separate runtimes because the approval chain becomes fragmented and impossible to audit consistently.

Common Variations and Edge Cases

Tighter delegation controls often increase orchestration overhead, requiring organisations to balance safety against workflow latency and developer friction. That tradeoff is real, especially in systems that rely on rapid, chained actions or human-in-the-loop approvals. Best practice is still evolving for fully autonomous systems, so there is no universal standard for how many handoff layers are acceptable.

Edge cases show up when agents operate across multiple tenants, when one agent can mint credentials for another, or when an approval agent is itself reachable through the same tool fabric it is meant to constrain. In those environments, identity teams should prioritise scope reduction before sophistication: separate runtime identities, isolate high-risk tools, and make escalation paths explicit. Where secret reuse is unavoidable, keep TTLs short and tie them to task completion, not calendar time.

NHIMG’s Ultimate Guide to NHIs and the CoPhish OAuth Token Theft via Copilot Studio case study both illustrate the same lesson: once authority is delegated through agents, the meaningful control point is the boundary where that authority can expand, not the point where the original user authenticated.

Related resources from NHI Mgmt Group

• Why is identity such a critical factor in securing AI agent systems?
• What is the difference between human identity governance and AI agent governance?
• How should security teams govern machine identity credentials in agentic AI environments?
• How should security teams limit the risk from AI agents that have access to production systems?