Teams should govern the graph as the primary security object, then assign identity, policy, and observability to each governed node. That means mapping resolved identities, permitted transitions, and tool access for every node that can act independently or trigger downstream work. If the graph is not explicit, accountability collapses when delegation fans out.
Why This Matters for Security Teams
A multi-agent graph changes the unit of security from a single workload to a chain of delegated actions. Once one node can call tools, spawn another agent, or hand off context, identity governance must cover the full path, not just the first login. Traditional role assignments are too static for behaviour that is goal-driven, runtime-dependent, and often partially unpredictable.
This is where teams misread the problem as an IAM inventory issue instead of an execution-control issue. The right question is not only “who is this agent?” but also “what transitions can it trigger, under what context, and with which downstream privileges?” That is why current guidance from the OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework emphasizes path-level control, not just node-level trust.
NHIMG research shows why this matters operationally: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 97% of NHIs carry excessive privileges. In practice, many security teams only discover uncontrolled delegation after an agent chain has already widened access or moved laterally.
How It Works in Practice
Govern the graph as a first-class security object. Each node should have a resolved workload identity, explicit allowed transitions, scoped tool access, and a policy decision point that evaluates context at request time. For autonomous systems, static RBAC is usually too blunt because the agent’s next action is not fully knowable at design time. Current guidance suggests pairing least privilege with runtime authorisation that can inspect intent, task state, resource sensitivity, and prior actions.
Practically, that means issuing ephemeral credentials per task rather than relying on long-lived secrets. Workload identity becomes the anchor primitive: a cryptographic assertion that the node is what it claims to be, whether via SPIFFE/SPIRE, OIDC, or another workload-attestation model. Policy-as-code tools such as OPA or Cedar can then decide whether a node may call a tool, hand off to another node, or elevate to a more sensitive action. The NIST AI Risk Management Framework is useful here because it frames governance, measurement, and monitoring as continuous controls rather than one-time approvals.
NHIMG’s Ultimate Guide to NHIs reinforces the operational baseline: NHIs outnumber human identities by 25x to 50x in modern enterprises, so manual review does not scale. A multi-agent graph should therefore be modeled with node ownership, edge permissions, credential TTL, and audit trails that preserve who delegated what, to whom, and for how long. These controls tend to break down when agents are allowed to chain external tools across loosely integrated SaaS environments because the policy engine loses full context and downstream identity resolution becomes ambiguous.
Common Variations and Edge Cases
Tighter graph controls often increase orchestration overhead, requiring organisations to balance execution speed against containment. That tradeoff is especially visible in research assistants, coding agents, and workflow automators that need broad but temporary access to complete a task. Best practice is evolving, and there is no universal standard for how granular agent-to-agent delegation should be.
One common edge case is a supervisor agent that never touches sensitive data directly but authorises lower-tier agents. That node still needs a distinct identity, strict approval boundaries, and separate observability because it controls privilege indirectly. Another edge case is cross-tenant or third-party tool use, where the graph extends outside the enterprise boundary. In those environments, a node’s trust should degrade automatically when provenance is unclear, a lesson echoed by the OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modelling framework. The right pattern is to treat unknown edges as deny-by-default until the node, the context, and the downstream target are all explicitly governed.
Guidance also differs for multi-agent pipelines that are deterministic versus exploratory. Deterministic flows can use narrower pre-authorised edges, while exploratory systems need stronger runtime checks and shorter-lived secrets. The common failure mode is assuming the graph is stable when the agent’s behaviour is not.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A10 | Covers uncontrolled agentic actions and delegated tool use in multi-agent flows. |
| CSA MAESTRO | Threat modeling must include agent-to-agent delegation and runtime trust decisions. | |
| NIST AI RMF | AI RMF supports continuous governance, measurement, and monitoring for autonomous agents. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Multi-agent graphs depend on strong NHI lifecycle and secret governance. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access management apply to each governed node and transition. |
Map every agent edge to a deny-by-default policy and review tool permissions before deployment.
