Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can a Coding Agent Escalate Its Own Permissions?

It can ask, and in the documented tools the default answer is a prompt rather than a boundary; an agent that can write the page or file defining its own permissions has escalated without asking. Check who can edit that definition and who approves the save.

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

Every coding agent ships with a way to ask for more room: a prompt that offers to run a command, reach the network or edit outside the project. That prompt is the visible part of a permission system, and it is the part a team reviews. The part that decides what the agent may do is the definition the prompt enforces: the sandbox profile, the allowlist, the settings page or the file that lists which commands and hosts are permitted. An agent that can write that definition does not need to win an argument with a person. It can change the terms of the next run and let the person approve a smaller-sounding action. The decision a team faces is whether the agent can edit the definition behind the prompt, and the defaults OpenAI and Cursor document are where that check starts. One record type runs through the page: a repository settings page where an allowlist of commands and hosts is edited, saved and applied to the next run. A review should follow the same order: where the boundary sits, how an agent reaches it without asking, what the vendor pages say, what the research record shows about hostile instructions, and what the record of an allowlist edit can prove.

Key findings

  • OpenAI's Codex documentation states that "Locally, Codex uses an OS-enforced sandbox that limits what it can touch" and that "Codex asks for approval to edit files outside the workspace or to run commands that require network access" (OpenAI, Agent, 2026).
  • Cursor's documentation states that "by default, terminal commands need your approval" and that "all MCP connections need your approval," while describing its run modes as "best-effort guardrails rather than a hard security boundary" (Cursor, 2026).
  • Doppler's guidance for running Codex states "Do not let the agent populate or modify its own secrets": an agent that can write the definition has escalated already (Doppler, 2026).
  • A study of prompt injection against agentic coding editors reports that "attack success rates can reach as high as 84% for executing malicious commands," a rate at which a person's review of a proposed command has to hold (Liu et al., Your, 2026).
  • A governed environment replaces a value with a consistent token before any model reads the screen, so a run that edits a permissions page works on REPO_014 and DOMAIN_003 and the record of what the model saw holds tokens (What Is an AI Control Record?).
  • A real value resolves only at the approved destination at the moment a named person approves the action, and the record carries that person's name beside the change (What Is Supervised Delegation?).

Where does a coding agent's permission boundary sit?

An agent's permission has three layers. The first is what its process may touch, which Codex documents as "an OS-enforced sandbox that limits what it can touch (typically to the current workspace)" (OpenAI, Agent, 2026). The second is what it may do without asking, documented as approvals for network commands, edits outside the workspace, terminal commands and MCP connections. The third is the definition that sets both, usually an allowlist of commands and hosts on a settings page or in a file read at startup.

The scope of this page is the rendered page. A governed browser environment covers what an agent reads and does on a page: dashboards, consoles, settings pages and forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. That limit matters: most of a coding agent's reach is in its terminal and local files.

The record type is a repository settings page on a code host, with an allowlist field listing permitted commands and hosts and a Save button. The change applies to the next run. A sign-up form belongs to the same class, which is why Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? treats a billing field as a page. The permission page is the harder case, because the value being edited is the rule that decides what the agent can do after it saves.

Three questions follow: what the agent does to reach that page, what the page shows it while it is there, and who approves the save.

Can a coding agent grant itself more access without asking?

Codex asks for approval to edit files outside the workspace or to run commands that require network access, and Cursor says terminal commands and MCP connections need approval by default.

Cursor is explicit that the prompt is not a boundary. It calls its run modes "best-effort guardrails rather than a hard security boundary" (Cursor, 2026). A guardrail can be lowered to reduce interruptions. Nothing in the pages reviewed describes a separate limit once the prompt is off, so the ask is granted by default.

The second path does not ask. An agent with write access to the allowlist page, the sandbox profile or the settings file can change the definition its next request is measured against. After the write, the command is inside the rule and the prompt may not fire. Doppler's Codex guidance states "Do not let the agent populate or modify its own secrets," and the same page says "the agent can fetch secrets, but never change them" (Doppler, 2026).

Debevoise & Plimpton's 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). OWASP's LLM06 entry describes excessive agency as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" and lists excessive permissions among its root causes (OWASP, 2025).

Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? covers the login; this page covers the rule behind it.

What do the vendors themselves say?

OpenAI documents Codex's local behavior in three sentences that matter here. Locally it "uses an OS-enforced sandbox that limits what it can touch (typically to the current workspace)," it runs with network access off by default, and it "asks for approval to edit files outside the workspace or to run commands that require network access" (OpenAI, Agent, 2026).

Cursor documents approvals rather than a sandbox. "By default, terminal commands need your approval," "all MCP connections need your approval," and the page warns that "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues" (Cursor, 2026). It does not mention a sandbox, and it calls the run modes "best-effort guardrails rather than a hard security boundary."

