Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Give a Coding Agent Access for One Run Only?

Yes, when the lifetime sits in the grant: a named run, one repository and one operation, and an adapter outside the agent that stops honoring it when the run closes. A token's expiry is a clock rather than a run boundary, so ask where the grant ends and whether the agent ever holds the value.

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

A coding agent asks for access, a person approves a scope, and the usual answer is a token with an expiry date. That answer treats a property of the credential as a property of the permission, and the two behave differently. A token can outlive the task by weeks. A task can outlive the token by minutes, which is why teams lengthen the window until it covers the longest job anyone can imagine, and then the credential is durable again. The distinction sounds academic until a run pauses for an approval and the token expires in the queue, or until a run finishes in four minutes and the token stays live for another month. The question in the title is about the permission. A grant that ends with the run names the run, fixes the scope to one repository and one operation, and leaves the credential with a component outside the agent that stops honoring the grant when the run record closes. This page separates the clock from the event, reads the vendor documentation that comes closest to an event boundary, sets out what a loose credential reaches, and ends with a check a team can run before the first handover. One record type runs through it, a grant that ends with the run, and What Is Least Exposure? supplies the vocabulary for what the agent may see while it works.

Key findings

  • Progent, a privilege control layer for AI agents, reports that it "significantly reduces attack success rates while maintaining high utility," and its abstract gives no numbers (Shi et al., 2026).
  • A study of agentic coding editors reports that "attack success rates can reach as high as 84% for executing malicious commands," with no trial counts or tool versions in its abstract (Liu et al., Your, 2026).
  • OpenAI's cloud environment page states that credentials "are only available to setup scripts" and are "removed before the agent phase starts," a phase boundary the environment enforces rather than a property of the credential (OpenAI, 2026).
  • GitHub records that "Infinite lifetimes are allowed but may be blocked by a maximum lifetime policy set by your organization or enterprise owner," which makes the lifetime a policy setting and not an end-of-task event (GitHub, Managing, 2026).
  • A governed environment replaces values with consistent tokens before any model reads the screen, so a repository page renders DEPLOYKEY_001 and the model never holds the string the page would display (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination, at the moment of an approved action, so a grant's lifetime can end with the run because the agent was never the component holding the value (What Is Least Exposure?).

What does one run of a coding agent actually include?

A run is a task with a start, a scope and an end, and a coding agent's task is usually stated in a line: open a pull request on this repository, fix this failing test, update this dependency. Some of what the run touches are pages the agent renders in a browser: the pull request page it opens, an issue page it reads, a settings page for deploy keys, the CI page where the check result appears. Others sit outside a browser entirely: the clone in the agent's shell, the test runner, the editor, a direct API call, an MCP server.

The scope of the control discussed at the end of this page follows that line. A governed browser environment covers what an agent reads and does on a rendered page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A grant that limits a shell command and a grant that limits a settings page are different instruments, and a team told the agent has access for one run should ask which surface it covers.

The record type for this page is a grant that ends with the run. The agent is asked to make one change on one repository, the grant is created for that task, and every permission the run uses hangs off it rather than off a long-lived token in an environment variable. What the grant does not settle is what the model reads on the pages the run touches.

The tether is a useful image for authority. A tethered agent goes where its supervisor could go and does real work there, and the tether describes authority rather than capability (What Is a Tethered Agent?). A grant for one run is a short tether: it says what the agent may reach, and when that reach ends.

Why is a token's expiry not the same as a grant's lifetime?

An expiry is a clock. It is set when the credential is issued, it counts down whether or not anything is happening, and it cannot tell whether the task finished, failed or is waiting for an approval. Set the window short and a run that pauses or retries dies halfway through, so the next iteration lengthens the window until every plausible job fits inside it. Set the window long and the credential is live for weeks after a four-minute task, which is the case the title is about.

The vendor pages tune the clock rather than replacing it, and a policy ceiling is still a clock. OWASP's CI/CD guidance says to "Prefer using temporary credentials over static credentials," which still leaves the length of temporary to whoever issues the value (OWASP, 2026).

Narrowing a token is a separate dial. Scope answers where a value may be used and for what; it does not answer when the permission ends. Work on restricting an agent to one workflow draws the same line at the identity layer: the workflow can be singular while the credential stays valid for months (How Do You Restrict an AI Agent to One Workflow With Microsoft Entra, ServiceNow AI Passport or SailPoint?).

A grant is different in kind. It names the run, carries the scope for that run, and is closed by an event that someone records. An expiry can sit on the grant as a backstop, but the primary terminator is the end of the run. That is why a per-run grant over a longer-lived credential can be safer than a short-lived token in the agent's hand, and why the lifetime belongs in the grant.

What do the vendors themselves say?

OpenAI's cloud environment page, which the vendor marks as legacy, says "Environment variables are set for the full duration of the chat (including setup scripts and the agent phase)," so a value placed in a variable rather than a secret is in the agent's reach for the whole task (OpenAI, 2026). The boundary it describes is a phase inside the environment: the agent phase starts and ends, and a credential can be removed at that line. What the page does not describe is a grant closed by a named person when the task ends.

GitHub's documentation states that "secrets are not passed to the runner when a workflow is triggered from a forked repository," a boundary the platform enforces when the run is created rather than when the token expires (GitHub, Using, 2026). It is the closest thing in the pages reviewed to a rule keyed to an event, and the event is the creation of a run, not its end.

Firecracker's design document states that it "is designed to assure secure isolation using multiple layers" and that "All egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level," which encloses a run and leaves the lifetime of what enters it to something else (Firecracker, 2026). Isolation of a per-task machine is not a lifetime on the credential inside it.

Dimension OpenAI Codex Cloud (Legacy), per its documentation GitHub Actions, per its documentation What a buyer should verify
Where the value sits at the start Available to setup scripts only Repository secrets, absent from fork-triggered runs Which step of the run receives it
What the agent phase gets Credentials removed before it starts; variables live for the full chat Credentials present in the job Whether a variable carries the value through the phase
Boundary type A phase transition inside the environment A trigger condition at run creation Whether the boundary is an event or a setting
After the run ends The page does not say The page does not say What closes the grant, and who records it

Read together, the three pages put the boundary in the environment: a phase, a trigger, a host filter. None of them states what the model reads on a page the run touches, and none describes a grant that ends because a person ended it.

Where should the lifetime be enforced, and by what?

Enforcement has to sit outside the model, for the same reason a policy does: the component being governed cannot decide when its authority ends. Two things are needed: a credential holder that consults the grant before it acts, and an authority that closes the grant when the run ends, a person or a system of record that marks the task complete, abandoned or failed.

The design consequence is the sentence that answers the title: a per-run grant over a longer-lived token is fine as long as the agent never holds the token. If the adapter is the only holder and it refuses once the run is closed, the token's remaining weeks do not matter to the agent, because the agent has no way to present them. If the agent holds the value, the token's own clock governs again, whatever the grant says.

The privilege control result cited above reports a reduction in attack success without giving numbers. The benchmark literature makes the gap explicit: one study reports "5 prompt injection attacks and 10 defenses with 10 LLMs and 7 tasks," a measurement of detection and not of how long anything lasts (Liu et al., Formalizing, 2024).

The custody pattern the adapter needs is documented for API keys, where an agent can ask for a key to be used without reading it (How Do You Let an AI Agent Manage API Keys Without Reading Them?). A grant is that idea applied to time: the agent asks for the operation, the adapter supplies the credential, and the permission exists only while the run does. What makes the lifetime checkable is the record, which lists the run identifier, the scope, the time the grant closed, and the name of the person who closed it.

What goes wrong when the grant outlives the run?

The first failure is that the credential is still usable after the reason for it has gone. Wiz "looked at 50 leading AI companies and found that 65% had leaked verified secrets on GitHub," which is the population a one-run credential enters and leaves behind (Wiz, 2025). A value that would have been dead at the end of a task is one more live string in that population.

The second is that durable identities are already ordinary in automated paths, so a leftover credential does not look out of place. Datadog reports that "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions," a durable identity in a path that runs unattended (Datadog, 2025). A one-run grant is unusual in that company, so write it into the record.

The third is that the grant tends to be wider than the task. A single login that bundles workflow access with value access grants more than the run needs, the excessive agency problem stated as an identity problem (How Do You Give AI Agents Access to Workflows Without Exposing Sensitive Data?). A per-run grant narrows that twice, once by naming one task and once by ending with it.

For a coding agent the leftover is legible in the places a run produces: a commit, a pull request body, a CI log, a transcript, a settings change the agent made on the way through. The 84% figure cited above concerns commands executed from injected content, not a leaked token. Model behavior under hostile content cannot be the control, so the credential has to stop working when the run does.

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 such as DEPLOYKEY_001. 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, which is the operating model described in What Is Supervised Delegation?. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring, the artifact described in What Is an AI Control Record?.

For this question it changes the last step of the grant. An expiry ends a value; it does not end a permission. Under the governed environment the permission ends when the run record closes, and the close is an event with a name attached, so the agent's reach stops at a moment a reviewer can find. The agent also stops being the place where the value lives: if it never held the credential, ending the run ends its usefulness to the agent, and a later attempt has nothing to present.

The scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so the shell side of a coding run needs the environment and the credential design the vendor pages above describe. The two are complementary, and this page's question needs both.

Methodology and limitations

This page rests on three research preprints on privilege control and prompt injection in coding editors, vendor documentation from OpenAI, GitHub and Firecracker, OWASP's CI/CD security guidance, two vendor research posts, 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 the survey figures from Wiz and Datadog are cited as published, not as independently measured. The preprints are cited for the findings their abstract pages state and not for rates those pages do not give.

RedactSure did not test any of the named products hands-on. Not described in the pages reviewed means the pages reviewed and nothing broader, so a release after this date may document a control those pages 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, a grant that ends with the run, and not an organization; DEPLOYKEY_001 illustrates a tokenization policy and not a limit of the design. The table is a comparison drawn from the pages cited and not a description of any one product.

Determinations about whether a grant design 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 repository, repeated after each release of the agent, the adapter and the identity provider.

What the record shows

The pages reviewed answer the title in three pieces. A token's expiry is a clock, tuned by policy and unable to see a task end. The environments reviewed draw their boundary at a phase, a trigger or a host, and none of them closes a permission because a run closed. What closes it is a grant that names the run, a component outside the agent that refuses after the close, and a record of the close itself. The failure record explains the cost: verified credentials leaked at most of the AI companies Wiz examined, and durable IAM users remain common in GitHub Actions. RedactSure's environment is built on the grant model. To test a setup, pick one agent and one run, then ask what closes the grant and whether the agent ever held the value it used. An answer that is a date means the lifetime is a setting; an answer that is an event with a name means it is a boundary.

Frequently asked questions

How do I give a coding agent access for one run only?

Put the lifetime in the grant rather than in the token. Name the run, fix the scope to one repository and one operation, and keep the credential with a component outside the agent that refuses to act once the run record closes. A short expiry is a clock and cannot see the task end, so it either cuts a long job short or leaves a credential alive after a short one. The test is to ask what closes the grant, and whether the answer is a date or an event.

Is a short token expiry the same as a one-run grant?

No. Expiry bounds how long a value can be presented; the grant bounds what may be done, and for which task. A ten-minute token still works for ten minutes after the run ends, and a run that waits for an approval can outlast any window a team dares to set. A team needs both: a short value is hygiene, and an event that closes the grant is what makes the lifetime match the task. A date cannot make that distinction.

Can a per-run grant sit over a longer-lived token?

Yes, provided the agent never holds the token. If a component outside the agent presents it only while the grant is open, a ninety-day credential is no more spendable at minute ninety-one of a closed run than a ten-minute one. The condition is strict: once the model can read the string, the token's own clock governs again, and each transcript, log and commit becomes a place the value can escape from. The placeholder is worthless outside the environment that issued it.

What stops the agent from using the credential after the run ends?

The component that holds it. If the adapter checks the grant's state before each call and the run's close is recorded, a late call is refused whether the token is still valid at the resource server or not. If the agent holds the credential itself, nothing stops it that the issuer did not schedule, and an unexpired token is a working token. Enforcement therefore sits outside the model, and a refusal is the control working rather than an error to route around.

Does an ephemeral environment solve this on its own?

Partly. A fresh environment per task removes local state, and a cloud environment can drop a credential at a phase boundary before the agent phase begins. Neither decides what the model reads on a rendered page, and a value left in an environment variable for the full duration of a chat is available throughout. Ask what the environment removes, at which point, and whether the agent could have read the value first. A fresh machine is a container, not a permission.

What should a team ask for in writing before the first run?

The grant's name, its scope, the event that closes it, the component that enforces the close, and the record of both. Whether the agent ever holds the credential, and what the model reads on each page the run touches. Who approves the consequential action, and what the approval is attached to. A vendor that answers those five questions has a design; one that answers only with an expiry time has a timer. Ask for the answers beside the record of the first 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 Ends a Grant When the Run Ends

An expiry is chosen before the task starts and cannot know when it ends, and the pages reviewed bound access by phase, trigger or host filter.

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

Before: the agent opens the deploy key settings page, the key material renders into its context, and the credential outlives the merged pull request. Inside: the settings page and the confirmation page render DEPLOYKEY_001, and the real value resolves at the repository while the run is open.

RedactSure is deploying now with enterprise and government customers. Wiz found verified credentials leaked at 65% of the AI companies it examined.

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

See it on your own workflow

A credential that outlives the merged pull request is the exposure one-run access is meant to prevent. Bring a deploy key task and see, with test values, what the model reads on the settings and confirmation pages. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.