AI coding harnesses need blast-radius audits

A coding agent is not just a model that writes code. It is a model connected to a harness that can inspect a repository, edit files, run commands, read tool output, install dependencies, inherit environment variables, and sometimes communicate with remote services. That harness is where productivity becomes operational risk.

The useful thesis is simple: AI coding harnesses need blast-radius audits before they touch real repositories.

This matters most when the agent feels reassuringly local. A local model can reduce exposure to hosted inference providers, but local execution does not make the workflow safe by default. If the harness can traverse directories, run shell commands, read secrets, trigger package lifecycle scripts, or send telemetry, the blast radius may still include more than the feature branch you intended to test.

Sebastian Raschka’s walkthrough of local coding agents makes this distinction explicit: the LLM supplies reasoning and code generation, while the harness supplies the operating environment that can read files, make edits, run commands, and verify changes. He also recommends auditing data egress, file permissions, and prompt-injection robustness before running an installed coding agent harness. That is the right starting point for product teams, not an optional security appendix. Raschka’s local coding agent walkthrough

The model is not the whole agent

Product teams often evaluate coding assistants by model quality: benchmark scores, context length, diff quality, latency, or how well the assistant follows house style. Those checks matter, but they do not answer the operational question: what can this system do when it is wrong?

The model proposes actions. The harness decides which actions are available, how they are executed, what context is loaded, which tools can be called, which files can be modified, and what logs leave the machine. A mediocre model inside a narrow harness may be safer than a great model inside an unchecked harness with broad filesystem and shell access.

That is why a harness review belongs before the first enthusiastic trial in a production repo. The question is not only whether the agent can solve a bug. The question is whether the agent can damage adjacent systems while solving it. Can it edit generated files and source files at the same time? Can it run a package manager script that executes arbitrary code? Can it read .env files? Can it discover SSH keys? Can it paste logs into a remote endpoint? Can repository instructions manipulate its tool use?

This is adjacent to code review, but it is earlier. A review packet evaluates the change the agent produced, as in AI coding agents need review packets. A blast-radius audit evaluates the environment that lets the agent produce that change in the first place.

What belongs in a blast-radius audit?

A practical audit should fit on one page. If it becomes a policy binder, teams will skip it. The goal is to identify the boundaries that make an initial trial safe enough, not to prove the tool is universally safe.

Start with file boundaries. Write down the default working directory, whether the harness can move above it, and which paths are read-only, writable, or blocked. Treat secrets as a separate line item. .env, credential stores, SSH directories, cloud config folders, database dumps, production logs, and browser profiles should not become casual context.

Then audit shell execution. List whether commands require confirmation, whether allowlists exist, and whether the agent can invoke package managers, build tools, test runners, Docker, or deployment scripts. The dangerous surface is not only rm -rf. It is also npm install, postinstall, make, curl | sh, migration scripts, and any command that can modify state outside the repo.

Next, inspect install and update paths. A harness that is safe today can change tomorrow through extension updates, global packages, plugins, MCP servers, or post-install hooks. Product teams should know how the tool updates, who approves version changes, and whether a pinned version can be reproduced during incident review.

Finally, map data egress. Look for telemetry, crash reporting, model-provider calls, plugin endpoints, update checks, and logs. A local model does not guarantee that prompts, file names, identifiers, or error traces stay local. If the tool has a cloud mode, confirm that the local mode does not silently inherit cloud defaults.

Which permissions should be blocked, narrowed, or logged?

Do not ask for a philosophical answer to whether agents should have access. Ask for a permission decision per capability.

Some capabilities should be blocked for first use: production credentials, deployment commands, broad home-directory reads, global package installs, destructive database operations, and write access outside the repo. If the agent needs them later, that is a separate approval event.

Some capabilities should be narrowed: tests can run, but only inside a container or dedicated user account. File writes can happen, but only under the project directory. Network access can exist, but only to declared endpoints. Logs can be collected, but secrets must be redacted and retention should be known.

Some capabilities should be logged: shell commands, file edits, network calls, permission escalations, plugin calls, and tool failures. This is not surveillance for its own sake. It is the minimum evidence needed when a generated change breaks something and the team has to reconstruct what happened.

This is where product and engineering need the same artifact. Product managers should not approve agent adoption based only on demos. Engineers should not carry the whole risk conversation informally in Slack. A one-page audit makes the adoption decision legible.

Prompt injection is a repo-surface problem

Prompt injection is often discussed as if it belongs only to chatbots reading hostile web pages. Coding agents have their own version. The hostile instruction may live in a README, issue description, test fixture, dependency output, generated file, commit message, or tool response.

A harness that treats every text surface as instruction is too trusting. Repository content should be context, not authority. Project instructions should be scoped. Tool output should be quoted or delimited. The agent should not be able to convert a comment inside a file into permission to exfiltrate secrets or disable tests.

For product builders, the important move is to turn this into acceptance criteria. Before a team adopts a harness, create two or three adversarial fixtures: a README that asks the agent to reveal environment variables, a failing test that suggests running an unsafe command, and a fake tool output that requests a network call. The expected result is refusal, clarification, or escalation, not clever compliance.

This connects directly to permission design. If an agent has blanket tool access, prompt injection has more room to become action. If tools are scoped, confirmed, and logged, injection attempts have less operational force. The same principle appears in AI agents need tool permissions, not blanket access, but coding harnesses make the issue concrete because the repo is the workbench.

How should teams approve agent use in real repositories?

Use a staged approval path. First, run the harness in a disposable repository with fake secrets and adversarial fixtures. Second, run it in a real repository with read-only access. Third, allow writes on a branch, with command confirmation and network restrictions. Fourth, allow broader autonomy only after the team has logs, rollback steps, and review expectations.

This path should connect to rollback planning. If an agent can make multi-file changes quickly, the team needs a way to revert, bisect, and explain those changes just as quickly. That is why AI coding agents need rollback plans is not a separate concern. It is the downstream half of the same control system.

The one-page audit should end with a clear decision: blocked, approved for sandbox, approved for read-only repo use, approved for branch writes, or approved for a narrower named workflow. Avoid vague approvals like “approved for engineering”. They hide the actual boundary.

Before running a new coding agent, write the audit. Name the files it can touch. Name the commands it can run. Name the secrets it cannot see. Name the endpoints it can contact. Name the update path. Name the logs. Name the prompt-injection tests. The point is not to slow down AI-assisted coding. The point is to make sure that when the agent accelerates, it accelerates inside a boundary the team chose on purpose.