OpenAI's Codex cloud documentation, marked legacy, states that "by default, Codex blocks internet access during the agent phase" while "setup scripts still run with internet access so you can install dependencies," and advises teams to "allow only the domains and HTTP methods you need" (OpenAI, Codex Cloud, 2026).

Doppler's page shows what the agent process receives: "Doppler injects the config's secrets as environment variables, and Codex inherits them," so the values sit in the process the model drives (Doppler, 2026).

Whether either product records the name of the person who approved an escalation is not described in the pages reviewed. The table sets the documented position beside the question a buyer should put to each vendor.

Dimension OpenAI Codex, per its documentation Cursor, per its documentation What a buyer should verify
Default execution boundary An OS-enforced sandbox limited typically to the current workspace No sandbox stated on the security page Which process boundary holds outside the IDE
Network Off by default locally; blocked during the agent phase in the cloud Not stated on the security page Whether the agent can add a domain to its own allowlist
Escalation prompt Approval for files outside the workspace and commands needing network Approval for terminal commands and MCP connections by default Whether the prompt can be turned off per task or per repository
Credentials Not stated for local CLI or IDE sessions Not stated; no statement on how credentials are stored What the model reads when a credential is on screen
Permission definition Not stated Not stated Who may edit the allowlist, and who approves the save
Record of approval Not stated Not stated Whether the approver's name is in an export the customer holds

What does the research record show about hostile instructions?

The rate in the key findings comes from an abstract that gives no trial counts and no tool versions, so it is cited as a rate for the class, not as a measurement of any named product. It is also the rate at which the person reading a proposed command is the only thing between the agent and execution.

The Agent Security Bench paper reports "critical vulnerabilities in different stages of agent operation" and "limited effectiveness shown in current defenses" (Zhang et al., 2025). Its abstract does not say which defense performed best or by how much, which is itself the finding: the benchmark found the stage and not the fix. The prompt injection benchmark evaluates "5 prompt injection attacks and 10 defenses with 10 LLMs and 7 tasks," and its abstract reports no result figures, so it establishes a method rather than a ranking (Liu et al., Formalizing, 2024). Together the two support a claim about where failure lands: in the stages of an operation, among actions the agent is permitted to take.

That distinction is what this page needs. If the failure were a bad output, a better model would fix it. If the failure is an action the agent was permitted to take, the fix is in the permission. An agent asked to run a command because a file said so is doing what its grant allows. The prompt that summarizes the command is written by the same model that was manipulated, which is why a person can approve a command and not see the intent behind it.

A permission change is one of the few actions whose effect is to widen what later actions are allowed. The research measures attacks on operations; the operation that matters most rewrites the rule the rest of the run depends on.

What does an allowlist edit on a settings page actually change?

A repository settings page on a code host renders an allowlist field: the commands the agent may run and the hosts it may reach.

Before the save, the model reads the page, sees the current entries and the values around them, and writes a new entry. It presses Save. On the next run, the command that needs that host is inside the rule, so its prompt may not appear. The person who approved the save approved a settings change, not the command it enabled.

Microsoft's managed identity documentation states that "managed identities eliminate the need for developers to manage these credentials" (Microsoft, 2026). That is a statement about the credential, not the permission; the role assignment is where the permission boundary sits.

Three checks follow. Who may edit the permission definition, and is that role wider than the task requires. What the model reads on the page while it edits, including the names that identify the organization. Who approves the save, and what the record shows about the change. Which SOC 2 Controls Apply to AI Agents? puts the change-management question in familiar controls, and How to Use AI Agents for Google Cloud Deployment covers the deployment permissions beside this one. Does IBM watsonx Orchestrate Require Human Approval for Agent Actions? finds approval written into an agent's instructions rather than enforced by the platform.

What does a governed environment change?

A governed environment treats the permission definition as data on a rendered page, and the save as a consequential action. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the model editing an allowlist works with REPO_014 and DOMAIN_003 rather than the names that identify the organization. Real values resolve only at the approved destination, at the moment a named person approves the action. A named person confirms the policy and approves each save that changes what the agent may reach. 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 change is the difference between a request and a grant. Under the documented defaults, an agent that can write the definition has already escalated; the prompt describes the next action, not the rule change. Under a governed environment, the definition is one more screen whose values are tokenized and whose save is an approval. The agent can propose the entry, and the proposal is in the record. It cannot enact the entry without a name attached to the decision.

The scope is the rendered page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so a team still needs its sandbox, role assignments and network rules for those routes. What the governed environment adds is the part those controls do not see: the page where the rule is edited, the values rendered on it, and the approval that lets the change take effect.

