Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Does Least Privilege Look Like for Coding Agents?

Least privilege for a coding agent is a grant written before the task starts: one task, one scope, a credential the agent never holds, and a named approval for anything consequential. Check whether your agent's grant is a record you can read or a habit you hope it keeps.

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

Security leaders who approve coding agents are working from a definition of least privilege that was written for a workforce. A person is granted the access the job needs, the person knows what the job is, and the grant can be reviewed later by asking what they were doing. An agent has the same access needs and none of the same anchors: its understanding of the job is rebuilt at every step from the pages, files and tool output it reads, and that text is exactly what an attacker can write. Least privilege for a coding agent therefore has to be a record made before the run, naming the task, the resource, the action, the expiry, the approver, and what the agent never holds at all. The sections below take those clauses in turn, then the vendor documentation that covers each one, the part a scoped grant does not reach, and the test a team can run on one task. The first section states what a page-level control can and cannot govern, because most of a coding agent's privilege sits in the terminal. The distinction between what an agent may do and what it may hold runs through the page, because only the first half fits in a permission rule, and the second half is where a coding task surprises the team that reviewed the first. A grant nobody can read after the run leaves its approver accountable for work no one can reconstruct.

Key findings

  • In a study of agentic coding editors, "attack success rates can reach as high as 84% for executing malicious commands," so the grant a run holds matters more than the model that proposes the command (Liu et al., 2026).
  • A privilege-control layer that rewrites each tool call to what the task actually needs "significantly reduces attack success rates while maintaining high utility," its authors report (Shi et al., 2026).
  • The 2026 DBIR reports that "hackers are shifting their focus from tricking people to exploiting systems," and that software vulnerabilities now beat stolen passwords as the way attackers get in (Verizon, 2026).
  • A law firm summary of FINRA's 2026 oversight report flags that "agents may act without human validation and may take actions that exceed the user's actual or intended scope or authority" (Debevoise & Plimpton, 2026).
  • Least privilege governs reach and credentials, not content: an agent can satisfy a per-task grant in full and still hold every record its screen showed it (Does Least Privilege Cover What an AI Agent Sees?).
  • Least exposure changes that by rendering values chosen by policy as consistent tokens before any model reads the screen and resolving real values only at the approved destination (What Is Least Exposure?).

What does least privilege mean for an agent that rebuilds its intent at every step?

The usual definition of least privilege is a rule about a person: give the worker the access one job needs, for as long as the job lasts, and nothing more. It works because the worker can be asked what the job was. A coding agent gives no such answer. It reads a page, a file or a tool response and proposes the next action from that text, so the job it is pursuing is whatever the last thing it read said it was. A per-task grant names the task, the resource and the action, sets an expiry and names the person who approves a consequential step, and anything it does not name is unavailable.

One part of a coding agent's reach is a rendered page, and it is the part a page-level control governs: dashboards, cloud consoles, repository and CI settings pages, and the sign-up and billing forms an agent fills in. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, and most of a coding agent's privilege sits in exactly those places. The split tells a team which control answers which question: a sandbox and a scoped credential answer the shell, and what the agent reads on a console page is answered at the page.

The record this page uses is one task, one grant: a task record with a single grant attached. Here the task is rotating the deploy key on a CI project's settings page, so the record holds the agent's identity, the project, the one field, a write action, an expiry, a named engineer as approver, and the screens touched. That record is what an assessor asks for, and the AICPA's trust services criteria are used "to evaluate and report on controls over the security, availability, processing integrity, confidentiality, or privacy" of a system, so an agent working inside the system sits inside the controls being evaluated, which Which SOC 2 Controls Apply to AI Agents? sets out.

Why does a rule written for people fail on an agent?

A rule written for people assumes three things a person brings: an intent that predates the task, a memory of what the task was, and a stake in the outcome. An agent has the first only as text in its context, and when an injection lands, the intent changes without anyone deciding to change it. Willison's design patterns for securing agents state the consequence of relying on the model's own judgment: "These design patterns constrain the actions of agents to explicitly prevent them from solving arbitrary tasks" (Willison, 2025). The constraint has to sit outside the model, because the model is the part the untrusted text edits.

OWASP's LLM06 entry is defined as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM," with excessive functionality, excessive permissions and excessive autonomy as its root causes (OWASP, 2025).

Least privilege for people is enforced by culture, and culture does not transfer. Google's guidance for Workspace administrators says the super admin account should be used only when needed, an instruction that depends on the admin remembering not to use it (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?). An agent that inherits an admin login does not remember the instruction; it acts on whatever page it is reading. That is the gap the three clauses close: the grant expires because a record says so, the credential is absent because the design never hands it over, and the approval is required because a person is named in advance.

What do the vendors themselves say?

