Notifications
Clear all
Topic starter
21/08/2026 4:42 pm
TL;DR: Major AI coding agents all transmit code to remote models, but privacy risk depends on how much is sent, whether it is retained, and whether users can verify those flows, according to Arize; one captured Grok Build path moved 5.1 GB through a storage channel, far beyond the task requirement. The governance issue is no longer whether code leaves the machine, but which settings, retention rules, and audit paths actually constrain that transfer.
NHIMG editorial — based on content published by Arize: AI coding agents transmit far more code than teams expect
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Arize’s analysis of AI coding agent code transmission and privacy controls →
AI coding agents and code exfiltration: are your controls keeping up?
Explore further
21/08/2026 5:02 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AI coding agents transmit far more code than teams expect
