Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Give a Coding Agent Access to Staging but Not Production?

Yes, when the environment is the resource the grant names and each environment holds its own credential in its own adapter. Ask which environment a credential can address, and whether the production value is reachable from the agent's sandbox at all.

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

Engineering leads who ask to keep an agent out of production usually ask in one sentence, and that sentence hides a design choice the organization will have to answer for. Production can be separated from staging by the network, by the credential, or by the grant, and each arrangement fails in a different place. A network rule is expensive to build for every environment and is only as strong as the shortest list of allowed endpoints. A credential that can address both environments is a production credential whatever the run is called. The difference shows up in a mundane failure: a staging task reads a production key out of the same configuration. A grant that names the environment as its resource, with a separate credential in a separate adapter, keeps the production value outside the agent's reach and leaves a record of which environment each action targeted. This means the grant is the separation that holds up in an audit, and the page weighs it against network separation, sets out the fields it needs and names the failures that remain. The record type throughout is two adapters and two environments, and What Is Least Exposure? supplies the vocabulary for what an agent may see while it works.

Key findings

  • Microsoft's managed identity documentation states that "This token acquisition doesn't require any secrets and is automatically authenticated based on the environment where the code runs," a credential bound to an environment, though to an Azure resource rather than to a staging grant (Microsoft, 2026).
  • E2B's documentation states that "Your sandbox configuration contains only a reference to the secret" and that "The egress proxy injects the real value into matching outbound HTTPS requests outside the sandbox," so a sandbox can use a value it never holds (E2B, 2026).
  • NVIDIA's OpenShell guidance states that "The agent receives an opaque placeholder, not the real API key or access token" and that "Each allowed endpoint is a potential data exfiltration path," so an allowlist narrows egress without making it safe (NVIDIA, 2026).
  • Cursor's agent security page states that "By default, terminal commands need your approval" and that "All MCP connections need your approval," while its run modes are described as "best-effort guardrails rather than a hard security boundary," so approval governs an action and not the environment a credential can address (Cursor, 2026).
  • A governed environment replaces the values a policy chooses with consistent tokens before any model reads the screen, so a deployment console renders the production entry as a token, not the credential itself (What Is Least Exposure?).
  • Real values resolve only at the approved destination at the moment of an approved action, so the production credential stays in its adapter while the run completes in staging (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

What does staging access mean for a coding agent?

A coding agent works on two kinds of surface. Some of its work happens on pages it renders in a browser: a deployment dashboard, an environment settings page, the CI page where a check result appears, a repository's deploy key screen. The rest happens outside a browser: commands in a terminal, edits in an IDE, reads of the local filesystem, direct API calls, and MCP servers.

The control discussed at the end of this page has the first surface as its scope. Its reach is what an agent reads and does on a rendered page, and the terminal, the IDE, the local filesystem, direct API calls and MCP fall outside it. The environment a page displays is something a model can read and act on. The credential a command uses sits outside the rendered page and has to be handled by the sandbox and the adapter design the vendors document.

Staging access is two permissions wearing one name: to see and operate a staging deployment's page, and to present a staging credential to a staging endpoint. A team can grant the first and believe it granted the second.

The record type for this page is two adapters and two environments. A staging adapter holds the staging credential, a production adapter holds the production credential, and the run is wired to the staging adapter. The grant names staging as its resource, and the production adapter stays reachable by a person and is not addressable by the run. The arrangement has to show that no production value sits inside anything the agent can read or call. Authority and capability differ: a tether says where an agent may go, not what it can see once it arrives (What Is a Tethered Agent?).

Why is separating credentials cheaper than separating networks?

Separating two environments at the network layer means building two paths and keeping them apart: separate accounts or virtual networks, separate egress rules, a proxy each environment's traffic passes through. The work repeats for every endpoint, and each allowed endpoint is a place data can leave. NVIDIA's guidance is explicit that "Every outbound connection from the sandbox goes through the CONNECT proxy" and that OpenShell "enforces sandbox security across four layers: network, filesystem, process, and provider credentials," with the warning that "Each allowed endpoint is a potential data exfiltration path" (NVIDIA, 2026).

Credential separation costs less because the unit is a credential rather than a network. The staging adapter gets the staging credential, the production adapter gets the production credential, and only the staging adapter is wired to the run, so a new endpoint widens staging's reach without touching production. The limit is that the binding is made when the adapter is configured: E2B's page contrasts its stored credential with an environment variable, where "any code running in the sandbox can read it" (E2B, 2026), which is the reach a production key gains if it is pasted into a staging job.

This is not a claim that network rules are unnecessary; egress filtering limits where a compromised staging job can send what it collects. A second credential in a second adapter is a smaller build than a second network, and a network rule is written against an address that changes as environments are rebuilt, while a credential is written against an environment name a person can approve.

How do you name an environment in a grant?

A grant answers four questions: who the agent is, which resource the permission covers, what operation it allows, and who approves it. The staging question fails at the second field when the resource is a repository or an application and the environment is implied: a credential that can deploy to either satisfies the grant.

The environment belongs in the resource field as a value the credential is bound to. Microsoft's page states that "Managed identities eliminate the need for developers to manage these credentials," which removes a stored credential and still leaves the environment boundary to the resource the identity was created for (Microsoft, 2026). The pattern transfers to a staging credential issued for staging.

The Model Context Protocol's security guidance states the audience rule in one line: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server" (Model Context Protocol, 2026). A production endpoint should not accept a token issued for staging.

Two fields complete the record: the adapter that holds the credential, and the named person who approves with the environment named. The remaining boundary is the identity that acts: AWS's guidance that it "strongly recommends not creating access keys for the root user" rules out the simplest way an agent gets power over every environment at once (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?), and the rule Google gives Workspace administrators for a super admin account, that it should be used only when needed, applies with more force to an agent (see Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?).

What do the vendors themselves say?

Cursor's agent security page states that "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues," the vendor's own account of why an approval prompt checks a proposal rather than guaranteeing the next one (Cursor, 2026). The page does not mention a sandbox or say how credentials are stored, and its run modes are described as "best-effort guardrails rather than a hard security boundary." An approval prompt governs the action in front of the model; the credential behind that action can still be one that reaches production.

OpenAI's Codex documentation states that "Locally, Codex uses an OS-enforced sandbox that limits what it can touch (typically to the current workspace)" and that "By default, the agent runs with network access turned off," while it does not describe how credentials are stored or handled in a local session (OpenAI, 2026). The sandbox limits what the session may touch, and it leaves the question of which credential the session holds to something outside the page.

Dimension E2B, per its documentation NVIDIA OpenShell, per its documentation What a buyer should verify
Where the value sits A stored credential referenced by name Provider credentials held outside the sandbox; the agent sees a placeholder Whether the real value is ever inside the sandbox
What the sandbox holds "only a reference to the secret" "an opaque placeholder" What a run can export
Who substitutes The egress proxy, outside the sandbox The CONNECT proxy Which component holds the real value
What limits egress Matching outbound HTTPS requests Every outbound connection through the proxy Whether the allowlist is set per environment
What the page leaves open How to bind the reference to one environment How to bind a placeholder to one environment Which environment the credential may address

Two patterns recur across the pages. The credential is held outside the component that runs the agent, and the boundary is enforced by a proxy, a sandbox or an identity system rather than by the model's judgment. What the pages reviewed do not describe is a way to decide, at the grant, that a credential works in staging and not production. That decision is left to how the adapter is configured and to what the endpoint will accept, which is the field the next section takes up.

What still goes wrong when one credential reaches both environments?

The failures are mundane: a configuration copied between environments, a token whose scopes cover both, and a deploy tool whose default target is production.

The code completion study found that "two valid credentials were identified during our experiments" and that the tools "can not only return the precise piece of their training data," which is why a production key in model-facing text can be repeated (Huang et al., Your, 2024).

The third failure is the one approvals are meant to catch, and the record on defenses is thin. A benchmark study evaluated "5 prompt injection attacks and 10 defenses with 10 LLMs and 7 tasks," a measurement that does not show the defenses hold against a different attacker (Liu et al., 2024). A benchmark of agent attacks reports "critical vulnerabilities in different stages of agent operation" and "limited effectiveness shown in current defenses," so the model's own judgment is not the boundary (Zhang et al., 2025).

Two more paths belong in the review. The Model Context Protocol guidance warns that "Poor scope design increases token compromise impact" and that "Cloud metadata endpoints often expose IAM credentials, API keys, and other secrets," when one token is accepted by two environments (Model Context Protocol, 2026), and one login that bundles workflow access with value access grants more reach than the task requires (How Do You Give AI Agents Access to Workflows Without Exposing Sensitive Data?).

What does a governed environment change?

A governed environment acts before the model does. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so a key or an environment keeps one token for the whole run. 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. 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 the control changes what the production page means to the model. The environment a page displays becomes a token such as ENV_STAGING_001, and the production entry renders as a token the run cannot redeem. A model that reads every card on a two-environment console still reads no production credential. The production value resolves only if a grant names production, a production adapter is addressable, and a named person approves the specific action.

Each action in the record carries the environment it targeted, the token the model worked from, and the name of the approver, so a reviewer can tell a staging deploy from a production one. A grant that names an environment and a record that shows it are one decision seen twice.

The rendered page is the surface this control acts on. The shell, the IDE and the API path are governed by the credential design and the sandbox, and the two together are what the title asks for: staging reachable, production out of reach, and a written account of which was which.

Methodology and limitations

This page rests on three research preprints about prompt injection, agent attack benchmarks and credential memorization in code completion tools, vendor documentation from Cursor, OpenAI, E2B, NVIDIA and Microsoft, the Model Context Protocol specification, and existing RedactSure research pages on exposure and agent authority. Vendor and standards 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 the benchmark figures are cited as published, not as independently measured. Where a vendor page does not describe how a credential is stored or which environment it may address, this page says so rather than inferring a capability.

RedactSure did not test any of the named products hands-on. Not described in the pages reviewed means those pages and nothing broader, so a release after this date may document a control they do not, and the absence of a description is not evidence that a product cannot do something. 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. The example describes a record type, two adapters and two environments, not an organization, and ENV_STAGING_001 and ENV_PRODUCTION_001 illustrate a tokenization policy rather than a limit of the design.

Determinations about whether an environment boundary 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 against its own staging and production endpoints after each release.

What the record shows

For a team that must keep an agent out of production, the pages reviewed answer in three parts. The credential can be kept outside the sandbox, as E2B and NVIDIA document, and both designs leave the environment to configuration rather than to the grant. The grant is where an environment becomes a resource a credential and an approver can be bound to, and the audience rules from Microsoft and the Model Context Protocol show the shape. What remains is the failure the research record describes: a model that reads a production value can repeat it, and defenses measured against one attacker do not settle the next. RedactSure's environment carries the environment in the token and keeps the production value in an adapter outside the run. Before approving a design, a team should run one test: name one agent and one task, ask which credential it can present, and ask whether the production adapter would answer if it did.

Frequently asked questions

How do I give a coding agent access to staging but not production?

Name staging as the resource in the grant, hold the staging credential in an adapter the run can reach, and keep the production credential in a second adapter the run cannot address. Then check what the agent reads: a production value that appears on a page, in a variable or in a copied configuration is inside the run whatever the grant says. The boundary is the credential, not the label on the task.

Is a separate network enough to keep an agent out of production?

A separate network limits where traffic can go, and it does not decide which credential the agent can present. If the staging job holds a production key, the rule that permits the staging endpoint does not help. Network separation is also the more expensive of the two, because every environment needs its own path and every allowed endpoint is a place data can leave. Use it for egress, and use credentials for environment scope.

Where should the staging credential live?

In an adapter outside the agent's sandbox, so the agent asks for an action and the adapter presents the value. The sandbox should hold a reference or a placeholder, not the credential itself. That is the pattern E2B documents with a stored credential referenced by name and an egress proxy that injects the real value, and the pattern NVIDIA documents with an opaque placeholder. The limit is that the reference is bound per sandbox, so the binding is where the environment decision is made.

What should the grant name besides the environment?

The agent or identity that acts, the operation the run may perform, the adapter that holds the credential, and the person who approves. The environment has to be a value the credential is bound to, not a note beside a repository name. An approval should name the environment too, because approving a staging deploy is not approving a production one. A grant with a resource and an approver is a decision a reviewer can check before the run starts.

Can an approval stop an agent from using a production credential?

An approval checks the action the agent proposes, so it can stop a production deploy if the approver sees the environment and says no. It cannot stop a model from reading a production value and repeating it later, and it does not decide which credential the run can present. Approvals are one layer, and they record a decision rather than remove a value from the room. The credential has to be out of reach before the approval is the only thing standing between the run and production.

How do I check that production is out of reach?

Pick one run and list every place a credential could enter it: the adapter, a variable, a configuration copied from another environment, a page the agent renders, and a metadata endpoint the sandbox can reach. Then ask which of those holds a production value. If the answer is none, the grant and the adapter agree. If the answer is one, the environment label on the task is doing work the design is not, and the label comes off before the next run.

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 Production Credential Out of the Agent's Sandbox

Both credentials sit in one reachable place, so a setting can select the wrong environment and an approval can confirm an action without naming it.

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

Before, the agent opens a two-environment deployment settings page, the production card renders its live key, and the model receives a value staging never needed. Inside, the page renders ENV_PRODUCTION_001 and ENV_STAGING_001, the production adapter sits outside the run, and production waits for a named person outside the run under Supervised Delegation.

RedactSure is deploying now with enterprise and government customers. The vendor pages reviewed keep the credential outside the sandbox and leave the choice of environment to configuration.

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

See it on your own workflow

Work in staging should never show the agent a production key. Bring a deployment settings task and see, with test values, what the model reads on a page that lists both environments. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.