Should organisations use both network and identity controls for AI agents?

Yes, but only as layered enforcement, not as a complete answer. Identity controls restrict what the agent may access, while network controls restrict where traffic may go. Neither one can determine whether a permitted action is actually safe, so runtime behavioural enforcement still has to fill the gap.

Why This Matters for Security Teams

For AI agents, the question is not whether identity or network controls should exist in isolation, but whether both can constrain an autonomous workload that can chain tools, retry actions, and shift tactics at runtime. Identity controls define who or what the agent is allowed to be; network controls define where it can talk. Neither one, by itself, decides whether an allowed action is safe in context.

This is why current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 treats agentic systems as runtime risk problems, not just access-control problems. NHI Management Group research shows why this matters in practice: in the Ultimate Guide to NHIs, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That is a reminder that agent security fails fast when long-lived credentials and broad reach combine.

In practice, many security teams discover this only after an agent has already used legitimate access to reach systems that no one intended it to touch.

How It Works in Practice

The strongest pattern is layered enforcement: workload identity, short-lived credentials, network segmentation, and runtime policy evaluation all working together. For autonomous agents, the identity primitive should be the workload itself, not a human proxy account. That usually means cryptographic workload identity, such as OIDC-issued tokens or SPIFFE-style identities, with tight TTLs and automatic revocation per task. Static RBAC alone is too blunt because an agent’s next action is often not predictable at design time.

Network controls still matter, but they are best used to reduce blast radius, not to express business intent. A zero-trust model aligned to NIST SP 800-207 Zero Trust Architecture limits where traffic can go, while policy engines decide whether a specific tool call, data retrieval, or outbound request is acceptable at that moment. That aligns with the control logic described in CSA MAESTRO agentic AI threat modeling framework.

• Use identity to prove the agent is the right workload.
• Use JIT credentials so access exists only for the task window.
• Use network policy to block unnecessary destinations and protocols.
• Use runtime authorization to judge whether the action matches policy and context.

That is also consistent with NHIMG research on agent and NHI exposure. The OWASP NHI Top 10 highlights how compromise often comes from secret reuse, over-privilege, and insufficient lifecycle controls rather than from a single network gap alone. These controls tend to break down when agents operate across fragmented SaaS tools and shared automation runners because identity, tool access, and egress paths are enforced by different teams with different policy models.

Common Variations and Edge Cases

Tighter identity and network controls often increase operational overhead, requiring organisations to balance blast-radius reduction against agent latency, deployment complexity, and policy drift. That tradeoff is real, especially where agents need to call external APIs, SaaS tools, or internal data services across multiple trust zones.

Best practice is evolving on how much of the decision should sit in the network layer versus the policy layer. There is no universal standard for this yet, but current guidance suggests that network policy should be a guardrail, not the source of truth for authorization. If an agent is allowed to reach a service, the higher-value question is whether that request should be permitted right now, given the task, data sensitivity, and recent behaviour.

This becomes even more important in multi-agent workflows, where one agent can hand off state, tokens, or inferred intent to another. In those environments, a narrow identity policy plus a permissive east-west network path can still create privilege escalation. The 52 NHI Breaches Analysis and the Anthropic report on AI-orchestrated cyber espionage both reinforce the same lesson: autonomous systems can chain legitimate actions into unsafe outcomes faster than perimeter-only controls can react.

The practical answer is yes, use both, but treat them as complementary enforcement layers around a runtime decision engine.

Related resources from NHI Mgmt Group

• How can organisations govern AI agents that use service accounts and tokens?
• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?
• Why do AI agents increase non-human identity risk in existing IAM programmes?