Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is the Least Access a Coding Agent Needs to Finish a Task?

A coding agent needs read access to the files its task touches, write access inside the repository or sandbox it works in, and the results of any credentialed call rather than the credential itself. Check which of those three an agent holds before its next run, because most agents today carry the developer's full access.

A credential reference travels from a browser record through a bounded route to a separate API destination.

The smallest working set for a coding task has three parts: the files the task reads, a place inside the repository or sandbox where it writes, and the output of any call that needs a credential, with the credential itself kept somewhere the agent cannot reach. Agents rarely get that set. They get the developer's account, because scoping access per task takes more effort than most teams spend on a single run. This means the agent often holds more access than the task uses, and the organization answers for all of it. The record here is one record type, a task scoped to one repository, read access, and one run. Anthropic, HashiCorp, Cognition, GitHub and the Firecracker project document parts of the scoping, and the attack research shows what an over-provisioned agent can be made to do; a team should close that gap with a per-task plan, which narrows access without stopping work. A governed environment adds a control on rendered pages, where the question of what the agent sees is separate from the question of what it may do, as What Is Least Exposure? sets out. Vendor pages were read on the dates given in Sources, and each section says which statements come from them.

Key findings

  • Claude Code's documentation states that the boundary is a permission prompt, so a Bash command the developer approves can still write anywhere the user account can, which is the developer's access and not the task's (Anthropic, 2026).
  • HashiCorp's Vault tutorial describes an agent that receives a token that is read-only, repo-only, scoped to a single credential, and short-lived, with token lifetime reduced from days or weeks to minutes (HashiCorp, 2026).
  • GitHub's secure use reference calls it good security practice to set the default permission for the GITHUB_TOKEN to read access only for repository contents (GitHub, Secure, 2026).
  • A study of prompt injection against agentic coding editors reports attack success rates as high as 84% for executing malicious commands, which is the cost of an agent that holds more than its task needs (Liu et al., 2026).
  • A governed environment replaces values chosen by policy with consistent tokens before any model reads the screen, so an agent working on a settings page sees placeholders in place of keys (What Is Least Exposure?).
  • In that control class, real values resolve only at the approved destination at the moment of an approved action, and a named person approves each consequential action (What Is a Tethered Agent?).

What is the smallest working set for one coding task?

Take one task as the record type: fix a failing unit test in one repository, on one branch, in one run. The agent needs to read the test file, the module under test and whatever those import. It needs to write to a working copy, on a branch, inside a sandbox or the repository checkout. If the task ends with a pull request or a CI run, it needs the result of that call, the pull request number or the test report, and not the token that made the call. That is the whole set. Three classes, each scoped to the task: read on the files the task touches, write inside the repository or sandbox, and the results of any credentialed call.

Everything outside that set is surplus. The developer's SSH keys, the cloud credentials file, the browser's logged-in sessions, the other repositories in the organization and the ability to push to the default branch are all available to an agent that runs as the developer, and none of them is needed to fix the test. The OWASP Non-Human Identities Top 10 lists overprivileged identities as its fifth risk, NHI5, and secret leakage as its second, NHI2, the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores" (OWASP, 2025). An agent that holds the developer's full access is both at once.

Two scope notes apply. Least privilege, which this page is about, governs actions and credentials; it does not govern the content of the screen an agent reads, so an agent can satisfy least privilege in full and still hold every record it was shown (What Is Least Exposure?). And a governed browser environment, described later, covers what an agent reads and does on a rendered page; it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, which are where most of a coding task happens.

Why do most coding agents get the developer's full access?

Because the default is the developer's own account, and narrowing it is work that happens per task. Claude Code's security page describes sandboxing bash commands with filesystem and network isolation, reducing permission prompts while maintaining security, and adds that while these protections significantly reduce risk, no system is completely immune to all attacks (Anthropic, 2026). The prompt gates the action; it does not change whose access the action runs with.

The leak record shows what full access produces. GitGuardian's study of GitHub's Copilot found that of the repositories examined over 1,200 leaked at least one credential, and that Copilot generated 3.0 valid credentials for one prompt on average (GitGuardian, 2025). Wiz looked at 50 AI companies and found that 65% had leaked verified credentials, almost two-thirds of the companies analyzed (Wiz, 2025). Neither figure measures a coding agent's access. Both show where credentials end up when a tool that reads and writes files can reach them.

The cost of scoping is the reason it is skipped. A per-task credential means minting, binding and revoking one; a per-task file scope means naming the paths before the run. For a single run that is more effort than approving a prompt, so the prompt wins and the agent inherits everything. How Do You Let an AI Agent Manage API Keys Without Reading Them? and Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? describe the same default on the credential and the administrator side.

