Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can a Grant Expire on Its Own When the Agent Task Ends?

Yes, when the grant carries a lifetime field and the component that enforces it stops honoring the grant at the task's end; no one has to remember a cleanup step. Ask where the lifetime is set, which event ends the task, and what record shows the grant lapsed.

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

A team that grants a coding agent access for a task also answers for that permission after the task ends, and a permission that outlives its task leaves access in place with no work to justify it. The familiar answer is a token with a timer, which counts down without knowing whether the work finished, failed or is waiting for an approval. The grant is the better place to put the ending because it names the task that the ending belongs to: when the lifetime is a field on the grant, the component that honors the grant can stop honoring it once the task closes, and no one has to run a cleanup step after a long day. The title asks whether that can happen by itself. The answer turns on three things, where the lifetime is written, which event marks the end, and what evidence shows the grant actually lapsed. The vendor designs reviewed bound a session, a proxy or an MCP credential, none closes a browser grant because the task closed, and so a team should test the lapse on its own agent before it trusts one. One record type runs through the page, a grant that lapses at task end, and What Is Least Exposure? supplies the vocabulary for what the agent may see while the grant is open.

Key findings

  • 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).
  • Infisical documents "Time-bound grants that let AI agents access services without holding real credentials," a time bound rather than a cleanup task (Infisical, 2026).
  • Cognition's Devin guide states that session secrets are "scoped purely to the current session and are not saved for any future sessions" (Cognition, 2026).
  • Teleport's framework page asks for "a verifiable, cryptographic identity tied to where they're running, not a shared API key" and offers "Comprehensive audit trails and behavior analysis for agent actions across infrastructure," but gives no certificate lifetime (Teleport, Agentic, 2026).
  • A governed environment substitutes values at the render layer before any model reads the screen, so a settings page renders CIKEY_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 that lapses removes an authority the agent never held as text (What Is Least Exposure?).

Where does a grant's lifetime apply on a developer task?

The scope comes first, because a lifetime can only end a permission on the surface that permission covers. A governed browser environment covers what an agent reads and does on a rendered page: a dashboard, a cloud console, a settings page, an issue page or a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A credential lifetime set for a shell command and a grant lifetime set for a settings page are enforced by different components, so a team told the agent's access ends with the task should ask which surface the sentence describes. Anthropic's computer use documentation describes a model that views screenshots of a screen and issues mouse and keyboard actions, which is why the rendered page is the surface where a browser control can act (Does an AI Agent See Everything on Your Screen?).

The record type for this page is a grant that lapses at task end. A platform lead asks an agent to add one CI key on one repository's Actions settings page. The grant names the task, the page, the save action and a 45-minute lifetime, and a named person approves it. When the task record closes, the grant lapses. Nothing in the grant says what the agent read on that page, which the rest of this page keeps separate from the lifetime.

A lifetime on a rendered page is a statement about authority, not capability. The tether describes authority, not capability: it says where the agent may go and when that reach ends, and not what the agent saw at each stop (What Is a Tethered Agent?). That matters at the end, when the permission is gone and the screen may still be in the transcript.

Why is an expiry that runs itself safer than a cleanup someone remembers?

A cleanup step is another task, and it lands on the person least free to do it. FINRA's report, as reported by Debevoise & Plimpton, warns 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). A revocation that depends on memory is a control with a human failure mode built in, because no one owns the cleanup when it comes due.

A lifetime written into the grant moves the decision to approval time. The approver sets the number while the task and its risk are in front of them, and the enforcement point reads the field later, when nobody is watching. The person stays in the loop at the moment they have context rather than at the moment they are busy. The grant ends because the term was set, not because someone returned to it.

Automatic expiry is also not the same as trusting the model to stop. Willison's design patterns "constrain the actions of agents to explicitly prevent them from solving arbitrary tasks," and one pattern lets agents trigger tools without being exposed to the responses, which limits what a compromised run can do (Willison, 2025). Neither pattern manages time. A lifetime field is the term those action constraints do not carry.

The same logic governs the admin accounts agents are often given: Google's guidance for Workspace administrators says the super admin account should be used only when needed, a rule written for people that applies with more force to an agent (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?).

What do the vendors themselves say?

The vendor pages reviewed describe access that ends on a session, a proxy or a short-lived certificate. None describes a lifetime written into a browser task, and none describes what the model reads on the page where the credential is used.

