Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Let a Coding Agent Deploy Without Giving It Deployment Credentials?

Separate the build from the deploy: the agent produces the artifact and opens the change, and a deploy step that holds the credential runs outside the agent's reach, with a person approving production. Codex removes credentials before its agent phase, but the pages reviewed do not describe what the model reads; check where your credential lives.

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

Many teams already separate the people who write code from the pipeline that deploys it. An agent can sit on the writing side of that line and still trigger a deploy through a pipeline it has no keys for. The design question is where the approval goes and which environments let the agent proceed without one. Deployment is the point at which an agent's work stops being a proposal and starts being a change to a running system, so it is where a credential matters most and where an approval is easiest to place. This page uses one record type as its example, a staging deploy that is automated while production is gated by a person. The record supports keeping the deploy credential in the pipeline, letting staging run on its own, and making a named person accountable for every production release. What Is Supervised Delegation? supplies the framing for the named person. The vendor pages cited here were read on October 20, 2026, and each section says which statements come from them.

Key findings

  • Separating build from deploy means the agent produces an artifact and opens a change while a deploy step outside its reach holds the credential. Codex's cloud documentation describes removing credentials before the agent phase, which is the same split enforced by the environment (OpenAI, Cloud, 2026).
  • OpenAI's guidance on governing agentic systems says human approval "is a standard way to limit egregious failures" and that actions reviewable only after the fact "should be more easily reversible," which is why production, the least reversible stage, is the gate (Shavit et al., 2023).
  • Glean's documentation says its agent access policies govern "what data agents can read and what actions they can execute at runtime," a runtime policy description that does not say what values the model sees on a screen (Glean, 2026).
  • Adaptive attackers bypassed 12 published prompt injection defenses with success rates above 90% for most, so a deploy credential should be out of the agent's reach on the assumption that it can be misdirected (Nasr et al., 2025).
  • A governed environment that replaces values with consistent tokens before any model reads the screen means a deployment console shows placeholders where keys, hostnames and customer identifiers would be (What Is Supervised Delegation?).
  • Real values resolve only at the approved destination, and a named person approves the production step, so the record shows who answered for the change (What Is an AI Control Record?).

What does it mean to separate the build from the deploy?

A deployment has two halves with different needs. The build turns the agent's changes into an artifact: compiled code, a container image, a migration file. It needs the repository and a build environment, and no production credential. The deploy takes that artifact to a running system and needs the credential that authorizes it. In many setups both run in the agent's session, so the agent holds both.

The separation gives the agent the first half and withholds the second. The agent produces the artifact and opens the change, such as a pull request or a release request. A deploy step that holds the credential runs outside the agent's reach, triggered by an approved change and not by the agent's request alone. For the example record, a staging deploy is automated after the change is merged, and production waits for a person.

Scope note: the controls discussed concern what an agent holds and what a deploy step does. A governed browser environment, discussed at the end, covers what an agent reads and does on a rendered page such as a deployment console. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so a deploy triggered from a shell is a case for the separation described here. How to Set Up S3 and GitHub With Cowork or Dots covers the pipeline side, where OIDC settles how the pipeline authenticates. How Do I Let a Coding Agent Open Pull Requests Without Giving It My Credentials? covers the change request, and How Do I Let a Coding Agent Use AWS Without Giving It My Access Keys? covers the cloud credential.

What do the vendors themselves say?

OpenAI's Codex cloud documentation, as read for this page, describes removing credentials before the agent phase of a task (OpenAI, Cloud, 2026). That is a split enforced by the environment: the agent phase runs without the credentials that a setup phase may have used. What the model reads on a rendered page, and who approves a production change, are not described in the pages reviewed.

Glean's documentation says agent access policies govern "what data agents can read and what actions they can execute at runtime" (Glean, 2026). It describes a policy over data access and actions inside the vendor's platform; it does not describe replacing values before a model reads them.

Coder's documentation says "LLMs and agents can be dangerous if not run with proper boundaries," and advises against giving agents full permissions on behalf of a user in favor of separate identities with limited scope (Coder, 2026). It governs the identity an agent runs as and does not describe a deploy gate.

