They need both, but identity control comes first when the core risk is delegated authority. If the question is who can task an agent, what tools it can invoke, and how far that authority extends, then network monitoring alone will always be partial. Governance must cover the agent session as an access boundary.
Why this is an identity control question, not just a network visibility question
Agent orchestration becomes an identity issue when authority is delegated, not merely when traffic moves across a network. The practical question is who may task the agent, what the agent may invoke, and whether that authority is bounded, attributable, and revocable. If those decisions are unclear, packet inspection can show activity but cannot prove that the right principal exercised the right authority at the right time.
That is why agent session design matters. The session is effectively an access boundary for tool use, data access, and cross-agent delegation, so security teams need to reason about authentication, authorization, and privilege scope before they rely on monitoring to explain behavior. The stronger the delegation chain, the more important it becomes to treat the orchestration layer as part of the control plane rather than as simple application traffic.
For teams building around multi-agent workflows, the Multi-Agent and A2A Security Guide is the clearest starting point because it focuses on authentication, signed agent identity, and multi-hop delegation. That matters when orchestration spans more than one agent, because each hop can widen the blast radius if authority is inherited too loosely or if trust between agents is assumed rather than verified.
What network monitoring can tell you, and what it cannot
Network monitoring still has an important role, but it answers a different question. It helps teams see where an agent connected, which endpoints were contacted, whether data left an approved path, and whether the behavior looks unusual compared with a baseline. That is useful for detection, investigation, and containment, especially when an agent starts behaving outside expected timing, volume, or destination patterns.
It does not, by itself, resolve whether the action was allowed. A monitored connection to a tool API may be legitimate or may represent tool misuse, excessive delegation, or an impersonated session. If security policy only watches network flows, it can miss the more important control failure: an overbroad agent identity that can call too many tools, inherit too many privileges, or continue operating after the task that justified access has already ended.
The practical implication is that telemetry and access control are complementary, not interchangeable. Security teams should use network data to validate behavior and identity data to define and enforce authority. When those are separated, the organization can detect suspicious execution without mistaking visibility for control.
The AI Agent Observability, Audit and Incident Response Guide is useful here because it ties agent logging, attribution, and kill-switch design to incident response. That combination reflects the real operational need: once a delegated agent is acting in production, teams must be able to reconstruct what it did and revoke its access without waiting for a network alert to explain the event.
How to decide where the control boundary should sit
The cleanest rule is simple: if the control question is about delegated authority, treat it as an identity control problem first; if the control question is about whether activity escaped detection or crossed a suspicious route, treat monitoring as a supporting control. In practice, the most effective architecture anchors orchestration to explicit identity, scoped tool permissions, task-level authorization, and revocation logic, then layers network monitoring on top for anomaly detection and forensics.
That decision becomes especially important when agent systems use shared credentials, chained delegation, or cross-environment access. Those patterns make it easy for a benign-looking agent action to become a broad access event if the underlying identity is not tightly bound to purpose, context, and expiry. The main design mistake is assuming that an orchestration layer is “just workflow,” when in reality it is often the mechanism that turns a request into privileged execution.
Teams that are formalising this boundary should review the broader control model in Identity Security Programme Guide, because orchestration governance sits inside a wider identity operating model. They should also use Agentic AI Identity Guide when they need a practical model for how agents receive, use, and retire delegated authority across their lifecycle.
Risk and Threat Considerations
When orchestration authority is too loose, the main risk is not just noisy activity, it is unbounded delegated action. An attacker who compromises an agent session, a shared token, or the tasking channel may inherit tool access that was meant to be narrow and temporary. Network monitoring may still record the traffic, but it will be too late to stop the control failure if the identity layer already granted excessive reach.
Failure mechanism: Orchestration logic grants broad or persistent authority, then treats later agent activity as ordinary service traffic instead of as privileged action. That creates a gap where tool calls, data access, and cross-agent delegation can proceed without sufficient task scoping, session expiry, or revocation.
Impact: The result can be unauthorized tool use, privilege escalation through delegation, cross-environment spillover, and harder incident reconstruction because the system observed the packets but did not enforce the authority boundary. At scale, the same weakness can turn many small agent tasks into a single high-blast-radius access path.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Orchestration risk here is delegated authority and overbroad agent privilege. |
| ASI07 — Insecure Inter-Agent Communication | Multi-agent orchestration depends on trusted agent-to-agent handoff and delegation. | |
| ASI08 — Cascading Failures | Loose orchestration can spread a bad agent action across multiple dependent agents. | |
| Recommendation — Scope agent tool and task permissions narrowly, and bind them to explicit identity and delegation rules. Authenticate inter-agent handoffs and reject unsigned or untrusted delegation paths. Contain shared failure paths by limiting propagation between agents and tool chains. | ||
| MITRE ATT&CK | T1021 — Remote Services | Agent orchestration often uses remote protocol paths that can be abused after access is granted. |
| Recommendation — Harden remote execution paths and monitor for unusual remote tasking patterns. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Authentication | Agent orchestration depends on authenticating non-human actors and their service interactions. |
| Recommendation — Authenticate agent-to-agent and agent-to-tool interactions with strong service identity controls. | ||
Practitioner Guidance
Decision rule: If the main failure you are trying to prevent is “who can cause the agent to do something,” put identity and authorization controls at the centre of the design. If the main failure you are trying to detect is “what happened after access was already granted,” keep network monitoring as a supporting detection layer rather than the primary control.
What to verify: Confirm that each agent session has a clear principal, explicit tool scope, and revocation path; if you cannot show those three elements, you do not yet have a reliable access boundary. Also verify that logs can tie tool invocation back to the originating task and delegated authority chain, not just to a source IP or service endpoint.
What good looks like: A well-governed orchestration environment allows temporary, purpose-bound agent activity, limits tool reach by default, and makes it possible to cut off authority quickly when behavior changes. Network telemetry then becomes the evidence layer that helps confirm whether the identity decision worked, not the mechanism that substitutes for it.
Practitioner takeaway: Treat agent orchestration as an access problem first and a visibility problem second, because you cannot monitor your way out of delegated authority that was never properly bounded.
Related resources from NHI Mgmt Group
- When should security teams treat AI design tooling as an identity governance issue?
- How do security teams decide which agent identity controls belong in orchestration versus infrastructure layers?
- How do software teams decide whether to treat AI agent and MCP-layer threats as an AppSec issue or an identity issue?
- What do security teams get wrong when they treat privileged account management as one control instead of separate account, user, and identity problems?