Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Long Should a Coding Agent Keep a Credential?

Zero seconds is the right default: a credential the agent never receives cannot outlive its task. Where the agent must hold one, the designs vendors document run from minutes to a refresh cycle, and custody matters more than the number.

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

When a team asks how long an agent should keep a credential, the argument usually settles on a number: an hour, a day, ninety days. The number is the least interesting part of the design, because the exposure the organization answers for is set elsewhere. What fixes it is where the value sits while it is valid, whether in a shell variable the agent can read, a file in its workspace, a token a wrapper exported before launch, or a proxy that holds the credential and attaches it to the call. An agent that holds a live key for a minute can still lose it to one injected instruction; an agent that never receives the value has nothing to lose. This means the route should be decided before the lifetime, and the page separates those routes on that basis, from what holding a credential means for a coding agent to why the strongest designs issue one for zero seconds and what makes a credential outlive its task. The worked record is a repository settings page where a deploy key is generated and displayed once, the rendered page closest to the moment a credential enters a run. The shell, the IDE and CI appear where their documentation bears on the question, and each section says which control covers which part of it.

Key findings

  • 1Password's design for browser agents keeps the credential out of the agent entirely: the agent and the LLM "never need to see nor handle the credentials," injected "if, and only if, the human approves the access" (1Password, Closing, 2025).
  • Infisical's Agent Vault takes the same position from the network side: "In short, the agent should not be trusted with direct access to any secrets," so the proxy attaches the credential to the call (Infisical, 2026).
  • The counterexample is documented too: "Doppler injects the config's secrets as environment variables, and Codex inherits them," which makes the credential's lifetime the life of the process rather than the task (Doppler, 2026).
  • Least privilege governs actions and credentials, not the content of the screen an agent reads, so an agent can satisfy it and still hold every value it was shown (What Is Least Exposure?).
  • Real values resolve only at the approved destination at the moment of an approved action, so a credential's working life is one action rather than one session (Can a Credential Vault Protect What an AI Agent Reads?).
  • Where a person must be in the loop, 1Password documents an approval rather than a shorter clock: "Human-in-the-loop authorization: Real-time approval prompts via 1Password mobile or desktop" (1Password and Browserbase, 2025).

What does holding a credential mean for a coding agent?

A coding agent holds a credential when its own process can read the value without asking anyone: an environment variable injected at start, a .env file in the workspace, a token a wrapper exported before launch, a key pasted into the prompt. Holding is a property of reach rather than of intent. The agent does not have to use the credential for it to be exposed, because anything the process can read it can print, copy into a patch or repeat in a summary.

The routes differ in who can end the exposure. A file or a variable ends when the process ends or the file is removed, and neither event is tied to the task. A vault token ends on its own schedule, which the vendor sets. A proxy ends nothing because the agent never held anything. The tether names the same distinction: a tethered agent goes anywhere its supervisor could go, an authority statement rather than a reading one (What Is a Tethered Agent?).

Arcade's documentation frames authorization as a question asked per action: "Can this agent, acting for this user, perform this action on this resource?" (Arcade, 2025). A credential's reach should answer the same three parts; a value that can act beyond them has a lifetime longer than the action that needed it.

The worked record is a rendered page, a repository settings page where a deploy key is generated and shown once. Inside that boundary, a governed browser environment covers what an agent reads and does on a rendered page, from dashboards and consoles to settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A key in a shell variable or a CI job is outside that boundary, so the vendor controls for it, environment injection, masking and short-lived tokens, are treated as the record they are.

Why is zero seconds the right default lifetime?

Zero seconds does not mean a credential that expires immediately. It means the agent never receives one. The component that makes the call holds the credential, attaches it as the request leaves, and returns only the result to the model. No interval exists in which the agent could read the value: no variable to print, no file to copy into a commit, no context for an injected instruction to collect.

1Password's release with Browserbase states that "Secure Agentic Autofill allows AI agents to authenticate with web services without ever exposing credentials," which is the zero-second case: the agent completes the login and never receives the value (1Password and Browserbase, 2025). The limit is in the same documentation: no technical detail on how the injection is implemented and no general availability date, so a buyer should ask where the credential is stored and what the model receives on the page after login.

A proxy or an adapter is the cheapest form of the control. An adapter is one integration point that calls pass through, so the credential lives in one place, rotates in one place, and is never handed to the model. The agent can still hold every record its screens rendered, which is why the zero-second route is a statement about what the model receives as well as about what the call is allowed to do.

Expiry changes what a stolen value can still do, and it does not change what the model already read. The value is either in the model's context or it is not, and only the second case makes the clock irrelevant.

What do the vendors themselves say?

The vendor pages reviewed split into two camps: designs that keep the credential away from the agent, and designs that inject it into the agent's environment and shorten its clock.

