Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can a Coding Agent Approve Its Own Permission Request?

No, not where the approval requires an act the agent cannot perform: a grant signed with a credential the agent does not hold, on a channel it cannot reach. In a design where the request and the answer pass through the same process, or a mode answers in advance, the agent effectively approves itself.

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

An approval is a check only when the agent making the request cannot supply the answer. A coding agent that wants to add a deploy key, create a token or widen a cloud role makes a request, and the shape of that request decides who is really answering: a person holding a credential the agent does not have, or the same process that asked. The interface can look identical in both cases, which is why the question is worth settling in a design review rather than after an incident. A useful answer names the component that holds the credential, not the screen that shows the request.

The sections below follow one request through a repository settings page. The first sets the scope, because a coding agent moves between rendered pages and a terminal and a browser control governs only the first. The next follows the request through the permission rules and sandboxes that vendor documentation describes, and asks what a grant has to require before an agent cannot sign it for itself. The last sections set out what a self-granted scope exposes and state the control class that answers the question without naming a product.

Key findings

  • Anthropic's engineering write-up states that sandboxing "safely reduces permission prompts by 84%," the direction of travel here: fewer prompts mean fewer moments at which a person is asked (Anthropic Engineering, 2025).
  • Datadog's 2025 report states that "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions," long-lived identities in automation that no separate approver signs for (Datadog, 2025).
  • Anthropic's permission page states that "If your project has a .claudeignore file, it has no effect," so a rule a reviewer finds in a repository is not necessarily one the harness honors for the agent's file reads (Anthropic, Configure, 2026).
  • A law firm's summary of FINRA's 2026 oversight report states that "Agents may act without human validation and may take actions that exceed the user's actual or intended scope or authority," the failure a self-answered prompt produces (Debevoise & Plimpton, 2026).
  • A governed environment substitutes tokens for real values before any model reads the screen, so an agent's request to widen access is composed against placeholders rather than live customer data (Enterprise Browser or Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, and every screen, action and approval is written to a record that names the person who answered (What Is an AI Control Record?).

What does a governed browser environment cover when a coding agent asks for access?

The scope comes first because a coding agent works in two places and only one of them is a page. A governed browser environment covers what an agent reads and does on a rendered page: a repository settings page, a cloud console, an admin dashboard, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. When an agent asks to run a shell command, the request belongs to its harness and to whatever sandbox the user configured, and Anthropic's sandboxing page describes that boundary: the sandbox covers shell commands only, while Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks run outside it (Anthropic, Sandboxing, 2026). When the same agent asks to add a deploy key on a settings page, the request is a page action, and a control that governs the page can see it.

That split decides what the title question can mean. An agent that asks its harness for a shell command has no page in the loop, so a page control has nothing to say about the answer. An agent that opens a settings page and submits a form is asking through a page, where an approver, a destination and a record can exist.

Keep the scope in view when a demo shows an agent clicking through a console. The click is inside the governed boundary only if the console was rendered to the agent, and the deploy key it creates is a grant the agent then uses in the terminal, outside that boundary (Enterprise Browser or Render-Layer Tokenization?).

Where does the approval happen in a coding agent's permission flow?

Every permission flow has three parts: the agent proposes a tool call, the harness checks its rules, and something answers when the rules do not decide. The answer can come from a rule written earlier, a mode that answers in advance, or a person at the keyboard. Only the third is a decision about this request.

Anthropic's permission page shows how much is settled before the agent asks anything. It states that "To block Claude's file tools from reading a file or directory, add a Read deny rule for its path," and adds that deny rules "don't apply to a command that reads files without naming them," which is about terminal access rather than the file tools (Anthropic, Configure, 2026).

The design direction is fewer decisions at the moment of the request. The 84% figure above is a benefit for anyone tired of approving commands, and it has a second reading: the actions that no longer prompt are actions nobody answered.

That is why "a human is in the loop" is not yet an answer. The loop can be a rule set last quarter, a mode switched on once, or a click at the end of the task. An agent handed the account's admin login described in Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? is answering its own request in the widest sense, and a browser agent using the default automatic approval recorded in Does Claude in Chrome Use Your Saved Logins and Open Sessions? answers in the same session.

What do the vendors themselves say?

Three vendors document parts of this flow, and each covers a different part of the answer.

Anthropic's Claude Code pages describe the harness end. The permission page defines deny rules over the agent's file reads and the sandboxing page defines what the sandbox encloses, while the mask setting shows the limit of the value handling: a sandboxed command sees a sentinel and a local proxy substitutes the real value on listed hosts. What those pages decide is what may run and what a command can reach. What they do not describe is an approval act performed by a named person for a specific request, and the prompt they do describe is answered inside the session the agent runs in.