That is the control class the page has been measuring: tokens before the model reads, real values only at the approved destination, a named approver, and an exported record. An agent cannot escalate through a page it cannot save.

Methodology and limitations

This page rests on three research preprints that benchmark prompt injection attacks and defenses, vendor documentation from OpenAI, Cursor, Doppler and Microsoft, one law firm summary of a regulator report, one OWASP standard entry, and existing RedactSure research pages. 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 the preprints are cited as their abstract pages report them, without independent measurement. The vendor pages are cited for what they state about defaults, sandboxes, network access and credentials; the OWASP entry is cited for its definition of excessive agency and its listed root causes.

RedactSure did not test any of the products hands-on. A behavior this page calls not described in the pages reviewed 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, an agent editing an allowlist on a repository settings page, and not an organization. The benchmark figures are reported as their abstracts state them, and neither abstract gives trial counts or a full methodology, so they locate the failure rather than rank the defenses.

Determinations about whether a permission model meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a review of the organization's own agent, its settings and its approval record, run against a page the agent can actually edit.

What the record shows

The documented defaults answer the title in two parts. A coding agent can ask for more access, and the tools reviewed put a prompt at the boundary: a sandbox limited to the workspace, an approval for network commands, an approval for terminal and MCP use. An agent that can write the definition those prompts enforce has escalated without asking, because the next run begins inside a rule it wrote. The research record makes the first part fragile: hostile instructions succeed often enough that a person reading a proposed command is the last check, and the benchmark work finds the defenses limited. RedactSure's environment puts the permission-defining page and its save inside an approval with a name and a record. For one agent and one allowlist change, a team should pass a simple test and say who approved the save, what the model read on the settings page, and whether the change outlived the run.

Frequently asked questions

Can a coding agent escalate its own permissions?

Yes, in two ways that look different. It can ask for more access, and the documented tools answer with an approval prompt for commands, network use and edits outside the workspace. It can also write the definition those prompts enforce if it has access to the settings page or the file, and then the next run begins inside a wider rule. The second is escalation without a request. Check write access to the definition before checking the prompt.

Do approval prompts stop an agent from escalating?

They stop the action shown in the prompt, for as long as the prompt is on. Cursor calls its run modes "best-effort guardrails rather than a hard security boundary," and a team can turn a prompt off to reduce interruptions. The prompt also describes the action the model chose to describe. It does not report the earlier settings change that made the action permitted. Approval is a checkpoint on a command, not a statement about the scope the command runs inside.

Can an agent edit its own allowlist?

Only if it has write access to the page or file that holds the allowlist, which is a role question rather than a model question. A repository settings page with an editing role, a sandbox profile in the working tree and a settings file the agent can open are all definitions it can change. Doppler's guidance states the rule for credentials plainly: "Do not let the agent populate or modify its own secrets." The same rule belongs on the permission definition.

Does a sandbox prevent permission escalation?

A sandbox limits what a permitted command can touch, which is not the same as limiting what the agent is permitted to run. Codex documents an OS-enforced sandbox and network access off by default, and those are real limits on the process. The definition of what the sandbox allows is a setting beside it. An agent that can edit the setting has changed the boundary the sandbox enforces, so the sandbox still holds and the rule inside it is wider.

What does the research say about prompt injection against coding agents?

One study of agentic coding editors reports "attack success rates can reach as high as 84% for executing malicious commands," without trial counts or tool versions in its abstract. The Agent Security Bench paper reports critical vulnerabilities across stages of an agent's operation and limited effectiveness in current defenses, and the prompt injection benchmark compares five attacks and ten defenses without reporting result figures. The record supports a claim about where failure lands, not a claim that any single defense works.

What should a team check before widening an agent's access?

Start with the definition. Name who can edit the allowlist, the sandbox profile and the settings file, and whether the agent's own role is among them. Then ask what the model reads on the page where the edit happens, because organization and host names on that page are values like any other. Finally, require a named approver for a save that widens scope, and a record that shows the change beside the name. A prompt on the next command does not cover any of the three.

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 an Agent From Editing Its Own Allowlist

A permission prompt reviews an action, but an agent with write access to its own allowlist can edit the rule that governs the next run.

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

Before, the agent opens the settings page, reads the real hostnames, adds an entry and saves, and the next command runs inside the wider rule. Inside, the page renders with tokens, the entry becomes a proposal, a named reviewer approves it, and the real hostname resolves at the destination.

RedactSure is deploying now with enterprise and government customers. The study of coding editors reports "attack success rates can reach as high as 84% for executing malicious commands."

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

See it on your own workflow

If an agent can widen its own allowlist, the allowlist is not a control. Bring a settings change your agent might attempt and see, with test values, how the new entry becomes a proposal a named reviewer decides. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.