{
  "id": 1844349,
  "title": "Why I Don’t Want AI Coding Agents to Have Shell Access by Default",
  "url": "https://urgent.news/2026/08/19/why-i-dont-want-ai-coding-agents-to-have-shell-access-by-default",
  "topic": "ai",
  "section": "AI",
  "published": "2026-08-19T01:33:41.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/lukie81/why-i-dont-want-ai-coding-agents-to-have-shell-access-by-default-kng"
  },
  "original_language": "en",
  "account": "Artificial intelligence coding agents are rapidly gaining the ability to comprehend and interact with real codebases. They can analyze repositories, debug issues across multiple files, suggest architectural changes, generate tests, and even implement entire features. However, a crucial security concern has emerged: how much access an AI truly requires to perform useful tasks. When requesting an AI to review my code, my intent typically involves actions like understanding project structure, reading source files, searching for symbols or patterns, tracing component interactions, identifying bugs, and evaluating proposed implementations. None of these tasks inherently necessitate unrestricted shell access. Yet, many AI agent workflows currently bundle code access with capabilities such as executing shell commands, running Git operations, launching processes, reading arbitrary filesystem locations, and modifying any file. This significantly expands the potential impact of an AI if something were to go wrong. Capability and access are distinct concepts. A more powerful model does not necessarily demand stronger permissions. For instance, if I ask an AI to review an authentication implementation and identify any security concerns, it only needs permission to read the relevant repository. It does not require the ability to run arbitrary commands, access my entire home directory, inspect unrelated projects, modify source files, access sensitive credentials, or delete files. This principle of least privilege is a well-established concept in security engineering, and AI agents should not be an exception. By granting an AI only the permissions it needs to perform its specific role, the security boundary becomes much clearer. This is the reasoning behind my open-source project, RepoRelay. RepoRelay acts as an MCP server situated between an AI client and a local repository. Instead of granting the AI a general-purpose shell or filesystem API, RepoRelay exposes a minimal set of repository operations. The read-only surface includes functions to open a workspace, list files, read individual files, and search for specific patterns. Crucially, there are no shell tools, Git operations, process execution capabilities, or generic file-write tools. The approved repository itself becomes the boundary of access. While this may seem simple, implementing containment is far from straightforward. The server must meticulously handle potential edge cases such as path traversal, absolute paths, canonicalization, symbolic links, junctions, hard links, sensitive files, hidden credential locations, and bounded reads or searches. Requests like accessing files outside the intended directory, for example ../../some-other-project/.env, should be strictly prohibited. RepoRelay treats containment as an enforced security property rather than a mere prompt instruction. The AI is not instructed to stay within a specific folder; the server ensures it cannot leave that boundary through the exposed tools. Furthermore, sensitive files warrant an additional layer of protection. Even within an approved repository, there are files I would not want an AI reviewer to access, such as .env files containing sensitive configuration data or private keys. RepoRelay distinguishes between the repository-root boundary and the exposure of sensitive paths, applying two distinct layers of access control. This approach is not groundbreaking but rather an application of established security principles to AI tooling. In my experience, a coding agent and a reviewing agent often serve different purposes. The implementing model may require local execution capabilities like editing code, running tests, compiling, or using Git. However, the reviewing model typically does not need such capabilities. To address this, I propose a workflow where a local coding agent implements changes, commits them to the repository, and then forwards the changes to a RepoRelay server. The strong reviewing model then accesses the repository through RepoRelay to perform its review without gaining unrestricted access to the codebase. This separation of concerns allows the implementing model to write code while ensuring the reviewing model only evaluates changes without the risk of inadvertently modifying the original source. While pure read-only access offers a clean security model, I also experimented with a constrained reviewer-to-implementer workflow. In this setup, the reviewing model can communicate the desired next steps through a designated handoff file, such as NEXT_TASK.md, without gaining generic write access to the source tree. The implementing model can then incorporate those changes, and the reviewing model can provide a REVIEW.md file summarizing its assessment. This approach limits the reviewer's access to predefined, controlled interactions rather than unrestricted write permissions. Ultimately, RepoRelay aims to apply established security concepts to AI coding agents, providing a more granular and manageable approach to balancing capabilities and access. By carefully defining the permissions and boundaries for each AI role, we can significantly reduce the potential impact of security breaches while still leveraging the powerful capabilities of AI in code review and implementation tasks.",
  "summary": "AI coding agents are becoming very good at working with real codebases. They can inspect a repository, trace bugs across multiple files, suggest architectural changes, write tests, and increasingly implement entire features. But there is a security question I think we are moving past too quickly: How much access does an AI actually need to do useful work? When I want an AI model to review my…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}