Infisical's Agent Vault overview lists "Time-bound grants that let AI agents access services without holding real credentials" and "Forward proxies that intercept an AI agent's requests and attach real credentials on the way out" (Infisical, 2026). The proxy holds the value while the grant is bounded in time. It does not explain how credentials are injected or stored.

Cognition's Devin guide states that session secrets are "scoped purely to the current session and are not saved for any future sessions," and that "In the browser, Devin types the value directly," while for shell commands "it binds secrets as environment variables whenever needed" (Cognition, 2026). A session is not a task event.

Teleport's framework page asks for "a verifiable, cryptographic identity tied to where they're running, not a shared API key" and lists "Comprehensive audit trails and behavior analysis for agent actions across infrastructure," while giving no certificate lifetime (Teleport, Agentic, 2026). Its MCP guide promises "secure and short-lived access to these MCP servers," a lifetime on MCP and not on a rendered page (Teleport, Machine, 2026).

Dimension Infisical Agent Vault, per its documentation Cognition Devin, per its documentation What a buyer should verify
Unit of scope A service and the time bound on the grant The current session Whether the unit is a task or a timer
Where the value lives A forward proxy that attaches it on the way out A credential the product types or binds Which component holds it and what the model sees
End boundary The time bound The end of the session Whether an event closes it or only time
Rendered page Not described The browser path is described; model visibility is not What the page shows the model
Record Not described on the overview Not described A record of the close and of what was read

Each limit matters to the title. A session is not a task, a proxy governs the call and not the page, and a short-lived certificate still needs someone to decide the length.

What happens when the task ends and the grant does not?

The first failure is an orphan: the task record closes, but no event is wired to the grant, so the lifetime field is the only thing still counting. The agent may be finished, and a copy of the credential may be in a transcript, a log or a commit. The grant keeps working until its clock runs out.

The second failure is a grant too broad for the task. AWS states that it strongly recommends not creating access keys for the root user, which rules out the simplest way an agent might be given durable top-level power (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). A root key with a 90-day lifetime is still a root key; the lifetime shortens the exposure and does not narrow it.

The research record explains why the window matters. A study of agentic coding editors reports that "attack success rates can reach as high as 84% for executing malicious commands" (Liu et al., 2026), and Veracode reports that "GenAI models make the wrong choices nearly half the time, and it's not improving" (Veracode, 2025). Progent's privilege control "significantly reduces attack success rates while maintaining high utility," according to its preprint, which gives no numbers (Shi et al., 2026).

The third failure is the record: the grant lapsed, the task closed, and nothing wrote down what the model read while the grant was open. An expired grant answers the authority question and leaves the exposure question where it was.

How would a team test whether a grant really lapsed?

Pick one agent, one task and one grant, and write the grant's terms down before the run starts: the page, the action, the lifetime, the approver and the event that will close it. Then run the task to completion and close the record. The test is what happens on the next call.

A lapse that is only a date is easy to claim and hard to see. Ask the system that enforces the grant to attempt the same action after the close and record the refusal, with the time and the identifier of the grant. A refusal that arrives before the lifetime expires proves the event closed the grant; a call that succeeds after the close proves the lifetime field is decorative.

The record should answer four questions: which grant, which event closed it, which component refused the call, and what the model saw while the grant was open. The last one is the one vendor pages rarely cover. As reported by Help Net Security, GitGuardian counted "28,649,024 new secrets exposed in public GitHub commits across 2025," and commits co-authored by an AI coding agent leaked at roughly double the baseline rate (How Do You Let an AI Agent Manage API Keys Without Reading Them?). A leftover credential still works, and its value may already sit in the places a transcript goes.

Run the test on a dummy key and a copy of the repository, not the production credential. Then repeat it after the agent, the adapter or the identity provider changes, because the close is a property of three components and any of them can move the boundary.

What does a governed environment change?

A governed environment treats the lifetime as a field on the permission rather than a setting on a credential. The grant names the task, the page and the action, and it records when the permission ends. Enforcement sits outside the model: the component that honors the grant checks the term before it acts, so the end arrives as a refusal rather than as a request for the model to stop.

The control class has four parts. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the model works on CIKEY_001 and the string it would otherwise copy is not in its context. 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 that approval is where the lifetime is set. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring, so the close of the grant is an event a reviewer can find.

For this question the change is the difference between a clean end and a cleanup. An expiry on a value ends the value; a lifetime on a grant ends the permission, and the record shows both the term and the close. If the task is abandoned or fails, the same event closes the grant, which is the case a person with a checklist is least likely to catch.

