Coding agents need file boundaries, not better manners

A developer argues that coding agents need auditable denylists to enforce file access boundaries, rather than relying on prompts to avoid sensitive files. The developer emphasizes that access control should be mechanical and enforced by the runtime, not dependent on the agent's interpretation of prose instructions. This approach addresses the trust problem in AI coding agents by making boundaries that the agent cannot talk its way around.

The next serious coding-agent feature is not a warmer tone or a smarter autocomplete. It is an auditable denylist. That sounds boring, which is exactly why it matters. Once an agent can inspect your repo, open local files, summarize context, run commands, or prepare a patch, the trust question stops being "does the model seem careful?" The useful question is much more mechanical: What can it read? What can it send to the model? What can it change? And when it says the work is verified, what actually failed loudly enough for a human to notice? Developers keep trying to solve agent trust with softer language. "Be careful with secrets." "Do not touch credentials." "Ask before using sensitive files." That is fine as guidance. It is not a boundary. A boundary is something the agent cannot talk its way around. There is a current open Codex issue asking for a way to exclude sensitive files and directories from agent access. The examples are exactly the ones you would expect: .env , private keys, cloud credentials, local config, .aws/ , .ssh/ , and other files that live close to real authority. That issue is useful because it cuts through the usual agent hype. This is not an abstract "AI safety" argument. It is a repo hygiene problem that any team can understand. Source code is context. Docs are context. Test files are context. Build scripts are context. Secrets are different. Local credentials are different. Customer exports sitting in a working directory are different. The mistake is treating all nearby files as equally valid input for a helpful model. They are not. Some files are operational boundaries. Some files exist because the developer's machine is where messy real work happens. Some files were never meant to become model context, even if they happen to be one read file away. Prompting the agent to "avoid sensitive files" is weaker than a rule the runtime enforces before the agent ever sees the path. That distinction matters. I do not want to pretend prompts are useless. Repo instructions, agent guidelines, and project policies are real parts of the workflow now. They tell the agent how the project works. They help keep edits consistent. They can prevent a lot of dumb mistakes. But they are still prose. Prose is reviewable. Prose is useful. Prose is also easy to misread, override, conflict with, or forget when the agent is juggling a long task. Access control should not depend on the agent remembering your preference. If a path is off limits, the system should make it off limits. That means teams need boring controls: This is not enterprise theater. Solo developers need this too. The smallest possible version is still useful: a checked-in agent config plus a local global ignore list for secrets and machine-specific state. The point is simple. If the agent should not read a file, do not make that a personality test. The research around AI coding agents is starting to make one thing clearer: agents do not remove the need for review. They move more pressure into it. One recent paper studies thousands of repositories after AI coding-agent adoption and argues that the effects show up in the human contributor ecosystem, not just in code volume. That is the part teams should pay attention to. More generated work can mean more review depth, more governance work, and more pressure on maintainers to catch problems after the fact. That matches how these workflows feel in practice. The agent can produce a patch quickly. Great. Now somebody has to decide whether the patch touched the right files, used the right assumptions, exposed the wrong context, skipped the wrong tests, or hid a risky change behind a clean summary. Weak boundaries make that review worse. If the agent had broad file access, the reviewer has to wonder what it saw. If the agent can read local secrets, the reviewer has to wonder whether any of that state influenced the output. If the agent can sweep through generated assets, design exports, local data, and config blobs, the diff is only part of the story. This is where file boundaries become a productivity feature. A smaller operating surface is easier to review. A visible denylist is easier to explain. A config file in the repo is easier to discuss than a vague assurance that the agent "probably would not do that." Good boundaries do not slow the team down. They reduce the amount of detective work after the agent has already acted. There is a similar trap with agent-written tests. Another recent paper looks at oracle signals in agent-authored test code. The useful takeaway is not "agent tests are bad." The useful takeaway is that test-shaped output can still fail to check the thing that matters. A test file can exist. The suite can run. The summary can look green. And the actual behavioral claim can still be under-tested, over-mocked, or asserted in a way that would never catch the bug. That matters because teams often talk about agent safety as if "run the tests" closes the loop. It does not. Running tests is a step. Meaningful verification is the loop. The same principle applies to file access. "The agent did not mention any secrets" is not proof that it never touched sensitive context. "The agent says it verified the change" is not proof that the verification had a useful oracle. Agent workflows need failure modes that are visible: The dangerous state is not failure. Failure is fine. Failure is information. The dangerous state is a fake green check. This is not limited to backend repos or secret files. Frontend and AI UI work has the same boundary problem, just with different artifacts. A repo may contain design screenshots, generated images, social preview assets, customer mockups, exported UI states, and half-finished experiments that should not automatically become agent context. If the task is "prepare a social preview image," the agent probably does not need a folder full of unrelated raw assets. Keep that work outside the agent context when you can. A browser-local utility such as Resize Image For https://resizeimagefor.com is a better fit for resizing platform assets than handing extra image files to an agent just because they are nearby. The same applies when evaluating generated interface patterns. You do not need the agent to ingest every old experiment in the repo to learn what the field looks like. A curated reference surface such as Awesome Generative UI https://awesomegenerativeui.com/ can be enough context for comparing patterns, papers, examples, and tools without widening the agent's access to your local project. That is the broader rule: give the agent the context it needs, not every artifact you happen to have. If your team is adding coding agents to real work, I would start with this checklist before arguing about model choice. First, define forbidden paths. Include secrets, credentials, private keys, local environment files, cloud config, customer data, and machine-specific directories. Make the list visible. Second, split repo rules from machine rules. The repo can define project boundaries. The developer's machine still needs a global denylist for things that should never be agent-readable anywhere. Third, review agent config like build config. If a change gives the agent more context, more write access, or more authority, it deserves real review. Fourth, keep generated assets out of context unless the task needs them. Images, previews, exports, logs, snapshots, and local data can carry more information than the agent needs. Fifth, make denied reads observable. A silent block is better than a leak, but a visible block is better than mystery. The reviewer should know when the boundary did its job. Sixth, separate patch success from verification success. "The diff was produced" is not "the behavior was verified." Make the agent say which checks ran, which checks failed, and which claims are still unproven. Seventh, inspect agent-written tests for real oracles. A test that only proves the mock returned the mock value is not doing much for you. Eighth, keep source notes for risky changes. If the agent changed auth, file handling, config loading, tool access, data export, or test policy, the review should know which source or rule justified the change. None of this requires a giant platform team. It requires deciding that agent access is part of the system design, not an afterthought. Better models will help. Better IDE integrations will help. Better summaries will help. They will not remove the need for hard boundaries. A coding agent can be brilliant and still have too much access. It can be careful and still see a file it should never have seen. It can write tests and still fail to prove the behavior. It can produce a beautiful summary and still leave the reviewer guessing about what context shaped the patch. The serious version of agent adoption is not "trust the model more." It is "make the model operate inside a smaller, inspectable space." That is why the denylist matters. It is not a minor settings-panel feature. It is the shape of the trust boundary. A coding agent becomes easier to trust when its access rules are boring enough for the whole team to audit. That is the bar I would want before letting one work near real repos every day. Source notes