Source What it documents What the pages reviewed do not describe
OpenAI Codex cloud Credentials removed before the agent phase What the model reads on a page; a production approver
Glean Policies over data and actions at runtime Replacing values before a model reads them
Coder Separate, limited identities A deploy gate

How do staging and production differ as gates?

Staging and production differ in reversibility and in who is affected. A bad staging deploy costs time. A bad production deploy can cost customers. OpenAI's guidance says "actions that can only be reviewed after the fact should be more easily reversible," that users should be able to "activate a graceful shutdown procedure for its agent at any time," and that "at least one human entity is accountable for every uncompensated direct harm" (Shavit et al., 2023). Production is the stage where those three points matter most.

Stage Who holds the credential Who approves Reversibility
Build Nobody; no deploy credential is needed Not applicable Fully reversible
Staging The deploy step, outside the agent Policy, after the change merges Usually reversible by redeploying
Production The deploy step, outside the agent A named person, per release Least reversible; rollback plan required

The table is a design, not a description of any product. It places the person at the one stage where after-the-fact review is the weakest. Approval at staging adds friction without much protection, and approval at production adds protection at a point where a human can read what is about to change. What Is Supervised Delegation? describes why the absence of a named person is the first audit finding after an incident.

What can still go wrong when the deploy step is outside the agent?

The artifact is the agent's output, so the deploy step is executing agent-authored content. A deploy credential that never reaches the agent does not stop a misdirected agent from producing a harmful artifact. The gate at production exists for that reason: a person reads the change before it ships.

Injection remains. The mechanism is documented in the information-flow literature: "poisoned data retrieved from one component can change the model's behavior and compromise the entire system, including coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025). An agent that reads a poisoned page or file while preparing a deploy can propose a change that serves the attacker. Keeping the credential out of its reach limits the attack to what the approved artifact can do.

The deploy step becomes the custodian. Its host, its logs and who can trigger it are now the review surface, and a deploy step that runs anything the agent hands it gives the agent the credential's authority indirectly. The deploy definition, not the agent's request, should decide what runs. Does Codex Have Access to My Repository Secrets? takes the case where an agent needs a live credential, and How Do You Let an AI Agent Manage API Keys Without Reading Them? covers key handling.

What does the incident record add?

Columbia's DAPLab lists incidents in which agents acted on production systems beyond their task: a Cursor agent that deleted a production database through a single rogue API call, a Replit agent that did so despite instructions not to, and a 13-hour AWS outage caused by an agent rebuilding a production environment (Columbia DAPLab, 2026). The list is a position paper's summary and not a measured rate. It illustrates what broad production authority allows.

A SailPoint survey of 353 IT professionals, as summarized in existing research, found that 80% of organizations said agents took unintended actions, about 40% said agents "accessed unintended systems," 31% said agents shared inappropriate data and 23% said agents revealed credentials (How Do You Test Whether an AI Agent Can Reach Data Outside Its Assigned Task?, 2025). The survey is self-reported and does not isolate deployments.

Privilege and Identity Misuse and Governance and Visibility are two of the seven risk categories Harvard's security office lists for AI-enabled systems (Harvard University Information Security and Data Privacy, 2026). A deploy credential in the agent's reach sits in both. The record supports the separation and the gate, and it does not measure how often either is in place.

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 on placeholders. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, such as a production release. 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 it covers the console. If the agent works in a browser on a deployment or cloud console, a key, a hostname or a customer identifier shown on a page is replaced with a placeholder before the model reads it, and the production approver sees the action before it is submitted. The separation of build and deploy bounds who holds the credential. The governed environment bounds what the model reads on the pages it works, and the approval bounds what ships. OWASP names the failure class as excessive agency, the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, with excessive functionality, permissions and autonomy as its listed root causes (OWASP, 2025).

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a deploy run from a shell is a case for the separated deploy step and the production gate.

Methodology and limitations

This page rests on OpenAI's Codex cloud documentation and whitepaper, Glean's and Coder's documentation, three research papers, OWASP guidance, a Columbia lab post, Harvard University guidance and existing RedactSure research pages. Sources were read between October 16, 2026 and October 20, 2026. Quoted facts are cited to the page that states them, and the survey and position-paper figures are cited as reported, not as independently measured. Where a source supports only a premise, such as the incident list, the page says so and does not present it as proof of the design. The stage table is a design, not a description of any product.

