The New Coding Agent Is Not Just A Chat Window
The useful version of an AI coding tool does not live in a browser tab pretending to understand your app from one pasted stack trace. It sits in your terminal, reads the repo, edits files, runs tests, calls tools, and keeps enough context to be dangerous in both directions.
That is why the current wave of command-line coding agents should be evaluated less like note-taking apps and more like package managers, CI runners, browser extensions, and database migration tools. They are close to source code. They can see secrets if you leave secrets lying around. They can invoke shell commands. They can connect to remote services. They can create a diff that looks plausible while quietly changing the wrong contract. Charming.
xAI's official Grok Build documentation describes it as a coding agent usable through an interactive terminal UI, headless scripts, bots, or the Agent Client Protocol, and its enterprise documentation lists required and optional network hosts for authentication, inference, remote session sync, updates, and assets. That does not prove any scary forum claim about any specific packet. It does prove the normal thing: modern AI coding CLIs are networked developer infrastructure, not offline text editors. See the official Grok Build overview and the enterprise deployment documentation if you want the vendor version in its own words.
Install Scripts Are The First Trust Decision
The first risky moment is not when the agent suggests a bad refactor. It is when you install it.
A lot of developer tools still offer the classic terminal spell: curl a script and pipe it into the shell. It is convenient. It is also the software equivalent of letting a stranger into the garage because they said they brought a ladder. Sometimes that is fine. Sometimes you should at least ask which ladder.
For an AI coding CLI, the install path should be part of the security review. Prefer package-manager installs where the package can be pinned, mirrored, cached, scanned, and rolled back. If the vendor offers a shell installer and an npm, Homebrew, apt, winget, or signed binary path, choose the one your team can actually audit. If your company manages laptops, the approved install should come from device management or an internal package registry, not from whatever command a developer copied at midnight because the demo looked cool.
At minimum, write down these answers before the tool becomes normal:
- Where did the binary come from? A vendor domain, package registry, internal mirror, or a random GitHub release?
- Can the version be pinned? If the answer is no, your rollback plan is mostly prayer with better fonts.
- Does it auto-update? Auto-update is useful, but it should not silently change behavior in regulated or production-adjacent environments.
- Can the installer be blocked from fetching extra binaries? This matters on CI runners and shared dev boxes.
- Who approves upgrades? Someone should own this besides the group chat.
Network Access Needs A Receipt
The right question is not whether an AI coding CLI uses the network. Of course it does if it calls hosted models. The right question is whether you can name the destinations, explain the purpose, and block the optional ones without breaking the core workflow.
A decent deployment story separates authentication, model inference, update downloads, telemetry, session sharing, web search, remote MCP servers, and asset loading. Those are not the same risk. Sending a prompt to a model endpoint is expected. Uploading session state for sharing may be optional. Pulling updates from a CDN may be convenient but should not be required during a locked-down build. Calling arbitrary MCP servers from a project config is a different kind of fun, and not the harmless kind.
Teams should keep a simple network receipt for every approved coding agent. It should list domains, ports, purpose, whether the connection is required, whether the user can disable it, and whether content may leave the machine. This is not bureaucracy for its own sake. It is how you avoid discovering during incident response that a developer tool had a side door labeled productivity.
If you want a deeper version of this idea, Notavello has already argued that AI coding agents need a network receipt. The short version is easy: no destination, no reason, no approval.
The Repo Is The Blast Radius
AI coding CLIs are useful because they can inspect a real project. That same access makes the project folder the blast radius.
Before using one in a serious repo, clean the repo like someone else is about to read it. Because someone else, in the broad systems sense, is. Remove committed secrets. Move local credentials out of project files. Check .env files, test fixtures, logs, database dumps, screenshots, exported customer tickets, and old migration scratchpads. Developers are very good at pretending these files are temporary. Git is very good at remembering they were not.
Use a throwaway worktree or branch for agent sessions. Keep the agent away from production credentials. Run it inside a container or dev environment when practical. If the project has multiple services, start with the narrowest folder that contains the task. Do not give a repo-wide agent a monorepo-sized buffet when you only need a route handler fixed.
There is also a social version of the blast radius. If a tool can modify shared config, hooks, generated code, lockfiles, CI workflows, or database migrations, it can create work for everyone. Require review on those files. Treat AI-generated changes to build scripts and deployment config as higher risk than ordinary application edits. The model may be clever. It still does not get to YOLO your release pipeline.
Config Files Are Policy, Not Decoration
The more serious coding CLIs now have layered config: user settings, project settings, managed settings, policy pins, MCP configuration, hooks, permissions, sandbox profiles, telemetry flags, and model routing. That sounds boring until one project config quietly grants a tool more access than the user thought it had.
Project-level settings should be reviewed like code. If a repo can define MCP servers, plugins, hooks, or permission rules, those files belong in pull requests, not in private hand-edited state. If a tool supports an inspect command that shows discovered settings, run it before trusting the session. xAI's CLI reference, for example, documents a grok inspect command that shows configuration discovered for the current directory, including rules, skills, plugins, hooks, and MCP servers. That is exactly the kind of preflight check developers should get used to running.
For teams, managed policy should beat user preference. Developers can choose themes and maybe notification sounds, because civilization must allow some freedom. They should not be able to override rules that disable risky telemetry, restrict tool access, or force a sandbox profile on regulated code. The policy file should be boring, versioned, backed up, and deployed through normal endpoint management.
A practical policy baseline looks like this:
- Disable optional sharing by default. Developers can ask for exceptions when they need them.
- Pin allowed models and providers. Random model switching is not a governance plan.
- Restrict MCP servers. Allow known internal servers first; make external servers opt-in.
- Block shell commands until approved. Read-only exploration should be easier than mutation.
- Export session logs. If the agent touched the code, the team should be able to reconstruct what happened.
Privacy Promises Still Need Local Discipline
Vendor privacy pages matter, but they are not a substitute for local hygiene. A vendor can promise not to train on certain data, offer enterprise retention controls, or document zero-data-retention modes. Good. Read it. Save it. Make procurement earn its lunch for once.
But most leaks are less cinematic than people imagine. A developer pastes a production token into a prompt. A repo contains a forgotten .env file. A test fixture includes real customer names. A debug log captures an OAuth exchange. A coding agent is then asked to explain the codebase, and suddenly the private junk is part of the working context. No conspiracy required. Just entropy with a command prompt.
The fix is not to ban every useful tool. The fix is to prepare the workspace before the tool arrives. Add secret scanning. Add pre-commit checks. Keep production credentials out of local repos. Use least-privilege API keys for development. Prefer synthetic fixtures. Rotate anything that touches a session by mistake. Make exported transcripts easy to review and easy to delete when retention rules require it.
Also separate personal experimentation from company code. Trying a new coding agent on a toy repo is normal. Trying it on a proprietary monorepo because someone on a forum said it was magical is how policies get written in all caps.
A Sensible Preflight Checklist
Before an AI coding CLI gets approved for real work, run a boring checklist. Boring is good. Boring is what you want near source code.
- Install: Use a pinned, approved installation method. Avoid unreviewed shell installers on managed machines.
- Version: Record the version used for meaningful changes, especially in CI or release branches.
- Network: Document required and optional domains. Block optional services unless needed.
- Secrets: Scan the repo before the first session. Remove .env files, dumps, logs, and real customer data.
- Scope: Run the tool in the smallest directory or worktree that fits the task.
- Permissions: Start read-only when possible. Require approval for shell commands, dependency installs, and file deletion.
- Diffs: Review generated code as code, not as a magic transcript. Tests are not optional because a robot sounded confident.
- Logs: Export or retain enough session history to explain why a change happened.
- Rollback: Use branches, worktrees, and small commits so the exit door stays visible.
The AI coding CLI is not the enemy. The lazy rollout is. Put the tool behind the same habits you already use for dependencies, CI, credentials, and code review, and it becomes much less mysterious. Still weird, yes. But usefully weird.