1Password's blog post adds the condition that matters for lifetime: the credential is injected "if, and only if, the human approves the access," so a run with no approval has no credential at all (1Password, Closing, 2025). How the value is attached is not described in the pages reviewed, so the design is documented at the level of the claim.

Infisical documents why a proxy is not enough on its own: "In a traditional proxy, that tunnel remains opaque, simply forwarding encrypted traffic," and Agent Vault "terminates TLS" so the credential can be attached to a request the proxy can read (Infisical, 2026). The post does not claim the design fully prevents credential exfiltration: a proxy narrows the route to the destination without securing the page the model reads.

Teleport documents "secure and short-lived access to these MCP servers," a short-lived credential for a tool connection (Teleport, 2026); its setup guide does not mention audit. Composio documents the opposite of a short clock: "Composio refreshes access tokens automatically before they expire, so connections stay ACTIVE with no work from you," and its page does not say what happens to in-progress calls when a connection expires (Composio, 2026).

Design What the vendor documents What a buyer should verify
1Password Agentic Autofill Credentials not shared with the LLM or in logs; approval prompt on mobile or desktop Where the value is stored, and what the model sees on the page after login
Infisical Agent Vault Agent gets no direct credential; proxy terminates TLS and attaches the credential Which destinations the proxy will attach it to
Doppler for Codex Credentials injected as environment variables the agent inherits Whether the agent can read, log or retain those variables
Composio connected accounts Access tokens refreshed before expiry; connection stays ACTIVE What ends the connection, and what happens to calls in flight
Teleport MCP access Short-lived access to MCP servers Whether audit covers each session
Arcade Authorization asked per agent, user, action and resource Which scopes a tool call can request

When the agent must hold one, how short is short enough?

HashiCorp's Vault tutorial states that "Token lifetime is reduced from days or weeks to minutes," and that the agent receives "a token that is read-only, repo-only, scoped to a single secret, and short-lived" (HashiCorp, 2026). Minutes, not hours, is the number the vendor documents, and scope does as much work as the clock: a token for one credential in one repository cannot be replayed anywhere else even while it is live.

The same tutorial shows the limit. Its wrapper "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent," so the raw token sits in the agent's environment, and the page does not say whether the agent can read it (HashiCorp, 2026). A five-minute token the agent can print is a five-minute exposure, not a zero-second one, and the difference is custody rather than duration.

The comparison this page returns to is a token with an hour on its clock against no token at all. An hour is generous enough for a long install and short enough that a leaked value stops working before most incident response begins, which is why days to minutes reads as the conventional ceiling rather than an aggressive setting. The number still does not cover the copy the model read while the token was live.

The steps that cannot be undone deserve a shorter clock than the steps that can. How to Use AI Agents to Launch an EC2 GPU Instance notes that five of those steps commit the account to something it cannot take back, and those five are where a credential's life should be counted in one action rather than in one hour.

What makes a credential outlive its task?

A credential outlives its task through copies, and the copies are made by systems working as designed. A token exported into the environment is inherited by every child process. A value printed in a job log is stored for as long as the log is. A key read from a page is in the model's context for the rest of the run.

GitLab replaces the value with a masked marker in the job log when a job outputs a masked variable, and its own page says "Masking a CI/CD variable is not a guaranteed way to prevent malicious users from accessing variable values" (GitLab, 2026). The page does not say whether masked values are removed from logs after a job finishes.

The research record adds the model's own memory: the study of neural code completion tools found that they "can not only return the precise piece of their training data," and that "two valid credentials were identified during our experiments" (Huang et al., 2024). The abstract does not give the number of tools or credentials tested, so the finding is cited for the pattern rather than a rate.

AgentCore Identity documentation states that centralized credential management eliminates the need to embed credentials in agent code or configuration files (Does AWS Bedrock Keep Company Credentials Away From Agents?). The advice against root access keys in Is It Safe to Let an AI Agent Set Up Your Cloud Environment? applies to any durable top-level credential handed to an agent, because a key that can do everything cannot be narrowed after the fact.

What does a governed environment change?

It changes where the lifetime is measured. In a governed environment the value is replaced with a token before any model reads the screen, and the model works with that token for the whole run. The token is consistent across pages, so a deploy key called KEY_001 on the settings page is KEY_001 in the summary the agent writes afterward. The real value resolves only at the approved destination, at the moment of an approved action, so the credential exists for one action rather than one session.

That is a different answer from a shorter expiry. An expiry bounds how long a value remains useful after it leaks. Rendering a token bounds what can leak in the first place. A one-minute credential in a page a model reads is still a credential in the model's context, and a token in a page a model reads is not a credential at all.

The consequential actions are where the tokens are resolved. A named person confirms the tokenization policy before the run and approves each action that resolves a value, whether it submits a form or writes a repository setting. The approval is recorded with the name attached, and the run produces an exported record of every screen as the model saw it.

