AI coding agents transmit far more code than teams expect

At a glance

What this is: This analysis shows that AI coding agents routinely send source code to remote models, and one captured Grok Build path uploaded far more data than the task required.

Why it matters: It matters because IAM, PAM, and NHI teams now need to govern code access, retention, and telemetry as part of the same control plane that manages secrets, tokens, and delegated automation.

By the numbers:

• A separate storage channel moved 5.1 GB, in 73 chunks, to a bucket named grok-code-session-traces.
• The model-request channel moved roughly 192 KB of task-relevant traffic.

👉 Read Arize’s analysis of AI coding agent code transmission and privacy controls

Context

AI coding agents depend on remote inference, so source code, prompts, and tool context often leave the local workstation even when the user expects a limited task scope. The governance gap is that privacy settings usually control retention or training, not whether sensitive code is transmitted in the first place, which makes AI coding agent privacy a control problem as much as a product setting problem.

The article’s main finding is that the important risk is not simply data collection, but uncontrolled scope, weak user visibility, and unclear retention behaviour across different plans. That creates an identity and access question for NHI governance too, because API keys, session traces, and delegated agent access now determine what code an AI system can see, move, and store.

For practitioners, the starting position is typical rather than exceptional: most organisations have not yet mapped code transmission paths, privacy defaults, and abuse-monitoring retention to a formal control framework.

Key questions

Q: What breaks when AI coding agents are allowed to ship code without security constraints?

A: Teams get working software that can still carry old, well-known vulnerabilities back into production. The failure is not only a coding mistake. It is a governance failure where functional correctness is treated as sufficient evidence, even when the agent has reintroduced a flaw that the security community already fixed.

Q: Why do enterprise AI agents complicate NHI governance?

A: They complicate NHI governance because the security model was built around predictable non-human identities such as API keys and workload credentials. Agents reason over context, can chain actions, and may use multiple protocols in one workflow. That makes permission modelling necessary but insufficient, because the real control issue is whether the execution still reflects approved intent.

Q: How do security teams know whether a coding agent is really in privacy mode?

A: They should verify observed network behaviour, provider retention settings, and abuse-monitoring exceptions against the vendor’s documentation. A privacy mode that only changes storage after upload is not the same as a control that limits transmission. The test is whether the agent sends less data, not whether the provider promises to keep it shorter.

Q: What should teams do first when an AI coding tool can access private code and secrets?

A: Start by classifying the tool as a governed high-trust identity, then restrict repository scope, block unnecessary secret access, and validate what the tool transmits under real sessions. If you cannot prove the boundaries, you should not assume the agent is operating within them.

Technical breakdown

Why AI coding agents must transmit code to remote models

AI coding agents are not fully local systems. They submit files, prompts, and surrounding context to a remote model so the model can reason over the task. The technical distinction is not transmission versus no transmission, but scoped transmission versus broad session capture. Some tools chunk code for embedding or indexing, others send task context directly, and the model provider may retain logs, traces, or classifier outputs separately from the live inference path. That makes privacy settings only one layer of the data flow, not the whole control boundary.

Practical implication: Map every code path that leaves the workstation, including indexing and telemetry, before treating any privacy toggle as sufficient.

Retention controls do not equal transmission controls

Zero data retention is often misunderstood. In practice, it is a rule about what happens after the provider receives the data, not a guarantee that the data never leaves the customer environment. Enterprise and API plans may support stronger retention choices than consumer subscriptions, but abuse monitoring, classifier storage, and investigation logs can still create residual records. For identity teams, that means the security question extends beyond content handling to contractual scope, plan eligibility, and whether the provider can independently inspect session material.

Practical implication: Treat retention promises as post-ingest governance and verify them against plan type, audit logs, and abuse-monitoring exceptions.

Why undisclosed upload channels create governance blind spots

The most serious issue in the article is not that code was transmitted, but that a separate storage channel appeared to move far more data than the task required and did so without clear user visibility. That is a classic control failure: data minimisation was not enforced at the transport layer, and the user-facing setting governed a different behaviour from the one the user likely cared about. In identity terms, this is delegated access without sufficient boundary enforcement, where an authenticated agent can expand the data footprint beyond intended scope.

Practical implication: Require per-session telemetry and explicit transport baselines so agents cannot exceed task scope without detection.

Threat narrative

Attacker objective: The attacker objective is to harvest code, secrets, and session context at scale through an apparently legitimate AI coding workflow.

1. Entry occurs when a developer runs an AI coding agent with repository access and allows it to inspect local files and secrets.
2. Credential access happens when the agent can read API keys, .env contents, git history, and other sensitive artefacts that were never meant for remote transmission.
3. Impact follows when the agent uploads excessive source material and credentials to provider-controlled storage, creating exposure and possible retention beyond the user’s intent.

