{"slug": "why-i-dont-want-ai-coding-agents-to-have-shell-access-by-default", "title": "Why I Don’t Want AI Coding Agents to Have Shell Access by Default", "summary": "A developer built RepoRelay, an open-source MCP server that restricts AI coding agents to read-only repository access, enforcing the principle of least privilege. The tool exposes only a small set of operations—open_workspace, list_files, read_file, and search_files—and deliberately omits shell, Git, and process-execution capabilities to reduce the blast radius of agent errors. The developer argues that capability and access are distinct, and that AI agents should be granted only the permissions needed for their specific tasks.", "body_md": "AI coding agents are becoming very good at working with real codebases.\n\nThey can inspect a repository, trace bugs across multiple files, suggest architectural changes, write tests, and increasingly implement entire features.\n\nBut there is a security question I think we are moving past too quickly:\n\nHow much access does an AI actually need to do useful work?\n\nWhen I want an AI model to review my code, I usually want it to do things like:\n\nunderstand the project structure;\n\nread source files;\n\nsearch for symbols or patterns;\n\ntrace how components interact;\n\nidentify bugs;\n\nreview a proposed implementation.\n\nNone of those tasks inherently require unrestricted shell access.\n\nYet many agent workflows bundle code access together with capabilities such as:\n\nexecuting shell commands;\n\nrunning Git;\n\nlaunching processes;\n\nreading arbitrary filesystem locations;\n\nmodifying arbitrary files.\n\nThat makes the agent much more capable.\n\nIt also dramatically increases the blast radius when something goes wrong.\n\nCapability and access are different things\n\nA stronger model does not necessarily need stronger permissions.\n\nSuppose I ask an AI:\n\nReview the authentication implementation and tell me if you see any security issues.\n\nFor that task, the model needs information.\n\nIt needs to read the relevant repository.\n\nIt probably does not need permission to:\n\nrun arbitrary commands\n\nread my entire home directory\n\ninspect unrelated projects\n\nmodify source files\n\naccess credentials\n\ndelete files\n\nThis seems obvious when written out.\n\nBut developer tooling often treats repository access and machine access as almost the same thing.\n\nI wanted to separate them.\n\nThe principle: least privilege\n\nTraditional security engineering has a simple idea:\n\nGive a system only the permissions it needs to perform its job.\n\nAI agents should not be an exception.\n\nIf I am using one model as a reviewer, its permissions should reflect the role of a reviewer.\n\nThat might mean:\n\n✓ list repository files\n\n✓ read approved files\n\n✓ search the repository\n\n✗ execute shell commands\n\n✗ run Git\n\n✗ launch processes\n\n✗ read outside the repository\n\n✗ arbitrarily modify source code\n\nThis doesn't eliminate every risk.\n\nBut it turns the question from:\n\n\"Do I trust this AI with my computer?\"\n\ninto something much narrower:\n\n\"Do I trust this AI to inspect this repository through these specific operations?\"\n\nThat is a much easier security boundary to reason about.\n\nThis is why I built RepoRelay\n\nI recently built an open-source project called RepoRelay around this idea.\n\nRepoRelay is an MCP server that sits between an AI client and a local repository.\n\nThe architecture is roughly:\n\nAI / ChatGPT\n\n↓\n\nSecure MCP connection\n\n↓\n\nRepoRelay\n\n↓\n\none explicitly approved repository\n\nInstead of exposing a general-purpose shell or filesystem API, RepoRelay exposes a deliberately small set of repository operations.\n\nThe read-only surface is essentially:\n\nopen_workspace\n\nlist_files\n\nread_file\n\nsearch_files\n\nThe important part isn't the number of tools.\n\nIt's what isn't there.\n\nThere is no shell tool.\n\nThere is no Git tool.\n\nThere is no process-execution tool.\n\nThere is no generic \"write this file anywhere\" tool.\n\nThe approved repository becomes the boundary.\n\n\"One repository\" sounds simple. It isn't.\n\nA security boundary based on filesystem paths has plenty of edge cases.\n\nChecking that a requested path starts with:\n\nC:\\Projects\\my-app\n\nis nowhere near sufficient.\n\nA tool like this has to think about things such as:\n\n.. traversal;\n\nabsolute paths;\n\npath canonicalization;\n\nsymbolic links;\n\njunctions and reparse points;\n\nhard links;\n\nsensitive files;\n\nhidden credential locations;\n\nbounded reads and searches.\n\nFor example, a request for:\n\n../../some-other-project/.env\n\nshould obviously fail.\n\nBut the less-obvious escape mechanisms matter just as much.\n\nRepoRelay therefore treats containment as an enforced security property rather than a prompt instruction.\n\nThe AI isn't being told:\n\n\"Please stay inside this folder.\"\n\nThe server is supposed to make leaving the folder impossible through the tools it exposes.\n\nThat distinction is important.\n\nSensitive files deserve another boundary\n\nEven inside an approved repository, there are files I usually don't want an AI reviewer reading.\n\nThe most obvious example is:\n\n.env\n\nA repository may also contain credentials, private keys, or other sensitive material.\n\nSo \"the AI may read this repository\" should not automatically mean:\n\n\"The AI may read every byte under this directory.\"\n\nRepoRelay blocks classes of sensitive paths separately from the repository-root boundary.\n\nThat gives you two layers:\n\nIs this inside the approved repository?\n\n↓\n\nyes\n\n↓\n\nIs this file allowed to be exposed?\n\n↓\n\nyes\n\n↓\n\nread\n\nAgain, none of this is revolutionary security theory.\n\nIt's applying established ideas to AI tooling.\n\nReviewer and implementer should not always be the same agent\n\nThis led me to another design decision.\n\nI often use one AI system to implement code and a stronger model to review the result.\n\nThose are different roles.\n\nThe implementer may genuinely need local execution capabilities:\n\nedit code\n\nrun tests\n\ncompile\n\nuse Git\n\nThe reviewer often doesn't.\n\nSo instead of giving both agents identical privileges, I prefer a workflow like:\n\nLocal coding agent\n\n↓\n\nimplements change\n\n↓\n\nrepository / commit\n\n↓\n\nRepoRelay\n\n↓\n\nstrong reviewer model\n\n↓\n\nreview\n\nThis also creates a useful separation of concerns.\n\nThe model that wrote the code isn't necessarily the model that decides the code is good.\n\nBut what if the reviewer needs to request changes?\n\nPure read-only access is the cleanest security model, and RepoRelay supports it.\n\nBut I also wanted to experiment with a constrained reviewer → implementer workflow.\n\nInstead of allowing arbitrary writes, RepoRelay can expose a few predetermined handoff files.\n\nConceptually:\n\nChatGPT\n\n↓\n\nNEXT_TASK.md\n\nlocal coding agent\n\n↓\n\nimplements changes\n\n↓\n\nRESULT.md\n\nChatGPT\n\n↓\n\nREVIEW.md\n\nThe reviewer can communicate what should happen next without gaining generic write access to the source tree.\n\nThat's a very different permission from:\n\n\"Edit whatever file you want.\"\n\nThe goal is not zero capability.\n\nThe goal is bounded capability.\n\nWhy not just use operating-system permissions?\n\nOS-level isolation is valuable, and a tool like RepoRelay is not a replacement for containers, VMs, sandboxing, or proper system permissions.\n\nThose solve a broader problem.\n\nRepoRelay is trying to solve a narrower one at the application layer:\n\nWhat operations should this particular AI client be able to invoke?\n\nThose layers can complement each other.\n\nYou might eventually have:\n\nOS / container sandbox\n\n+\n\nMCP-level capability restrictions\n\n+\n\nrepository containment\n\n+\n\nsensitive-file filtering\n\nSecurity tends to work better when it does not depend on a single control.\n\nWhat RepoRelay does not claim\n\nI think security-oriented projects should be explicit about their limitations.\n\nRepoRelay is not an operating-system sandbox.\n\nIf malicious software is already running under your user account, an MCP server cannot magically secure the rest of the machine from that software.\n\nIt also doesn't make AI-generated code safe.\n\nA reviewer can still miss vulnerabilities.\n\nThe purpose is narrower:\n\nReduce the authority granted to the AI connection itself.\n\nThat still matters.\n\nIf the task requires reading four source files, giving the model the ability to execute arbitrary commands is unnecessary additional authority.\n\nAI tooling needs better permission design\n\nAs models improve, I think permission design is going to matter more, not less.\n\nA weak model with powerful permissions is dangerous because it can make mistakes.\n\nA very capable model with powerful permissions deserves careful thought for a different reason: it can do much more.\n\nThe answer can't simply be:\n\n\"The model is smarter now, so give it everything.\"\n\nWe should be asking:\n\nWhat is the smallest useful interface for this task?\n\nFor code review, that interface can be surprisingly small.\n\nAnd once the permissions are explicit, they become much easier to inspect, test, audit, and reason about.\n\nRepoRelay is open source\n\nRepoRelay is still a very new project, and I'm actively working on the security model and developer experience.\n\nIt's MIT licensed and available on GitHub:\n\ngithub.com/Lukie-81/RepoRelay\n\nYou can install it through npm:\n\nnpm install -g reporelay-mcp@latest\n\nI'm especially interested in feedback from people working on MCP, agent security, local-first tooling, and coding-agent workflows.\n\nI'm sure there are threat-model assumptions and edge cases I haven't considered yet.\n\nThat's also part of why I wanted to make it open source.\n\nThe broader question is bigger than RepoRelay:\n\nWhen an AI only needs access to your code, why should we automatically give it access to your machine?", "url": "https://wpnews.pro/news/why-i-dont-want-ai-coding-agents-to-have-shell-access-by-default", "canonical_source": "https://dev.to/lukie81/why-i-dont-want-ai-coding-agents-to-have-shell-access-by-default-kng", "published_at": "2026-08-19 01:33:41+00:00", "updated_at": "2026-08-19 01:41:57.436169+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "developer-tools", "ai-tools"], "entities": ["RepoRelay", "ChatGPT"], "alternates": {"html": "https://wpnews.pro/news/why-i-dont-want-ai-coding-agents-to-have-shell-access-by-default", "markdown": "https://wpnews.pro/news/why-i-dont-want-ai-coding-agents-to-have-shell-access-by-default.md", "text": "https://wpnews.pro/news/why-i-dont-want-ai-coding-agents-to-have-shell-access-by-default.txt", "jsonld": "https://wpnews.pro/news/why-i-dont-want-ai-coding-agents-to-have-shell-access-by-default.jsonld"}}