For this page's question the answer stops depending on a number. A team can still set a short expiry for the underlying credential; the model's exposure no longer changes when it does. The record is what makes the difference auditable: it shows which values were tokenized, which action resolved them and who approved that action. The practical form of the rule is already described for API keys: the agent is given a handle rather than the key itself (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

Methodology and limitations

This page rests on ten external sources: two 1Password pages on credential injection for browser agents, Infisical's Agent Vault post and Doppler's Codex page on proxy and environment custody, Arcade's authorization write-up, Composio's connected-account documentation, Teleport's MCP access guide, GitLab's CI/CD variable documentation, HashiCorp's Vault tutorial, and one research preprint on credential memorization in code completion tools. It also rests on existing RedactSure research pages linked in the body. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page.

RedactSure did not test any named product hands-on. "Not described in the pages reviewed" means the recorded facts for that page do not cover the point, not that the product lacks the feature. Vendor features change, and the page carries its date; a release after that date is unreviewed until the checks below are repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The worked example describes a record type, a deploy key on a repository settings page, and not an organization.

Determinations about whether a credential's lifetime satisfies a contract, a control framework or a regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test on the organization's own agent, its own repository and its own identity provider. A reviewer should keep the page's date beside the answer and rerun the test after any change to the agent's configuration or to the vendor's documentation.

What the record shows

Ten sources and one worked record give a consistent answer, and it has two parts. Where a proxy or a browser integration holds the credential, the agent's exposure is zero and the value's lifetime becomes the vendor's problem. Where the credential is injected into the agent's environment, its lifetime is the process's lifetime, and every copy the agent makes inherits it. Between those, a token issued for minutes narrows the window without removing the copy the model already read while the token was live. RedactSure's environment is built on the zero-second route. Any team can run this test on one agent and one repository task: run it with a deploy key, then write down where the key existed and what the model received on the page that displayed it.

Frequently asked questions

How long should a coding agent keep a credential?

For as short a time as the task can tolerate, and ideally not at all. The strongest documented designs keep the value with a proxy or a browser integration and give the agent only a completed call, so its holding time is zero. Where the agent must hold one, the Vault tutorial's shift from days to minutes is the conventional ceiling. What matters alongside the number is scope: a token for one credential in one repository cannot be replayed elsewhere even while it is live.

Is a token that expires in an hour short enough?

It bounds misuse, not exposure. An hour is short by the standard the industry inherited, when tokens lasted days or weeks, and long enough for a build or an install. During that hour the agent can read the token, print it or carry it into a commit, and an injected instruction can use it before it expires. The clock shrinks the window; it does not change who could read the value while the window was open.

Does a refresh token defeat the point of a short lifetime?

Yes, when the refresh is automatic. Composio's documentation describes connections that stay ACTIVE because the platform refreshes access tokens before they expire, which is convenient and also means the usable life of the connection is set by the refresh policy rather than by any single token. A refresh token is a durable credential in everything but name. Ask what revokes the whole connection, not what expires the current token.

What is wrong with putting a key in an environment variable?

Nothing, if the process that reads the variable is trusted with the key. The problem is that a coding agent's process is the least trustworthy part of the run: it reads untrusted files, installs packages and runs commands. A variable is available to every child process, every log line and every tool the agent invokes. Doppler's Codex page says the agent inherits the injected credentials. The variable is the least private place a key can sit. Inheritance, not the mechanism, is where the risk sits.

Can a masked credential still leak from a CI log?

GitLab's documentation says masking is not a guaranteed defense against a malicious user who can reach the variable values, and the page does not say whether masked values are removed after a job finishes. Masking rewrites a value in the log; it does not remove the value from the job, the runner or the artifacts. Treat a masked variable as a credential with a redaction step, not as a credential the log cannot hold. A partial value in a job log is still a hint.

What should a security team ask a vendor in writing?

Where the credential is stored, which component can read it, what the model receives on the page where it appears, what revokes it, and what record shows each use. Ask for the answer per route, because a vendor that keeps the value in a proxy and one that injects it into the agent's environment produce very different exposure. Then test one task on a repository settings page and compare the transcript with the answer. Write the answers down and date them.

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 Bounds a Credential to One Approved Action

Every design reviewed answers the clock with an hour, minutes or a refresh cycle, while a credential readable on a settings page stays exposed whatever its expiry says.

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

Before: the agent generates a deploy key on a repository settings page, and the page renders the key to the model. Inside the governed environment: the page renders KEY_001, and the real value reaches the repository only when a named person approves the write.

RedactSure is deploying now with enterprise and government customers. HashiCorp's tutorial reduces token lifetime "from days or weeks to minutes" and still exports the token into the agent's environment.

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

See it on your own workflow

A credential an agent keeps past the action it was needed for is exposure no one approved. Bring a task that creates a deploy key and see, with test values, what the model reads and when the real key is written. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.