AI Coding Agents: The Files They May Touch

Originally published at techpotions.com.

AI coding agents stop being a productivity toy and start being a governance problem the moment they can write to your repo without asking. The 2026 tool landscape is crowded, practical comparisons of the leading agents and Sourcegraph's guide to the coding-tool ecosystem will tell you which model is cleverest. But the boundary that actually protects your codebase is not "which agent," it is "which files and commands this agent may touch."

An assistant suggests a line of code while you stay at the keyboard. An AI coding agent works from a task-level goal, reads your codebase, writes a multi-file change, and runs your test suite on its own, that distinction is the whole difference in trust. Autonomy is exactly what makes agents useful, and exactly what makes them dangerous in the wrong directories.

The sane engineering answer is not to ban them. It's to define the touch boundary once, encode it, and enforce it mechanically. After cleaning up enough agent-generated sprawl in client repos, we built our AI service work around this simple principle: the useful boundary is a permission model, not a model card.

What an AI coding agent may touch before you lose control

The answer determines everything downstream: an agent should read source, propose changes, and run tests. It should not read secrets, should not write directly to protected branches, and should never hold deploy credentials.

Here is the boundary we consider the baseline for any repo where agents are allowed to work:

Notice what this table is really saying: the first sane control is not a better agent, it's a smaller filesystem. agents-sandbox exists precisely for this reason, it lets you isolate coding agents from the rest of the dev environment and stay in control of which parts they can reach. Isolation is the control; the agent is just the tenant.

Read-only repos are the fastest sane starting boundary

Start every agent integration read-only. This is not a compromise, it's a phase: you learn what the agent does with your code before you hand it a write handle.

The read-only phase answers questions no benchmark can answer:

• Does the agent hallucinate APIs your codebase doesn't use?
• Does it respect existing conventions, or rewrite them?
• Does it understand the architectural seams, or flatten them?

If it fails any of these, the tool comparison barely matters. You know it's not ready for writes. If it passes, you promote it, and only in the narrow surface where it passed.

The promotion should be mechanical, not memorial. An agent that read-only proved competent in src/ does not therefore earn .github/workflows/ or infra/. Every new directory is a new grant.

Test-gated writes: the agent may only merge what the suite proves

The single highest-leverage rule is this: no agent write reaches the main branch unless an automated test run passes first. Agents that run the suite themselves are table stakes in 2026, the good ones plan a change, edit across files, run tests, and work through failures. What you add on top is the rule that the suite result is the only currency that buys a merge.

A concrete setup looks roughly like this:

# agent-guardrails.yaml, the minimum permission model
agent:
  read:
    - src/
    - lib/
    - tests/
  execute:
    - test command: npm test
  write:
    paths: [src/, lib/]
    condition: tests_pass
  deny:
    - .env*
    - keys/
    - infra/
    - .github/
merge_policy:
  require: [tests_pass, human_review]

The file is deliberately boring. That's the point. If you cannot express the boundary in a config file this flat, the problem is not the agent, it's that you don't yet know the boundary. And if you're inheriting a codebase where agents have already written unguarded, a vibe-coding cleanup is the route back to a state where rules like this can actually be applied.

Review gates that actually catch agent mistakes

Agents write syntactically valid code that is semantically wrong, structurally alien, or rooted in a hallucinated assumption. Human review gates are not bureaucracy; they are the only layer that can catch those three failure modes, because they are the only layer that knows what the code was supposed to mean.

The review gate should be designed for what agents actually get wrong:

• Intent mismatch, the agent solved a nearby problem, not the one in the ticket. Reviewer checks the change against the task, not just the diff.
• Convention drift, the agent invented its own patterns because they were shorter. Reviewer checks against project conventions.
• Silent blast radius, the agent touched a file that should have been denied. This is a bug in your boundary, not the agent; log it and tighten the config.

A review gate with these three checks is cheap to run and catches most of what survives the test suite. Without it, you are code-reviewing an intern who reads the entire codebase in one sitting and never asks questions.

Secret redaction and the directories we never expose

Security researchers at NCC Group have been explicit about the baseline risk: interactive coding agents hold direct access to your local files, and that access extends to credentials if they live in the same tree. The fix is not a smarter secret scanner inside the agent. It's redaction at the boundary.

Never expose these to an agent, full stop:

• .env and dotenv variants
• API keys, tokens, private keys, certs
• Anything that can sign a release or deploy
• Database credentials, even dev ones
• Notes, playbooks, or commit messages that embed credentials

If a secret must exist inside a directory the agent can read, say, a test fixture, redact it before the agent ever sees it. The rule of thumb: the agent gets the shape of the secret, never the secret itself. A redacted placeholder carries all the structural information the model needs and none of the risk.

The directories we never expose by default are infra/, .github/, and anything with deployment state. Not because agents can't reason about infrastructure, many can, but because the failure mode there is irreversible, and irreversible is the one thing a test suite cannot buy back.

Where tool choice still matters

Boundaries don't make tool choice irrelevant; they make it safe to evaluate. Once the permission model is settled, agent quality becomes a real variable again: how well the model handles multi-file reasoning, how gracefully it works through failing tests, how much context it retains. Our hard-won picks among 2026's AI coding tools rank those qualities specifically, on the assumption that the guardrails are already in place.

That ordering matters more than most teams admit. Pick the smartest agent first, and you inherit its access model by accident. Pick the boundary first, and the smartest agent becomes a safe upgrade instead of a governance incident.

FAQ

What is the difference between an AI coding assistant and an AI coding agent?

A coding assistant works on a prompt and the cursor context around the line you're typing. A coding agent works from a task-level goal, reads the codebase, writes multi-file changes, and runs tests on its own. The practical difference is autonomy: an agent can mutate many files without you at the keyboard. This assistant-versus-agent line is consistent across the practical tool comparisons and the OpenHands definition.

Which files should I never expose to an AI coding agent?

Never expose secret material: .env files, API keys, production credentials, private keys, and anything that can sign or deploy. Also treat infrastructure state and migration scripts as high-risk. Redact or encrypt these before granting agent access, and keep them out of any directory the agent can read or write. The security concern is not hypothetical, it follows directly from the fact that these agents hold direct access to your local files.

How do I keep an AI coding agent from breaking our codebase?

Give the agent read-only access to source, require every write to pass an automated test suite, route each change through a human review gate, and isolate it from the rest of the environment. A sandbox that limits reachable directories is the most direct control; agents-sandbox exists precisely to give you that reach-control. The sequence is read-only first, then test-gated writes, and only then any talk of a wider grant.