Data Report · By Chris Sowa · Published
Last updated
Can a Coding Agent Ask for More Access When It Needs It?
Yes, by asking: a mid-task request should produce a new permission slip that names the scope, the reason and the duration, and a person decides it. The agent must never be able to grant that slip itself, so check where the approval lives and whether the agent can write to it.
An agent that meets a permission wall halfway through a task has two options, and only one of them is safe. It can stop and ask, producing a request that names the repository, the branch and the operation, which a person with authority then approves or refuses. Or it can find a way to widen its own reach, either by using a credential broader than the task needs or by changing the rule that governs it. The first is how delegated work is meant to function. The second is how escalation happens, and what separates the two is where the decision sits and whether the agent can reach that place, rather than anything about the model.
This page takes the request half, the one that is easy to leave unexamined because asking looks harmless. One record type runs through it: a coding agent that needs push access to a branch midway through a change, and the page on a code host where that access is requested or refused. The page sets the scope of a browser control first, then separates a request from a grant, reads what Teleport, Cognition, gVisor and Browserbase document about identity, credentials and sessions, and closes with the fields a team should require of a request before anyone approves it.
Key findings
- Privilege control research reports that "Progent significantly reduces attack success rates while maintaining high utility," the case for treating a mid-task request as a decision rather than a formality (Shi et al., 2026).
- A study of agentic coding editors reports that hostile instructions reach command execution at rates its authors put "as high as 84%," so the text an agent reads mid-task can author the request it makes (Liu et al., 2026).
- FINRA's 2026 oversight report, summarized by Debevoise & Plimpton, 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).
- Teleport's framework states that "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key," while the same page marks most of its listed capabilities "In-progress" or "Not started" (Teleport, 2026).
- A governed environment replaces values chosen by policy with consistent tokens before any model reads the screen, so an agent that requests push access works with REPO_014 and BRANCH_003 while the decision is pending (What Is Render-Layer Tokenization?).
- Real values resolve only at the approved destination at the moment a named person approves the action, which makes a granted request a dated decision with a person attached rather than a standing key (What Is Supervised Delegation?).
What does a request for more access look like on a rendered page?
The record type for this page is a coding agent midway through a change on a repository it can clone and read but not push to. It finishes the edit, tries to publish the branch, and the code host refuses.
When the agent works through a browser session, the refusal lands on a page: a branch view with the push control disabled, or an access request form that asks for the permission level, the reason and sometimes a duration. A governed browser environment covers what an agent reads and does on that kind of page, dashboards, consoles, settings pages and sign-up forms included. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. Most of a coding agent's reach sits in those places, and a push attempted from a shell never reaches a page at all.
The page still matters, because the permission that allows the push is usually created on one. Repository settings, collaborator pages, deploy key screens and token scope pages are all rendered pages, and each is where a standing credential gets made. The choice at the refusal is between asking for a narrow grant and shipping the agent with a wide one.
The second choice is the common one, and it leaves a trace. Datadog's 2025 DevSecOps report, drawn from its own customer base, states that "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions," an identity that already covers the work and therefore never generates a request (Datadog, 2025). Can I Grant a Coding Agent Clone Access but Not Push Access? works through the split between reading a repository and writing to it; this page covers the request in between.
Why is asking for access different from being granted it?
A request is what the agent produces: this task needs push access to this branch, for this long, for this reason. A grant is what a person with authority produces: a decision that the request is allowed, at a narrower scope, with a name and a time. A grant should be writable only by someone who could give the access away.
OWASP's non-human identity list treats the second half as the recurring failure. NHI5 is overprivileged identities, and NHI2 is the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores" (OWASP, 2025). A standing grant fails both ways at once: nothing is held between tasks to leak, and nothing is over-privileged if access arrives per decision.
FINRA's 2026 oversight report adds the audit half. It warns that agents "may take actions that exceed the user's actual or intended scope or authority" and that agent chains "may be difficult to reconstruct, complicating auditability" (Debevoise & Plimpton, 2026). A request answers both: it states the scope in advance and records who accepted it.
Privilege control is the mechanism, and it has been measured. Progent's authors report that their approach "significantly reduces attack success rates while maintaining high utility," evaluated on the AgentDojo and ASB benchmarks (Shi et al., 2026). The abstract gives no numbers, so the claim is about the mechanism. Can a Coding Agent Escalate Its Own Permissions? covers the case where the agent writes the rule instead of asking.
What do the vendors themselves say?
Teleport's framework states that it provides "Comprehensive audit trails and behavior analysis for agent actions across infrastructure," and the same page marks most of its listed capabilities "In-progress" or "Not started," so the audit trail is a stated design rather than a shipped control (Teleport, 2026). Nothing on it describes who approves a scope change.
Cognition's Devin guide documents four credential scopes, organization, personal, repository and session, and states that session credentials are "scoped purely to the current session and are not saved for any future sessions" (Cognition, 2026). It also describes the route a credential takes: "In the browser, Devin types the value directly," shell commands receive credentials "as environment variables whenever needed," and "All secrets are encrypted at rest" (Cognition, 2026). Whether the model sees the value is not described in the pages reviewed, which is the question a request turns on.
Browserbase's Contexts page describes a persisted browser profile: "Once created, a Context persists until you explicitly delete it or it becomes invalidated," and Contexts are "uniquely encrypted at rest" (Browserbase, 2026). A profile holds cookies and local storage, so access granted in one task can survive into the next, a grant with no expiry on any page.
gVisor's production guide states that "While gVisor is able to sandbox any application, it should generally not be used to sandbox every application," and that "sandboxing has a performance penalty" (gVisor, 2026). A boundary with a cost is one teams widen, and a widened boundary is where standing access comes from.
| Dimension | Teleport, per its documentation | Cognition, per its documentation | What a buyer should verify |
|---|---|---|---|
| Who is asking | A per-agent cryptographic identity tied to where it runs | Credentials scoped to organization, personal, repository or session | Whether the request carries the identity of the run or the person's login |
| What the grant covers | Not stated on the page | A session scope that is not saved for future sessions | Whether the grant can be narrowed to one branch and one operation |
| Lifetime | No certificate lifetime given | Session credentials end with the session | When the grant expires, and who may renew it |
| What the model reads | Not stated on the page | The browser step types the value directly; the shell binds it as an environment variable | Whether the page shows the value or a token |
| Record | Audit trails listed as in progress | Encryption at rest; no approval record stated | Whether the record names the approver and exports to the customer |
What does the research record show about a request made mid-task?
An access request is text produced by a model, and the model producing it has been reading material the team does not control: issue bodies, pull request comments, README files and tool output. That places the request in the same category as any other model output, which is why it should be decided where the model cannot reach.
The clearest measure is a study of agentic coding editors, which reports that "attack success rates can reach as high as 84% for executing malicious commands" (Liu et al., 2026). The abstract gives no trial counts and no tool versions, so the figure locates the risk rather than describing a named product. It establishes that instructions reaching an editor can produce actions, and a request for access is among the cheapest to produce, because it needs only text.
The supply chain supplies the pretext. Datadog reports that "Throughout 2024, Datadog identified thousands of malicious PyPI and npm libraries in the wild" (Datadog, 2025). A malicious dependency arrives with a plausible reason to ask for a new scope: a registry token, a build permission, a host on the network list. The request can be honest about the task and still be wrong about the package.
None of this argues for refusing every request. It argues for deciding the request outside the model's reach, at a scope narrowed to the task and with the reason on the record. The credential design that already works this way for API keys is covered in How Do You Let an AI Agent Manage API Keys Without Reading Them?, and the principle carries over: the agent states the need, and the value is attached by something the agent does not read.
What should a team require of the request itself?
Five fields make a request decidable. Who is asking, as an identity for the run rather than the user's login. What is being asked for, at the level of a repository, a branch and an operation rather than a role name. How long it is needed, expressed as an ending condition. Why the current task needs it, in words a reviewer can check against the change. And what the agent will read once the scope is live, because a wider page is also a wider view.
The identity field is the one teams configure least carefully. A shared credential is easier to wire up than a per-run identity, and it removes the request entirely, which is why the standing identity keeps appearing in the data.
Two failure modes deserve a line in a review. The first is a request channel that grants on a timeout, which turns an unanswered question into a permanent permission. The second is a browser session that outlives the task, where a grant made for one page is still available on the next. A queue with a short default lifetime and a session deleted at the end of the run are both cheaper than the incident they prevent.
The record is the last field and the one that makes the other four auditable: the request as written, the scope granted, the person who granted it, the time, and what the page showed the model. What Is an AI Control Record? sets it out, How Do I Revoke a Coding Agent's Access Mid-Task? covers the ending, and Is It Safe to Let an AI Agent Set Up Your Cloud Environment? covers the durable credential a request replaces.
What does a governed environment change?
A governed environment is a control class that acts where a page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so a request made on a repository page is made against REPO_014 and a branch token rather than the names that identify the organization. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, and an access grant is one. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.
For this page's question, the control class separates the two halves in a way a request form cannot. The request stays the agent's work: it names the operation and the reason, and it can be proposed by a model that read a hostile file. The decision is not the agent's, because the page where the decision is made renders with tokens, the request arrives as a proposal to a named reviewer, and the real names resolve at the code host only after that reviewer approves. A run that never receives approval never sees the real values, so a hijacked agent's request is a proposal that was refused rather than an escalation that succeeded.
The scope is the rendered page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so a grant that arrives as a token in a shell environment remains the territory of the sandbox, the token scope and the revocation process. Within the page, three properties are separable and testable: tokens before the model reads, real values at the approved destination only, and a named approver with an exported record.
Methodology and limitations
This page rests on two research preprints, one on privilege control for agents and one on prompt injection against agentic coding editors; vendor documentation from Teleport, Cognition, gVisor and Browserbase; one law firm summary of a regulator report; one OWASP standard entry on non-human identity risks; one vendor research post from Datadog; and existing RedactSure research pages. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and figures from the preprints are reported as their abstracts give them, without independent measurement.
RedactSure did not test any of the products hands-on. Where this page says a behavior is not described in the pages reviewed, that means it is absent from the documentation listed, not established as absent from the product. Vendor features change, and the page carries its date, so a release after that date is unreviewed until the checks are repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a coding agent asking for push access to a branch on a code host, and not an organization. The research figures locate a risk; neither abstract gives trial counts, tool versions or a full method, so they are not a ranking of defenses.
Determinations about whether an access control 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 own agent, its request flow and its approval record, run against a page the agent can actually reach.
What the record shows
The two halves of the answer have different owners. A coding agent can ask for more access, and the research on privilege control says deciding such a request at the point of use reduces attack success while keeping the work possible; that half a team can build. The half it cannot delegate is the grant, because a grant written by the agent is not a decision by anyone, and the failure modes on this page, from the overprivileged identity in the OWASP list to FINRA's agent acting beyond its intended scope, are grants that outlived their reason. The vendors reviewed supply pieces of the first half: an identity for the run, credentials scoped to a session, a profile that can be deleted. None supplies the second half alone, which is the part RedactSure's environment is built around. For any one agent and one mid-task request, a team should be able to pass a simple test by saying who approved it, what the page showed the model, and when the grant expired.
Frequently asked questions
Can a coding agent ask for more access when it needs it?
Yes, and the request is the part worth designing. An agent that cannot ask will either fail the task or be deployed with access wide enough to avoid asking, and the second outcome is worse because it is invisible in the logs. A request should name the operation, the resource, the duration and the reason, and it should reach a person who can grant that scope. An agent that asks well is easier to supervise than one that never needs to.
Should an agent be able to approve the access it requested?
No. An approval written by the process that benefits from it is a formality, and the privilege control research exists because that formality is common. The decision belongs to a named person outside the run, acting on a scope that person can see and narrow. If nobody is available, the default should be refusal with an expiry rather than a standing grant. Self-approval converts a request into a notification, and a notification is not a control. The approver's name is what makes the grant attributable later.
What should an access request from an agent contain?
At least five fields: the identity making the request, the exact resource and operation, the duration or ending condition, the reason tied to the current task, and what the agent will read once the scope is live. The last field matters most, because a grant that widens a rendered page also widens what the model sees on it. A request that names a scope but not the exposure leaves the reviewer judging half of the decision. Ask which of the five is missing before you read the answer.
Is an approval prompt the same thing as a grant?
No. A prompt asks a person to allow one action the model has already chosen, and it describes that action in the model's own words. A grant is a decision about a scope, taken before the action and recorded with the name of the person who took it. The gap between the two is where a hijacked run does its work, because the prompt is accurate about the command and silent about why the command was proposed. Read the scope, not the command, when you review one.
What happens to a request while the reviewer is away?
It should expire or stay pending, and the run should continue with the work it can still do. A queue that grants after a timeout is a standing credential with extra steps, and a queue that blocks the whole task teaches teams to grant broadly in advance. The useful setting is a short default lifetime with an explicit renewal, so an unread request costs the agent a step rather than the organization a permission. Then test the timeout on a dummy scope before a real request depends on it.
Does a sandbox limit what an agent may request?
No. A sandbox limits what a permitted action can touch, which is a different question from what the agent may ask for or who decides. A team can run a well-sandboxed agent that still requests a wide scope for a plausible reason, and nothing in the sandbox will flag it. Read the request flow and the sandbox as two controls, because each is blind to what the other covers. One governs reach, the other governs permission.
Related reading
What Is Render-Layer Tokenization? · What Is Supervised Delegation? · What Is an AI Control Record? · How Do You Let an AI Agent Manage API Keys Without Reading Them? · Is It Safe to Let an AI Agent Set Up Your Cloud Environment? · Can a Coding Agent Escalate Its Own Permissions? · Can I Grant a Coding Agent Clone Access but Not Push Access? · How Do I Revoke a Coding Agent's Access Mid-Task? · On the RedactSure blog: Accountable AI and Workflow Governance · What If the Agent Never Had Your Data? · RedactSure
Sources
Peer-reviewed research and preprints
-
Shi, He, Wang et al., "Progent: Securing AI Agents with Privilege Control," arXiv:2504.11703 (preprint, v3 May 2026). https://arxiv.org/abs/2504.11703
-
Liu, Zhao, Lyu et al., "Your AI, My Shell: Demystifying Prompt Injection Attacks on Agentic AI Coding Editors," arXiv:2509.22040 (preprint, revised 2026-04-28). https://arxiv.org/abs/2509.22040
Vendor documentation
-
Teleport, "Teleport Agentic Identity Framework," Teleport documentation (vendor documentation; read October 20, 2026). https://goteleport.com/docs/ver/19.x/agentic-identity-framework/
-
Cognition, "Secrets," Devin product guide (vendor documentation; read October 21, 2026). https://docs.devin.ai/product-guides/secrets.md
-
gVisor, "Production guide," gVisor documentation (vendor documentation; read October 20, 2026). https://gvisor.dev/docs/user_guide/production/
-
Browserbase, "Contexts," Browserbase documentation (vendor documentation; read October 20, 2026). https://docs.browserbase.com/features/contexts
Regulation, standards and official guidance
-
Debevoise & Plimpton, "FINRA's 2026 Regulatory Oversight Report: Continued Focus on Generative AI and Emerging Agent-Based Risks," December 12, 2025 (law firm summary of regulator report). https://www.debevoise.com/insights/publications/2025/12/finras-2026-regulatory-oversight-report-continued
-
OWASP, "Top 10 Non-Human Identities Risks 2025" (standard). https://owasp.github.io/www-project-non-human-identities-top-10/2025/top-10-2025/
Industry analysis and press
- Datadog, "State of DevSecOps 2025" (vendor research). https://www.datadoghq.com/state-of-devsecops-2025/
RedactSure documents
-
RedactSure Research, "What Is Render-Layer Tokenization?" (2026). https://redactsure.com/research/what-is-render-layer-tokenization/
-
RedactSure Research, "What Is Supervised Delegation?" (2026). https://redactsure.com/research/what-is-supervised-delegation/
-
RedactSure Research, "What Is an AI Control Record?" (2026). https://redactsure.com/research/what-is-an-ai-control-record/
-
Product behavior described on this page reflects RedactSure's current design. Third-party products are described from their public documentation as read between October 20, 2026 and October 21, 2026. Compliance determinations belong to the organization's counsel.
What Is Render-Layer Tokenization? The Control at the Layer Where the Agent Actually Reads
Render-layer tokenization swaps sensitive values for consistent stand-in tokens such as SSN_001 as the screen renders, before any AI model reads it.
What Is Supervised Delegation? Who Answers for an AI Agent, and What the Record Shows
Supervised Delegation is the operating model in which an AI agent works for a named person who grants its access, approves actions and answers for it.
What Is an AI Control Record? The Runtime System of Record for Sensitive AI Work
An AI Control Record is the complete evidence set for one governed AI workflow: what the AI saw and did, and what the named person did and approved.
How Do You Let an AI Agent Manage API Keys Without Reading Them?
Swap the key for a token as the dashboard renders it, and resolve the real value in the approved field when a person confirms. Check where keys show.
Is It Safe to Let an AI Agent Set Up Your Cloud Environment?
Only when the agent never holds root or owner credentials, works under scoped roles, and a named person approves billing, IAM and network changes.
Can a Coding Agent Escalate Its Own Permissions?
It can ask, and in documented tools the default answer is a prompt, not a boundary. An agent that can edit its own permission file has escalated.
Can I Grant a Coding Agent Clone Access but Not Push Access?
Yes, by operation: a credential can read a repository without permission to write, and a grant can name clone so a push is refused.
How Do I Revoke a Coding Agent's Access Mid-Task?
Revoke the grant where the service enforces it, at the identity provider, gateway or adapter, and the next call fails. Clearing context is a race.
Accountable AI and Workflow Governance
Explore AI agent governance for billing and claims, with named supervisors, data masking, approval boundaries and a useful audit record.
What If the Agent Never Had Your Data?
Explore AI agent security built around tokenization, controlled browser actions and human approval before sensitive payments proceed.
How RedactSure Answers a Mid-Task Request for Push Access
The tools reviewed leave the access decision inside the agent's session, where a prompt or a token stands in for a person, and record nothing the model saw.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent reads a repository page that refuses the push and shows the organization name and account list. Inside, that page renders as REPO_014, the request becomes a proposal, and the real names resolve at the code host only on approval.
RedactSure is deploying now with enterprise and government customers. Hostile instruction reaches command execution at 84% in the study above.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
Requests for more access in the middle of a task are where grants quietly widen. Bring a task that usually ends with a request for push access and see, with test values, how the request becomes a proposal a person decides. Book a demo