The scope is the rendered page. A governed environment does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, where the credential lifetime and the sandbox rules described by the vendor pages do the work. The two are complementary, and the question of what the model read on the page remains separate from the question of how long the permission lasted.

Methodology and limitations

This page rests on two research preprints on privilege control and prompt injection in coding editors, four vendor documentation pages from Teleport, Cognition and Infisical, a law firm summary of a regulator report, one practitioner analysis and one vendor press release, plus 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 and the press release are cited as reported, not as independently measured. The regulator summary is cited for the warning it attributes to FINRA, and the coding-editor preprint for the figure its abstract reports.

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 lapses at task end, and not an organization.

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 and the identity provider, and after each change to the policy that sets the lifetime.

What the record shows

The pages reviewed answer the title in three parts. A lifetime on a credential ends the value; a lifetime on a grant ends the permission, and only the second can be tied to a task. The vendor designs closest to the question bound a session, a proxy or an MCP credential, and none closes a browser grant because the task closed. What closes it is a term written at approval, an enforcement point outside the model that reads the term before it acts, and a record of the close. The case for that design is the cost of the orphan: an agent that still holds the means after the reason has gone, in a population where leaked credentials are counted in the tens of millions and coding agents follow injected instructions at rates measured in the high double digits. RedactSure's environment is built on the grant model. To test it, name one agent and one task, ask what closes the grant, and try the same action after the record closes; an answer that is a date means a timer, and an answer that is an event with a name means a boundary.

Frequently asked questions

Can a grant expire on its own when the agent task ends?

Yes, if the lifetime is written into the grant and the component that honors the grant checks it. The grant names the task, the page and the action, and it carries a lifetime field set when a person approves it. When the task record closes, that component stops honoring the grant, so the next call fails without anyone running a cleanup step. The expiry is a term of the permission, not a scheduled deletion of a token. The record is what makes the lapse checkable later.

Who sets the lifetime, and what should it be?

The person who approves the grant sets it, and the task should set the number. A settings change that takes four minutes does not need a thirty-day window, and a migration that runs for hours should not be cut off in the middle. Write the lifetime beside the scope at approval time, and treat a default that nobody chose as a finding. The question to ask is what event will close the grant if the timer never fires. A lifetime that arrives as a default is a policy nobody reviewed.

What happens if the task ends and nobody records it?

Then the grant has no end event, and its lifetime becomes the only backstop. The agent may be finished while the credential remains valid until the clock runs out. The fix is to make the close automatic: the task record moves to complete, abandoned or failed, and the enforcement point reads that state before the next call. A grant that relies on a person noticing is a grant with an unassigned owner. An orphan is not a lapsed grant; it is a grant whose end was never defined.

Does an expiring grant stop the model from reading a page?

No. A lifetime governs how long the permission lasts, not what the screen shows while it is open. The model reads whatever the page renders, including values that have nothing to do with the action. An expired grant narrows the window; it does not remove what was already read, which is why the render layer matters alongside the lifetime. Check both, the term on the grant and what the page displayed. A term that lapses on schedule is only half of the answer.

Can a grant expire in the middle of a long task?

Yes, and that is a design question rather than a failure. If the task pauses for an approval, the lifetime may run out before the approval arrives. Set the lifetime to the task's expected duration with a margin, require a fresh approval to extend it, and record the extension with the name of the person who granted it. A silent extension is the same as no lifetime at all. A renewal is an event too, and it should carry a name.

What should a team ask a vendor in writing?

Where the lifetime field lives, who writes it, which event marks the task's end, and which component refuses the next call. Ask what record shows the grant's close and whether the record includes what the model read. A vendor that answers with a token expiry time has described a timer; one that answers with a grant and an end event has described a boundary, and the difference is what the page turns on.

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 Makes the Task Itself End the Grant

A cleanup step depends on whoever is busiest, and the pages reviewed bound a session, a proxy or a certificate without closing a permission when the task closes.

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

Before: the lead writes a 90-day CI key into the agent's environment, the agent opens the repository's Actions credentials page, and the value renders into its context. Inside: the grant names that page and one save action with a 45-minute lifetime, the page renders CIKEY_001, and the grant the named person approved covers this run and no later one.

RedactSure is deploying now with enterprise and government customers. Infisical documents time-bound grants, and Cognition scopes a credential to the session; neither describes a grant that closes at task end.

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

See it on your own workflow

A grant that outlives its task is standing access no one approved. Bring a task that needs a CI key and see, with test values, the grant that names the page, the action and the run it covers. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.