Vendor documentation is thinnest on the third clause of a grant, the approval.

Doppler's page for coding agents states that you can "Give every coding agent its own scoped, read-only, expiring set of credentials" (Doppler, 2026). The same page adds that credentials are "Injected at runtime instead of written to a .env, so agents can't read, log, or commit them," though it does not say whether an agent can read the variables injected into its own process (Doppler, 2026).

Arcade frames the question a grant has to answer: "Can this agent, acting for this user, perform this action on this resource?" and adds that "Even if a user can delete files in Drive, their agent should only get read access unless deletion is explicitly needed," a rule about the action that the page does not extend to token storage or refresh (Arcade, 2025).

Anthropic's Claude Code permission page documents the file half: "To block Claude's file tools from reading a file or directory, add a Read deny rule for its path," and states the limit, that deny rules "don't apply to a command that reads files without naming them, such as grep -r pattern .", pointing to its sandbox for enforcement (Anthropic, 2026).

Teleport's framework states that "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key," and the page marks most of the capabilities it lists as in progress or not started, so the identity design is the part a buyer can rely on today (Teleport, 2026).

Dimension What the documentation states What a buyer should verify
Scope A scoped, read-only, expiring credential set per agent and per branch Whether the agent can read the variables injected into its own process
Action Agent, user, action and resource named for each request How the token is stored and refreshed
Identity A cryptographic workload identity instead of a shared key Certificate lifetime, and which listed capabilities have shipped
Path Read deny rules on named file paths Reads by a command that names no path

Microsoft's managed identity page states the credential a workload never holds: "This token acquisition doesn't require any secrets and is automatically authenticated based on the environment where the code runs," which removes the stored credential rather than narrowing what the credential reaches (Microsoft, 2026).

The third clause is the thinnest. None of the pages above describes a named approver for the specific action a run proposes.

What should a grant contain before the task starts?

A grant that can be checked has six fields. Who is acting: the agent's own identity, not the developer's session. What it may touch: one project, one field, one repository. What it may do: read, write, or a named action such as rotate. How long: an expiry that matches the task. Who approves: a named person for anything consequential. What it saw: the screens and actions, recorded.

The fourth field is the one teams get wrong, because the simplest way to give an agent deployment power is to hand it a durable key that outlives the task. Cloud providers state the rule at the top of the hierarchy, that no long-lived access key should exist for a root account (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). A deploy key in a CI project is a durable top-level credential for that project, and the grant should say when it stops working.

The second field is where one task, one grant earns its keep. A single named object means a reviewer can see that the run touched one settings page and no other. The console pages a deployment task passes through are where that difference shows (How to Use AI Agents for Google Cloud Deployment).

The sixth field separates a policy from evidence. A policy says the agent was limited; a record shows which page rendered, what the model received and who approved the write. Teleport's framework lists "Comprehensive audit trails and behavior analysis for agent actions across infrastructure" as a capability, which is the sixth field in vendor form (Teleport, 2026).

Where does a scoped grant stop short of what the agent reads?

A grant bounds what an agent may do. It says nothing about what the agent holds while doing it. A coding agent with a one-task, one-field grant that lets it read a customer record on a support console reads every field the page renders, and from that point the values are in the context with the rest of the run. The tether metaphor is useful here: a tether is a description of authority, not of capability, and an agent on a short leash still reads the whole page it is standing on (What Is a Tethered Agent?).

A grant review and a data review are therefore different exercises. Discovery and posture tools, DLP, CASB and secure access tools, enterprise browsers, AI gateways, privacy vaults and agent governance tools each operate at a different layer and answer a different question (What is the best AI data security platform?). A per-task grant sits in the access layer. The content of the page is the layer above it.

Approval does not close the gap by itself either. A named approver sees the action proposed, and if the model proposes it after reading a page full of values, the approval authorizes an action while the values stay in the context. It is not sufficient, because it governs the second half of the run.

So the honest description of a per-task grant is that it makes the blast radius small and leaves the exposure unchanged. An agent can hold a grant that names one field and still carry every value it read on the way to that field.

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 with a project name and KEY_001 where a deploy key sits. Real values resolve only at an approved destination, at the moment of an approved action, and a named person confirms the policy that decides which values are substituted and approves each consequential action. Every screen as tokens, every action and every approval are written to a record that exports to the organization's own monitoring.

For the question on this page, the control class adds the clause a per-task grant cannot carry. A grant written before the run bounds what the agent may touch; it cannot bound what the page it touches shows. The render layer bounds that, screen by screen, for the life of the run, and the record then holds both halves together: the grant that authorized the run and the tokens the model saw inside it.

Two properties follow. The control is model agnostic, because it acts on the page rather than on the model. It is also narrow: it governs the rendered page and not the terminal, the IDE, the local filesystem, direct API calls or MCP, so a task that needs a shell still depends on the sandbox and the scoped credential. The two records answer different questions: what the agent was allowed to do, and what it was shown.

