How should security teams secure east-west AI traffic without waiting for a complete agent inventory?

Why east-west AI traffic should be controlled before the agent graph is complete

East-west AI traffic is the internal movement between agents, tools, services, and orchestrators. The practical mistake is to wait for perfect inventory before enforcing boundaries. Security teams can already control the reachable surface by treating each connection as an access decision, then tightening scope as they learn more about the workflow. The Zero Trust for AI Agents model is useful here because it starts from verified access, not assumed trust.

That means the first question is not “what does every agent do?” It is “what should this agent be allowed to reach right now?” If a service can only justify one downstream capability, its network path, token scope, and request context should reflect that limited need. As the workflow expands, permissions can expand in step with the approved use case, rather than being granted broadly and later discovered to be excessive.

This approach also fits the way real agent systems evolve. Teams often begin with one orchestrator and a small number of tools, then add sub-agents, shared services, and chained workflows. A deny-by-default posture prevents those additions from silently inheriting broader east-west access than they need, while still letting delivery continue. Agent identities should therefore be registered and governed as first-class actors, even when the full topology is still changing.

How to narrow reach without blocking delivery

The operational control is to scope connectivity to the service level, not the environment level. In practice, that means per-agent or per-workflow policies, short-lived credentials where possible, and connection rules that are specific to the action being performed. A broad internal network allowlist is too coarse for autonomous systems, because it treats all internal reach as equally acceptable.

Cryptographic identities make this safer because they bind requests to a verifiable workload or service rather than to a static host location. That is particularly important when agents move across platforms, namespaces, or execution contexts. SPIFFE and SPIRE are a strong fit for this problem because they are designed around workload identity, attestation, and service-to-service authentication.

Teams should also treat permission growth as a change-control event. When a workflow needs broader east-west reach, that expansion should be explicit, reviewable, and tied to a concrete business reason. The control objective is not to freeze the system. It is to ensure that new agent relationships do not inherit old trust assumptions that were never valid for the current workflow.

What to watch when the topology is still unknown

Unknown agent relationships are not a reason to defer control, they are the reason to start with tighter control. The practical risk is that an unlisted sub-agent, helper service, or orchestrator path may become a hidden lateral movement route if internal traffic is permitted too freely. That is why discovery and enforcement should proceed together, rather than in sequence.

Security teams should look for internal connections that are not needed for the current task, credentials that can reach multiple services without a clear purpose, and agent-to-agent paths that bypass normal approval or logging. Even before inventory is complete, those patterns usually indicate overreach rather than necessity. The key NHI challenges and risks page is a useful reference point because visibility gaps and over-privilege are the two failure modes that most often turn unknown relationships into exposure.

A second issue is trust propagation. If one agent can call another with the same broad token or internal trust context, the compromise of one component can immediately widen the blast radius. Limiting east-west reach early reduces that propagation effect, even when the environment is still being mapped.

Practitioner Guidance

What to prioritise: Start with the highest-value internal workflows and define the minimum set of reachable services for each one. Do not wait for complete inventory if the reachable path is already visible from logs, service maps, or deployment manifests.

Decision rule: If the connection is not required for the current task, block it until the workflow owner can justify the dependency. If it is required, allow only the specific service, action, and credential scope needed for that transaction.

What good looks like: New agent paths are introduced as explicit approvals, not as implicit side effects of deployment. The default state is no east-west access unless a concrete workflow need exists, and any expansion is traceable to a named use case.

Practitioner takeaway: The fastest safe path is to control trust boundaries first, then let discovery refine them. Perfect inventory is useful, but it should never be a prerequisite for denying unnecessary internal reach.

Related resources from NHI Mgmt Group

• How should security teams secure an API platform across both north-south and east-west traffic without relying on direct service exposure?
• How should security teams secure AI agent platforms at the traffic boundary?
• How should security teams handle AI agent traffic without treating it as a security verdict?
• How should security teams detect AI agent traffic without blocking legitimate customers?