{"slug": "coding-agents-need-file-boundaries-not-better-manners", "title": "Coding agents need file boundaries, not better manners", "summary": "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.", "body_md": "The next serious coding-agent feature is not a warmer tone or a smarter autocomplete.\n\nIt is an auditable denylist.\n\nThat 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:\n\nWhat can it read?\n\nWhat can it send to the model?\n\nWhat can it change?\n\nAnd when it says the work is verified, what actually failed loudly enough for a human to notice?\n\nDevelopers 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.\n\nA boundary is something the agent cannot talk its way around.\n\nThere 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`\n\n, private keys, cloud credentials, local config, `.aws/`\n\n, `.ssh/`\n\n, and other files that live close to real authority.\n\nThat 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.\n\nSource code is context. Docs are context. Test files are context. Build scripts are context.\n\nSecrets are different.\n\nLocal credentials are different.\n\nCustomer exports sitting in a working directory are different.\n\nThe 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`\n\naway.\n\nPrompting the agent to \"avoid sensitive files\" is weaker than a rule the runtime enforces before the agent ever sees the path.\n\nThat distinction matters.\n\nI 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.\n\nBut they are still prose.\n\nProse is reviewable. Prose is useful. Prose is also easy to misread, override, conflict with, or forget when the agent is juggling a long task.\n\nAccess control should not depend on the agent remembering your preference. If a path is off limits, the system should make it off limits.\n\nThat means teams need boring controls:\n\nThis 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.\n\nThe point is simple. If the agent should not read a file, do not make that a personality test.\n\nThe 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.\n\nOne 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.\n\nThat matches how these workflows feel in practice.\n\nThe agent can produce a patch quickly. Great.\n\nNow 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.\n\nWeak 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.\n\nThis is where file boundaries become a productivity feature.\n\nA 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.\"\n\nGood boundaries do not slow the team down. They reduce the amount of detective work after the agent has already acted.\n\nThere is a similar trap with agent-written tests.\n\nAnother 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.\n\nA test file can exist.\n\nThe suite can run.\n\nThe summary can look green.\n\nAnd the actual behavioral claim can still be under-tested, over-mocked, or asserted in a way that would never catch the bug.\n\nThat 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.\n\nThe 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.\n\nAgent workflows need failure modes that are visible:\n\nThe dangerous state is not failure. Failure is fine. Failure is information.\n\nThe dangerous state is a fake green check.\n\nThis is not limited to backend repos or secret files.\n\nFrontend 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.\n\nIf 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.\n\nThe 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.\n\nThat is the broader rule: give the agent the context it needs, not every artifact you happen to have.\n\nIf your team is adding coding agents to real work, I would start with this checklist before arguing about model choice.\n\nFirst, define forbidden paths. Include secrets, credentials, private keys, local environment files, cloud config, customer data, and machine-specific directories. Make the list visible.\n\nSecond, 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.\n\nThird, review agent config like build config. If a change gives the agent more context, more write access, or more authority, it deserves real review.\n\nFourth, 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.\n\nFifth, 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.\n\nSixth, 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.\n\nSeventh, inspect agent-written tests for real oracles. A test that only proves the mock returned the mock value is not doing much for you.\n\nEighth, 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.\n\nNone of this requires a giant platform team. It requires deciding that agent access is part of the system design, not an afterthought.\n\nBetter models will help. Better IDE integrations will help. Better summaries will help.\n\nThey will not remove the need for hard boundaries.\n\nA 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.\n\nThe serious version of agent adoption is not \"trust the model more.\"\n\nIt is \"make the model operate inside a smaller, inspectable space.\"\n\nThat is why the denylist matters. It is not a minor settings-panel feature. It is the shape of the trust boundary.\n\nA coding agent becomes easier to trust when its access rules are boring enough for the whole team to audit.\n\nThat is the bar I would want before letting one work near real repos every day.\n\n**Source notes**", "url": "https://wpnews.pro/news/coding-agents-need-file-boundaries-not-better-manners", "canonical_source": "https://dev.to/hefty_69a4c2d631c9dd70724/coding-agents-need-file-boundaries-not-better-manners-kg2", "published_at": "2026-06-29 08:18:20+00:00", "updated_at": "2026-06-29 08:27:05.414516+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-safety", "large-language-models"], "entities": ["Codex"], "alternates": {"html": "https://wpnews.pro/news/coding-agents-need-file-boundaries-not-better-manners", "markdown": "https://wpnews.pro/news/coding-agents-need-file-boundaries-not-better-manners.md", "text": "https://wpnews.pro/news/coding-agents-need-file-boundaries-not-better-manners.txt", "jsonld": "https://wpnews.pro/news/coding-agents-need-file-boundaries-not-better-manners.jsonld"}}