What do the vendors themselves say?

Anthropic's Claude Code security page states, for cloud sessions, that GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM, and that the VM holds a short-lived credential scoped to that session (Anthropic, 2026). That is the per-session shape of the working set. The page describes it for Anthropic-hosted cloud sessions and not for local sessions.

HashiCorp's Vault tutorial describes a wrapper script that obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent, so the agent process holds the raw token in its environment (HashiCorp, 2026). The scope is narrow and the lifetime is minutes; the page does not say whether the agent can read the token.

Cognition's Devin guide lists credential scopes of organization, personal, repository and session, with session credentials scoped purely to the current session and not saved for any future sessions (Cognition, 2026). In the browser, Devin types the value directly, and for shell commands it binds credentials as environment variables whenever needed; whether the model sees the value is not described in the pages reviewed.

GitHub advises pinning references to actions to a commit SHA in workflow files and auditing how credentials are used (GitHub, Secure, 2026). The Firecracker jailer drops privileges by setting the provided uid and gid, and with --new-pid-ns spawns the binary into a new PID namespace (Firecracker, 2026).

What can an over-provisioned agent be made to do?

Whatever its access allows, on an instruction it did not get from the developer. A study of prompt injection against agentic coding editors reports that attack success rates can reach as high as 84% for executing malicious commands (Liu et al., 2026). The injected text arrives in a README, an issue, a dependency or a web page, and the agent executes it with the access it holds. With the developer's access, the command runs as the developer.

Browsing agents show the same pattern. Mudryi, Chaklosh and Wojcik report findings that include prompt injection, domain validation bypass and credential exfiltration, and demonstrate how untrusted web content can hijack agent behavior (Mudryi et al., 2025). Credential exfiltration is only possible where the agent holds a credential to exfiltrate. An agent given the result of a credentialed call, and not the credential, has nothing of that kind to hand over, which is the point of the third item in the working set.

Privilege control is the proposed defense in the research as well as in practice. Progent, a privilege control framework for agents, is reported to significantly reduce attack success rates while maintaining high utility, evaluated on AgentDojo and ASB (Shi et al., 2026). The abstract gives no figures, so the claim is directional. The direction matters: scoping what the agent may do lowers what an injection achieves, without a change to the model. The combination that makes injection dangerous is private data, untrusted content and a channel out (What Is the Lethal Trifecta for AI Agents?), and an agent with the developer's full access has all three.

How do you scope access per task without stopping the work?

Write the working set down before the run, then issue access against it. For the unit test task the plan is short: read the test directory and the module it covers, write to a branch in the sandbox, and one credentialed call, a CI trigger or a pull request, made by a component outside the agent with the result passed back. Anything the task needs that is not in the plan is a request, approved by a person, and recorded.

Access class Least working set for the task What stays outside the agent
Read The files the task touches, named before the run Credential files, other repositories, browser sessions
Write A branch in the sandbox or working copy The default branch, the developer's home directory
Credentialed calls The result of the call The token, the key, the password
Approvals A named person for each push, merge or deploy Standing write grants

Two existing designs show the shape. As Is It Safe to Let an AI Agent Set Up Your Cloud Environment? records, AWS strongly recommends not creating access keys for the root user, which rules out the simplest way an agent might be given durable top-level power. Meta's Muse design, described in What Would an Enterprise Version of Meta Muse Need?, uses credentials through surrogate tokens the agent never sees, with human approval before sensitive actions. Both keep the credential out of the agent and give it the result.

The per-task plan is the piece most teams lack, and its absence is why the default persists. A planner that reads the task, proposes the working set and issues the scoped grants removes the effort that made full access the easy choice. Whatever form it takes, the test is the same: after the run, can the team list what the agent read, where it wrote, which calls it made and who approved each one.

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders such as a token name in place of a key. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this question it covers the part of a coding task that happens on a page. When the agent opens a repository settings page, a key management page, a CI dashboard or a cloud console to finish the task, the key shown there is replaced before the model reads it, and the agent works on the placeholder. The working set on the page is then the least exposure as well as the least privilege: the agent sees what the task needs and nothing it does not, and the credential never enters the model's context from that route. The record of what the model saw on each page is the piece the vendor pages above do not describe.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so the read and write classes of the working set stay with the sandbox, the file permissions and the credential broker the team configures. The tether, as What Is a Tethered Agent? puts it, is a description of authority and not of capability: the agent goes where its supervisor could go and does real work there, but cannot slip the line back to the person who set it up.

Methodology and limitations

