Why do coding agents create new trust gaps in east-west cloud traffic?

Coding agents create a trust gap when application security and network security both assume the other layer will catch abuse. The agent may execute unreviewed code, while the cloud fabric treats internal traffic as trusted. That combination lets data leave through channels that look normal at the packet level, even when the payload is malicious.

Why This Matters for Security Teams

Coding agents change the trust model because they can generate, modify, and execute code faster than traditional review cycles can keep up. In east-west cloud traffic, that matters when internal service-to-service paths are treated as low risk by default. A request may look legitimate at the network layer while carrying unsafe logic, credential use, or data movement that only the application layer would recognize. Guidance from the NIST AI Risk Management Framework is clear that AI systems need governance, measurement, and ongoing oversight, not just perimeter controls.

The practical issue is that many environments still separate appsec, cloud networking, and identity operations into different workflows. That creates a blind spot when an agent can call internal APIs, reuse secrets, or chain benign-looking services into an exfiltration path. Current guidance suggests treating agent-driven execution as a distinct risk class, especially where code output is deployed automatically or where the agent has access to production-adjacent data. In practice, many security teams encounter this only after an internal service begins behaving like a trusted insider rather than through intentional trust design.

How It Works in Practice

East-west trust gaps emerge when cloud platforms rely on implicit trust between workloads, namespaces, VPC segments, or service accounts. A coding agent may not need to break transport security to cause harm. It can create a new API client, alter a deployment manifest, query internal metadata, or trigger a workflow that passes normal authentication checks. If controls focus only on packet inspection, the activity can look routine because the traffic follows sanctioned routes and uses valid credentials.

For that reason, practitioners should design controls around identity, policy, and content validation rather than assuming the network boundary will decide what is safe. The agentic AI security community, including the OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework, increasingly treats tool use, autonomy, and escalation paths as first-class security concerns.

• Bind agent actions to short-lived identities and scoped permissions.
• Separate read, write, and deploy privileges for any tool the agent can call.
• Inspect payloads, prompts, and generated code before execution or promotion.
• Log east-west requests with enough context to trace the originating agent task.
• Use policy enforcement at service boundaries, not just at the ingress edge.

Detection also needs adversarial framing. The MITRE ATLAS adversarial AI threat matrix is useful where prompt manipulation, tool misuse, or model-driven workflow abuse leads to unauthorized internal activity. These controls tend to break down when agents are given broad production access, because normal service-to-service telemetry rarely shows the intent behind a malicious but syntactically valid request.

Common Variations and Edge Cases

Tighter east-west control often increases latency, alert volume, and deployment friction, requiring organisations to balance segmentation against developer velocity. The tradeoff is especially visible in platform engineering teams that rely on service meshes, internal developer platforms, or ephemeral compute, where aggressive inspection can disrupt normal release flows. Best practice is evolving, but there is no universal standard for how much autonomy a coding agent may have before it becomes a privileged execution path.

The hardest edge cases appear when the agent is acting through a legitimate CI/CD pipeline, a secrets broker, or a shared build runner. In those environments, the traffic is formally trusted yet operationally risky, because the agent can pivot from code generation into environment access without crossing a classic perimeter. The OWASP Agentic AI Top 10 highlights this kind of tool-chain abuse, while guidance from the NIST AI Risk Management Framework supports governance over deployment, monitoring, and accountability.

Another common exception is non-production experimentation that quietly becomes production-adjacent over time. Once an agent can reach internal services, cached tokens, or shared storage, network trust assumptions stop being a reliable control boundary. Organisations handling sensitive code, regulated data, or high-privilege automation should treat agent-originated east-west traffic as a distinct trust domain, not as ordinary internal application chatter.

Related resources from NHI Mgmt Group

• Why do AI agents create new trust and containment risks in cloud and identity environments?
• Why do coding agents create new NHI governance problems for IAM teams?
• Why do MCP-based agents create new trust-boundary problems?
• Why do AI coding agents create new IAM risk even when prompt injection is addressed?