NHI Mgmt Group analysis

AI coding agents have become a new NHI governance surface. When a code assistant can read repositories, secrets, and session history, it behaves like a privileged non-human identity with delegated access. That means the programme cannot treat the tool as a neutral productivity layer. It must govern its permissions, telemetry, retention, and offboarding like any other high-trust workload identity.

Retention settings are being mistaken for data minimisation. The article shows that a privacy flag may change storage behaviour while leaving transport untouched. That is a governance failure because the control is positioned at the wrong point in the lifecycle. Practitioners should read this through an OWASP NHI lens, where the problem is not only credential exposure but also the scope of what the credentialed system can exfiltrate before any review occurs.

Code indexing and session tracing create a distinct concept: transport expansion risk. This is the condition where a tool sends more data than the immediate task requires, even when the user believes the control is only about model training. Transport expansion risk matters because it broadens the blast radius of a single authenticated session and weakens the assumption that local execution equals local confidentiality.

Verification now matters as much as policy text. The article’s wire-level testing is the right model for governance: trust the documented setting less than the observed behaviour. For identity and NHI programmes, that means control validation should include packet capture, session tracing, and vendor configuration review, not only policy attestation. The practitioner conclusion is simple: if you cannot verify what leaves the machine, you do not control it.

Agentic AI will force IAM and PAM teams to converge on code handling. Even when the article is about developer tooling rather than classic infrastructure access, the same question appears: who can the agent see, what can it transmit, and how is that privilege revoked? The practical conclusion is that AI coding agents should be enrolled into the same governance model used for privileged service accounts and other NHI workloads.

What this signals

Transport expansion risk will become a recurring control issue as coding assistants, copilots, and agentic workflows expand the amount of data that leaves endpoints during ordinary development tasks. For identity teams, the lesson is to measure what is actually transmitted, not just what the privacy policy says should be retained.

The governance pattern mirrors other NHI problems: delegated access grows faster than review processes. That makes verification tooling, session-level telemetry, and entitlement scoping more valuable than generic privacy assurances, especially where code, secrets, and infrastructure context are all visible to the same agent.

For practitioners

• Audit transmission paths for AI coding tools Inventory which agents can read repositories, environment files, commit history, and session traces, then test what actually leaves the workstation under normal use and after privacy settings change.
• Separate retention from transport in policy Write controls that distinguish between data sent to a model, data stored for abuse monitoring, and data retained for training, then map each condition to the specific plan or subscription type.
• Require per-session verification for high-trust tools Use packet capture, proxy testing, or tracing plugins to confirm that an agent’s observed behaviour matches its documented privacy mode and does not expand beyond task scope.
• Treat AI coding agents as governed non-human identities Assign ownership, approval, and revocation steps for each agent workspace, especially where the tool can access secrets, private code, or production-connected credentials.

Key takeaways

• AI coding agents now sit inside the identity and access perimeter because they can read repositories, secrets, and session context while acting on behalf of users.
• The evidence in this case shows that retention controls and privacy labels do not prevent overscoped transmission, which is the governance failure teams must address.
• Practitioners should verify actual network behaviour, narrow agent permissions, and govern coding tools like privileged non-human identities.

Key terms

• Transport Expansion Risk: Transport expansion risk is the gap between the task a user asked an AI tool to perform and the larger volume of code, context, or telemetry the tool actually transmits. It matters because privacy settings often govern retention, while the real exposure happens before data reaches the provider.
• Zero Data Retention: A storage model in which prompts and outputs are not retained by the provider after processing, or are excluded from normal logging altogether. It reduces exposure to discovery, abuse monitoring, and later reuse, but it does not remove all other privacy or security obligations around the AI service.
• Delegated non-human identity: A machine or agent identity that acts on behalf of a user or system and inherits access to connected tools. The control problem is not only authentication, but the scope, duration, and downstream reach of that delegation once the session is established.

What's in the full article

Arize’s full analysis covers the operational detail this post intentionally leaves for the source:

• Wire-capture methodology for validating what AI coding agents actually transmit during a live session
• Per-tool privacy setting differences across Claude Code, Codex, Copilot, Cursor, Gemini CLI, and Grok Build
• How training consent, retention, and abuse monitoring diverge across consumer, business, and enterprise plans
• The tracing plugin approach used to instrument session, tool-call, and subagent behaviour in Arize AX

👉 The full Arize analysis covers the captured upload behaviour, privacy flag testing, and agent-by-agent documentation differences.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps security and IAM practitioners apply consistent governance to agentic tools, service accounts, and other high-trust non-human actors.