This page rests on vendor documentation from Anthropic, HashiCorp, Cognition, GitHub and the Firecracker project, three research preprints, the OWASP Non-Human Identities Top 10, two vendor research reports on credential leakage and existing RedactSure research pages. Sources were read between October 20, 2026 and October 21, 2026. Quoted facts are cited to the page that states them, and the leak figures are cited as the publishers reported them, not as independently measured. The page is a reading of public documents and should be read with each vendor's current documentation open, since the products change frequently.

RedactSure did not test Claude Code, Devin, Vault or Firecracker hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader. The tables summarize the documentation as read and are not configuration guides. The research preprints concern attacks and defenses in general; the Progent abstract gives no figures, and the coding editor study gives no trial counts or tool versions, so each is cited for its stated result only. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. Examples describe record types, a task scoped to one repository, read access and one run, and not organizations.

Determinations about whether a scope meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against its own repository, repeated after each release, since a change to a sandbox, a permission system or a credential broker would change the answer. The date on this page marks when the documents were read, and a later release should be treated as unreviewed until the test is repeated.

What the record shows

The documentation and the research give a consistent answer. The least access for a coding task is read on the files the task touches, write inside the repository or sandbox, and the results of credentialed calls, with the credential kept outside the agent. The vendor pages describe pieces of that set, a scoped short-lived credential in a cloud session, a minutes-long single-credential token, a session-scoped credential and a read-only default token, and none of them describes who approved each consequential action or what the model read on a page. The attack research shows what an agent with more than the set can be made to do. Full access persists because scoping per task is effort, and a per-task plan is what removes it. One way to test it: name one agent and one task, write down the files, the write location and the calls it needs, run it, and compare what it held with what it used.

Frequently asked questions

What is the least access a coding agent needs to finish a task?

Three things, each scoped to the task. Read access to the files the task touches, which can be named before the run. Write access to a branch inside the sandbox or the working copy, not the default branch or the developer's home directory. And the result of any credentialed call, such as a pull request number or a CI report, with the token that made the call held by a component outside the agent. Anything beyond that set is surplus the task cannot use and an attacker can.

Why does the agent usually have more than that?

Because it runs as the developer. Claude Code's documentation says the boundary is a permission prompt, so an approved command can write anywhere the user account can, and the same is true of any agent launched from a developer's shell with the developer's environment. Narrowing access per task means deciding paths, minting a credential and revoking it afterward, which is more effort than approving a prompt. The prompt gates the action, but it does not shrink the access behind it.

Does a short-lived credential solve the problem?

It solves part of it. HashiCorp's tutorial describes a token that is read-only, repo-only, scoped to a single credential and short-lived, with lifetime cut from days or weeks to minutes, which limits what a leaked token is worth. The wrapper script still exports it into the agent's environment, so the agent process holds the raw value for those minutes. Scope and lifetime shrink the blast radius; keeping the credential outside the agent, and passing back only the result, removes it.

Can the agent finish a task if it never sees the credential?

Yes, when a component outside the agent makes the credentialed call and returns the result. Devin's documentation binds credentials as environment variables for shell commands and types values directly in the browser, so in those paths the value is present in the agent's environment. Meta's Muse design, by contrast, routes credentials through surrogate tokens the agent never sees. The task needs the pull request to exist or the test to run; it does not need the string that authorized it.

What should the plan for one task contain?

A list of the files and directories the agent may read, the branch or sandbox it may write to, each credentialed call it may request and who approves each one. For the unit test example, that is the test directory, the module under test, a feature branch and a single CI trigger approved by the developer. Write it before the run, issue access against it, and keep the record of what the agent read, wrote, called and had approved, so the next task starts from it.

Does least privilege cover what the agent reads on a page?

No. Least privilege governs actions and credentials, and an agent can satisfy it in full and still hold every record it was shown on a settings page or a console. That is a separate control, least exposure, which replaces values with placeholders before the model reads the screen and resolves them only at the approved destination. On this page the two are complementary: scope governs what the agent may do in the terminal and the repository, and the governed environment governs what the agent sees on a rendered page.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Keeps a Scoped Agent From Reading the Key

An agent can satisfy least privilege and still hold every value it was shown, because scoped tokens are exported into its process and key pages show the key.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the agent fixing the unit test opens the CI settings page, the key enters its context, and an injected README can request it. Inside the governed environment: the page renders KEY_001, the agent finishes on the placeholder, and the real value is used only in the push a named person approves. Sandbox access stays with the broker.

RedactSure is deploying now with enterprise and government customers. An approved Claude Code Bash command can write anywhere the user can.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

The least access an agent needs to finish a task rarely includes reading the key itself. Bring a task your agent already finishes and see, with test values, the agent finish it on the placeholder. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.