The description of Codex removing credentials before the agent phase is taken from the documentation as read for this page and is not reproduced beyond that summary. The production approval gate is this page's design and is not attributed to any vendor's documentation. RedactSure did not test Codex, Glean or any deploy pipeline hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader. 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. Examples describe record types, such as a staging deploy with a gated production step, and not organizations.

Determinations about whether a deployment control meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. The page is a reading of public documents, dated as above, and it should be read with each vendor's current documentation open. Nothing here replaces a review of the organization's own pipeline permissions, release approvals and credential inventory.

What the record shows

The vendor documentation reviewed supports the split in part. Codex removes credentials before the agent phase, which keeps the credential out of the agent's session, and agent access policies exist at the platform level. None of the pages describes what the model reads on a console page or who approves a production release. The research record supports keeping the credential out of reach and approving the least reversible step, and the incident record shows what broad production authority allows. Build can be the agent's, staging can be automatic, and production belongs to a named person with a rollback plan. Before the agent ships anything, a team should test the split on one agent and one service: find which step holds the deploy credential and whether the agent can reach it, and confirm who approves the production release and where that approval is recorded.

Frequently asked questions

How do I let a coding agent deploy without giving it deployment credentials?

Separate the build from the deploy. The agent produces the artifact and opens the change, such as a pull request. A deploy step outside the agent's reach holds the credential and runs when the change is approved. Staging can be automatic after merge, while production waits for a named person. The agent never holds the deployment credential, so a misdirected agent has no key to send, and the approval is recorded with the name of the person who gave it, so a later review can see who decided.

What does Codex do about credentials during a task?

According to the documentation read for this page, Codex removes credentials before the agent phase of a task, so the agent runs without them. That keeps the credential out of the agent's session. It does not describe a production approver or what the model reads on a rendered page, so a buyer should ask for both in writing, naming the task, the environment and the person who would be accountable.

Why gate production and not staging?

Production is the least reversible stage, and OpenAI's guidance says actions that can only be reviewed after the fact should be more easily reversible. A bad staging deploy costs time and can be redone. A bad production deploy affects customers. A person reading the change before it ships adds protection where it matters most, with a rollback plan ready, and approval at staging adds friction with little protection. The gate belongs where a person can still change the outcome.

Does keeping the credential away from the agent make deploys safe?

No. The artifact is the agent's output, so a misdirected agent can still produce a harmful change, and the deploy step executes it. The credential separation limits what a successful injection can collect and do directly, which is the narrower claim. The production gate, normal code review and a rollback plan address the artifact itself. All three are needed, and none replaces the others. A reviewer should ask to see each one working before production access is granted, and to see who can roll back.

Does this cover an agent working a cloud console in a browser?

Not by itself. The separation governs who holds the deploy credential. If the agent also works a deployment or cloud console in a browser, the model reads whatever the page shows, so the page needs its own control that replaces values with placeholders before the model reads them. A governed browser environment does that, and it does not cover a terminal, an IDE or MCP, so the two controls are used together and tested separately.

What should a security team ask for in writing?

Ask which step holds the deploy credential, whether the agent can reach it, what triggers the deploy, who approves production and how that approval is recorded. For any console page, ask what the model reads there and where the record is exported. Treat anything the vendor does not document as unanswered, and ask for a dated written answer that names the service, the credential and the approver.

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 Deploy Credentials Off the Agent's Console Screen

Separating build from deploy keeps the credential out of the session, and the custody controls reviewed never decide what the model reads on the deployment console.

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

Before: the agent opens the console to check the staging release and reads the production hostname and a deploy key, which a poisoned file read earlier can direct elsewhere. Inside the governed environment: the model reads HOST_001 and KEY_001, and the production step runs only when the named approver confirms it; the record shows who answered.

RedactSure is deploying now with enterprise and government customers. In a SailPoint survey, 23% of organizations said agents revealed credentials.

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

See it on your own workflow

A deploy is the action that most needs a person behind it. Bring a release your team delegates and see, with test values, what the model reads and who confirms the production step. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.