{"slug": "coding-agents-should-not-hold-write-credentials", "title": "Coding agents should not hold write credentials.", "summary": "A developer argues that coding agents should not hold write credentials, proposing a system where agents submit structured intents rather than directly creating external impact. The approach separates intent from impact through a deterministic gateway that checks scope, policy, and idempotency before materializing any changes as reviewable pull requests.", "body_md": "I have been thinking a lot about coding agents lately.\n\nNot really about whether they can write good code, because usually they can, sometimes they can't. That part is obvious. But the risk is shifting from wrong answers to wrong outcomes.\n\nThe part that feels more important to me is this:\n\nshould the agent actually own the write authority?\n\nWe already don't trust humans without roles, limits, reviews, and accountability. Developers use PRs, pilots use checklists, bank clerks have transfer limits. Capable agents need the same structure, but machine-readable.\n\nRight now a lot of setups still look roughly like this:\n\nI don't think this is the right default.\n\nThe agent can reason.\n\nThe agent can inspect files.\n\nThe agent can propose changes.\n\nBut the moment it can directly create external impact, the problem changes.\n\nIt is no longer just:\n\ndid the agent say something wrong?\n\nIt becomes:\n\ndid the agent create the wrong outcome?\n\nThat is a much more expensive failure mode.\n\nThe pattern I like more is simple:\n\n**So the agent does not get the write credentials.**\n\nIt submits a structured intent instead, which could look like:\n\n```\n{\n  \"operation\": \"write\",\n  \"target\": {\n    \"repo\": \"example/app\",\n    \"branch\": \"main\",\n    \"path\": \"docs/config/agent-policy.md\"\n  },\n  \"source_state\": {\n    \"blob_sha\": \"8f31c2...\"\n  },\n  \"requested_effect_hash\": \"sha256:...\"\n}\n```\n\nThis is then not a command anymore, it is a suggestion, or an intent.\n\nThe system still has to decide whether this proposed outcome should exist.\n\nThat decision layer can check things like:\n\nOnly after that should there be an outcome.\n\nFor example:\n\n```\n{\n  \"decision\": \"admitted\",\n  \"checks\": {\n    \"scope\": \"pass\",\n    \"source_state\": \"pass\",\n    \"policy\": \"pass\",\n    \"idempotency\": \"pass\"\n  },\n  \"outcome\": {\n    \"type\": \"pull_request\",\n    \"status\": \"created\",\n    \"reviewable\": true\n  }\n}\n```\n\nThe core rule is:\n\n**No impact without admission.**\n\nThe flow would look like this:\n\nA sandbox is useful.\n\nBut I think it solves a different problem.\n\nA sandbox asks:\n\nA gateway asks:\n\nshould this concrete proposed outcome exist?\n\nThat difference matters because a sandbox can stop escape, it does not decide whether a proposed outcome should exist.\n\nIf the agent has a valid GitHub token inside the allowed environment, it can still use allowed tools to create an unwanted result.\n\nThe action can be technically allowed and still be the wrong outcome.\n\nThat is why I think the boundary should sit between intent and impact, not only around execution.\n\nSandbox isolates execution.\n\nGateway isolates impact.\n\nGitHub already has a good human pattern:\n\na change proposal is not a merge.\n\nPull Requests are familiar because they are reviewable and they fit how developers already work.\n\nBut with agents there is one step before the PR that also matters:\n\nAn agent proposal should not automatically become PR impact.\n\nA PR is already a real side effect.\n\nSo the agent should not directly create it with its own write token.\n\nThe flow I want is more like this:\n\nThe adapter is not the authority, it only materializes admitted work.\n\nAnd the agent never receives the GitHub write credentials.\n\nThis is important:\n\nThat narrower claim is the whole point. I think many agent systems mix three things together:\n\nBut these should be separated:\n\nI don't think production agent systems will be trusted just because the models get smarter. They will be trusted when the path from agent work to external change becomes explicit.\n\nFor every real outcome, I want to be able to ask:\n\nThat is the layer I have been working on with Impact Boundary Labs.\n\nThe first implementation is GitHub-first:\n\nagents can read repositories directly, but write intents go through a deterministic gateway that creates reviewable Pull Requests with evidence.\n\nGitHub is not the whole idea, it is just the first concrete place to prove the pattern, because repositories have clear state, branches, commits, PRs, and review.\n\nThe broader principle is:\n\nLet agents reason.\n\nStop them at intent.\n\nControl what becomes outcome.\n\nProject: [Impact Boundary Labs](https://impactboundarylabs.com/)", "url": "https://wpnews.pro/news/coding-agents-should-not-hold-write-credentials", "canonical_source": "https://dev.to/davidloibner/coding-agents-should-not-hold-write-credentials-3eod", "published_at": "2026-05-30 12:50:22+00:00", "updated_at": "2026-05-30 13:12:52.292959+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy", "ai-ethics"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/coding-agents-should-not-hold-write-credentials", "markdown": "https://wpnews.pro/news/coding-agents-should-not-hold-write-credentials.md", "text": "https://wpnews.pro/news/coding-agents-should-not-hold-write-credentials.txt", "jsonld": "https://wpnews.pro/news/coding-agents-should-not-hold-write-credentials.jsonld"}}