Teleport's documentation takes the identity route and is explicit about why: "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key" (Teleport, 2026). The same page lists "Comprehensive audit trails and behavior analysis for agent actions across infrastructure," a record of what the agent did rather than of who permitted it, and it marks most of the capabilities it lists as "In-progress" or "Not started," so the framework is a direction as much as a shipped control (Teleport, 2026).

Cognition's Devin guide shows the agent handling the value itself: "In the browser, Devin types the value directly," and for shell commands it binds credentials as environment variables whenever needed (Cognition, 2026). Whether the model sees a value Devin types in the browser is not described in the pages reviewed.

Dimension Anthropic, per its documentation Teleport, per its documentation What a buyer should verify
Who answers a request Permission rules and prompts, answered in the session the agent runs in An agent identity tied to where it runs, with most listed capabilities marked "In-progress" or "Not started" Which person performs the approving act, and on what device
What the sandbox covers Shell commands only; Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks run outside it Not a sandbox; the framework governs identity and audit Whether the tools that change access sit inside or outside the boundary
What the record holds Permission decisions and sandbox behavior, as the pages describe them "Comprehensive audit trails and behavior analysis for agent actions across infrastructure" Whether the record names an approver or only an actor
Agent identity The harness runs as the developer An identity tied to the running agent Whether the grant is bound to the person or to the software

What makes an approval one the agent cannot give itself?

The test is not whether a person sees the request but whether answering it requires something the agent does not have: a key held on another device, a confirmation delivered on a channel the agent cannot read, a signature that binds the grant to the person who gave it. Each is an act a model driving a page cannot perform.

The record scenario is a request on a repository settings page, where the agent wants a deploy key added so it can push. In the first arrangement the agent opens the page with the account's session, fills the form and submits it. The confirmation is a button in a page the agent is already driving, so the agent presses it, and nothing in the run records a person deciding anything.

In the second arrangement the page still renders the request, but the grant takes effect only when a person signs it. The agent can fill the form and choose the scope it asks for; it cannot supply the signature, because the key sits on a device it does not control. The difference is not the interface but which component holds the credential.

The person who signs also answers for the action, which is why the arrangement records a name rather than an event (What Is Supervised Delegation?). FINRA's 2026 oversight summary makes the same point from the audit side: agent chains "may be difficult to reconstruct, complicating auditability" (Debevoise & Plimpton, 2026).

The practical check is what the agent would need to approve its own request. A click, a keystroke in the same session or a token it already holds, it can supply. A key on another device or a second channel it cannot open, it cannot. A workflow that stops at the five irreversible steps in How to Use AI Agents to Launch an EC2 GPU Instance applies the rule before the fact.

What happens when the agent can approve itself?

A self-answered request leaves no moment at which the scope is argued about, so the exposure accumulates. The grant is chosen by the component that benefits from it: an agent blocked by a read-only token asks for a write token, a deploy key, or a scope that outlives the task because the task will need it tomorrow. Each grant is defensible in isolation; the sum is an identity with more reach than the work required.

OWASP's non-human identity list gives the two names that apply: NHI2, the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores," and NHI5, overprivileged identities (OWASP, 2025). Both describe access that grew faster than the review of it.

Datadog's 2025 report records that in 2024 it "identified thousands of malicious PyPI and npm libraries in the wild" (Datadog, 2025). A grant given to the agent is a grant given to every dependency running beside it.

Verizon's 2026 DBIR landing page states that "Hackers are shifting their focus from tricking people to exploiting systems" (Verizon, 2026). A self-approving agent is the exploited system in that sentence, and the page puts software vulnerabilities ahead of stolen passwords as the way in.

The credential material already exposed matters beyond one repository. GitGuardian's data, as reported by Help Net Security, counted "28,649,024 new secrets exposed in public GitHub commits across 2025," with commits co-authored by an AI coding agent leaking at roughly double the baseline (How Do You Let an AI Agent Manage API Keys Without Reading Them?). More autonomy over credentials adds to that population.

What does a governed environment change?

A governed environment is a control class that acts before the model does. Values chosen by policy are replaced with consistent tokens for the whole run, so a request to widen access is composed against a token such as REPO_014. Real values resolve only at the approved destination, at the moment an approved action is taken. A named person confirms the tokenization policy and approves each consequential action. Every screen as tokens, every action and every approval goes to a record that exports to the organization's own monitoring.

For this page's question, the change is where the answer comes from. The model can still propose a grant; what changes is that the proposal is not the approval. The approval is an act by a named person, performed on a channel the agent does not hold, and it is written down with the scope, the destination and the time. The record then answers the two questions an auditor asks after a bad grant: what the model saw when it asked, and who said yes.