Methodology and limitations

This page rests on two research preprints on privilege control and injection in coding editors, vendor documentation from five vendors, one standards entry, a law firm summary of a regulator's oversight report, an industry breach report, one practitioner analysis, and existing RedactSure research pages. The vendor pages were chosen because each documents a mechanism the grant uses: a scoped credential, a per-action question, a workload identity and a path rule. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and figures from research preprints are cited as their abstract pages report them, not as independently measured.

RedactSure did not test any of the named products hands-on. Where the page says a behavior is not described in the pages reviewed, it means the documentation listed in Sources does not state it, not that a vendor does not do it. A vendor page that does not mention a control may still describe it elsewhere; this page cites only the pages listed. Vendor features change, and the page carries its date; a release after that date is unreviewed until the same questions are asked of it. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, one task with one grant on a CI project's settings page, and not an organization.

Determinations about whether a grant meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers. Where the page draws a conclusion, it is a reading of those documents and not a legal or audit opinion. Nothing here replaces a review of the organization's own agent against its own task list, repeated after each release.

What the record shows

The answer the record supports is narrower than the phrase least privilege usually carries for the security lead who signs off on a coding agent. A per-task grant bounds what an agent may touch, a credential the agent never holds removes the credential from the run, and a named approval decides the one action that matters; each is documented somewhere in the vendor pages reviewed, and none changes what the model read on the way. The research record explains why that matters more for an agent than for a person: the intent is text, the text is writable, and the commands a coding editor can be made to run succeed often enough to plan around rather than hope against. Least exposure is the clause that reaches the page, and RedactSure's environment is built on it. Putting one agent and one task to that test comes down to three steps: write the six fields of the grant down, run the task, and compare what the record says the agent saw with what the page rendered.

Frequently asked questions

What does least privilege look like for a coding agent?

Three things written down before the task starts: a grant that names one task and one scope, a credential the agent never holds, and a named person who approves anything consequential. The grant also sets an expiry and produces a record of the screens and actions. The test of the definition is whether you can read the grant and then say what the agent could touch, for how long, and who said yes, without asking the agent to explain itself afterward.

Does a scoped credential count as least privilege on its own?

It covers one clause. A credential scoped to one repository, read-only and expiring at the end of the task removes the standing key and the shared login, which is most of the practical risk in a coding agent's setup. It does not bound what the agent does with the pages that credential opens, and it does not name an approver. Scope the credential, then write the other two clauses, because the first is the easiest to buy and the least complete, and the third is the one nobody sells.

Who should approve a coding agent's action?

A named person inside the organization, not the model and not the vendor's review model. The approver should see the action and the resource, and should be someone who would recognize a wrong destination. An approval that arrives as a batch of yesterday's actions is a notification, not a decision. What makes it an approval is that a name, a time and the specific action end up in the record together, where a reviewer can find them weeks later without reconstructing the run.

Do deny rules in a coding agent cover least privilege?

They cover a path, and only for the tools that honor them. A Read deny rule stops the agent's file tool from opening a named path, which is useful and cheap, but the documented limit is that a command which lists and reads files without naming them is outside the rule, and the vendor points to an operating-system sandbox for that case. Treat a deny rule as one field of the grant, not as the boundary itself, because the path is the smallest part of what a task touches.

Where does a per-task grant stop short?

At the content of the page. A grant can say the agent may read one record and write one field, and the page that renders the record can still show every value in it, which the model then holds for the rest of the run. That is a data question rather than a permissions question, and it is why least exposure is a separate control with its own record of what each screen rendered, which is the record a data-protection review asks for first.

How would a team test its own agent's grant?

Take one task, write the six fields on one page, and run the task with the grant in place. Then read the record and answer three questions: did the agent touch anything outside the named resource, did any credential appear in the transcript, and did the approval name the action that actually ran. A grant that fails one of the three is a policy rather than a control, and the next task will show the same gap in the same place.

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 Writes a Task Grant Before the Agent Reads a Page

The designs reviewed put scope, expiry and identity in the credential, while a per-task grant must be written before the run because the run re-derives intent.

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

Before, the agent opens the CI project's settings page with an engineer's own session, and the key field renders to the model as the key itself, which then sits in the transcript. Inside the governed environment the same page renders with KEY_001, the grant names one project and one write, and the key resolves only when the named engineer approves the rotation.

RedactSure is deploying now with enterprise and government customers. Coding editors have run malicious commands at rates as high as 84%.

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

See it on your own workflow

Least privilege for agents starts with what the agent reads, not only with what the token allows. Bring a CI task and see, with test values, the grant that names one project and one write. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.