The class also sets its own boundary. It governs the rendered page, and it does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP. A deploy key created through a governed settings page is approved there, and the push it enables happens in the terminal, under whatever rules the team set for the harness. A narrow standing for the approver belongs to the same idea: the guidance for Workspace administrators that a super admin account should be used only when needed is written for people and applies with more force to a software agent (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?).

Methodology and limitations

This page rests on vendor documentation from Anthropic, Teleport and Cognition, a law firm summary of FINRA's 2026 regulatory oversight report, an OWASP standard on non-human identity risks, two industry reports from Datadog and Verizon, and existing research pages on agent accountability, records and scope. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quoted passages are cited to the page that states them, and where a figure reaches this page through a law firm's summary of a regulator's report, the wording is the summary's rather than the regulator's own. Figures from industry reports are given as the report states them, with the sample limitations noted where the report itself notes them.

No product named here was tested hands-on. "Not described in the pages reviewed" means the recorded pages do not cover a behavior, not that the product lacks it, and every vendor feature is given as its documentation states it. Vendor features change, and the page carries its date, so a release after it is unreviewed until the check is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The worked example describes a record type, a permission request made on a repository settings page, and not an organization.

Determinations about whether an approval flow meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's agent against its own permission model, run with the vendor's current release notes open beside it.

What the record shows

The evidence points one way. Vendor documentation describes what may run and what is isolated, and leaves the answer to a request inside the agent's own session or in a rule written earlier. FINRA's summary names the result: agents that act without human validation and exceed the scope the user intended. A design that makes the answer no moves the approval out of that process and requires an act the agent cannot perform, with the destination and the approver written down; RedactSure builds its environment on that arrangement. The two arrangements in the worked example differ in one field of the record: whether it holds a signature or a click. Before relying on either arrangement, a team should test it: name one agent and one request, ask it to add a deploy key on a settings page, and write down who signed, on what device, and what the model saw when the page rendered.

Frequently asked questions

Can a coding agent approve its own permission request?

It can when the request and the answer pass through the same process. An allow rule written earlier, a mode that answers in advance, or a confirmation button on a page the agent is already driving are all answers the agent can obtain without a person acting at that moment. It cannot when the grant needs a signature from a key on a device the agent does not control. The check is the answer's source, not the prompt's appearance. Ask which of those your tool does.

Which requests count as permission requests?

Any widening of what the agent may do: a shell command outside its allow list, a write to a path it could not reach, a network destination it has not used, or a change on a settings page that creates a credential. The last kind is the one a page control can govern, because it is a rendered form rather than a terminal command. The first three belong to the harness and the sandbox. A deploy key made on a page and used from a shell needs both.

Does an allow rule count as a person approving?

A person approved a class of actions when the rule was written, which is a real decision and worth recording. It is not a decision about this request, and it cannot weigh a scope the agent chose after reading a page. A rule written for a person's convenience becomes a grant an agent inherits without review. The distinction matters when an incident is reviewed: a rule shows what someone permitted in general, and only a per-request approval shows who allowed this grant. Keep both in the record.

Can a sandbox replace an approval?

No. A sandbox limits what a process can reach, and the vendor documentation is clear about how far that goes: Anthropic confines its sandbox to shell commands while Read, Edit, Write, WebFetch, WebSearch, MCP servers and hooks run outside it. Those outside paths are where a credential often travels. Isolation answers what is reachable; approval answers who allowed this action. A design needs both, and one does not substitute for the other.

What should the record of an approval contain?

The scope that was granted, the destination it applies to, the person who signed, the device or channel used, and the time. Add what the model saw when it made the request, because that shows whether the request was formed on real values or on tokens, and whether a person or a mode supplied the answer. FINRA's summary notes that agent chains may be hard to reconstruct, and a record with those fields is what makes reconstruction possible after the fact.

Where does a governed environment fit?

On the rendered page where the request is made. It replaces values with tokens, keeps the real ones until an approved destination needs them, and puts a named person in the approving act rather than inside the agent's process. It does not follow the grant into the terminal, so the harness rules still matter. The page control records the signature; the harness records the command. The two controls answer different halves of the same question.

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 Makes the Approval an Act the Agent Cannot Perform

A permission prompt inside the agent's own process can be answered by the agent, and the designs above leave the grant inside that loop.

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

Before: the agent opens a repository settings page with the account's session, and a confirmation there is the gate. Inside the governed environment, the page renders as tokens and a named person signs on a channel the agent does not hold. The key resolves at the repository, and the approval enters the record with a name.

RedactSure is deploying now with enterprise and government customers. FINRA's 2026 summary records agents that "may act without human validation."

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

See it on your own workflow

An approval is only worth recording if the agent cannot produce it. Bring a change your team signs off on today and see, with test values, where the approval comes from and whose name the record carries. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.