Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Happens to a Credential an Agent Created but I Did Not Approve?

It stays a live credential, usable by whatever holds it, until its lifetime ends or someone revokes it, unless a control holds it unusable until a person approves it. Ask where the created value is held, how long it lives and whether a named approval stands between its creation and its first use.

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

For the team accountable for an agent's access, the risk starts when the agent opens a console's token page and creates a token: it has made a live credential, and the page shows it once. What happens next depends on what stands between the creation and the first use. If nothing does, the value sits where the page put it, in the model's context and then in whatever the agent writes, and it works until it expires or someone revokes it. If a control holds the value until a person opens it, checks it and accepts it, the credential is inert until that moment. This page sets the scope, follows one record, a token captured and left unapproved, through the places a created credential can sit, reads what vendors document about short-lived, single-use and scoped credentials, and ends with a test a team can run on a test account. A reader who stops here has the answer: unapproved does not mean inactive, and a person's approval is the control that changes that. The separate question of who approves the submission that uses a credential is covered in Why Should Submitting a Credential Require Its Own Permission?.

Key findings

  • A 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," the memorization risk a created token faces once it enters model-facing text (Huang et al., 2024).
  • OWASP's Non-Human Identities Top 10 lists credential leakage as NHI2, the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores," and overprivileged identities as NHI5 (OWASP, 2025).
  • In GitGuardian's test of Copilot, "over 1,200 leaked at least one secret" and "Copilot generates 2702/900 = 3.0 valid secrets for one prompt on average," a measure of how readily a model repeats a value it has read (GitGuardian, 2025).
  • A governed environment replaces a created token with a consistent placeholder such as TOKEN_001 before any model reads the screen, so the agent works on the placeholder and never holds the value the console displayed once (Can a Credential Vault Protect What an AI Agent Reads?).
  • Real values resolve only at the approved destination at the moment of an approved action, and a named person is accountable for that approval (What Is Supervised Delegation?).

What does a governed browser environment cover when an agent creates a credential?

A governed browser environment covers what an agent reads and does on a rendered page: dashboards, consoles, settings pages and sign-up forms, including the page where a token is created and displayed. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A token an agent creates by calling an API from a shell is outside this page. A token it creates by pressing Generate on a console page is inside it.

The example record is a token captured and left unapproved. An agent working a developer console opens the token page and creates a token with a scope and an expiry. The console displays the value once, and the agent captures it for the next step. No person has opened it, checked its scope or accepted it. The question is what that value is, and who can do anything with it, between capture and approval. The page treats the token as an object with a scope, an owner and an expiry, because those are the fields a reviewer can judge.

Three states are possible. In the first, the value is live and in the agent's context, usable by anything that can read the context. In the second, it is live but held outside the agent, so the agent holds a reference and cannot present the value. In the third, it is held and unusable until a person approves it, and discarded if no one does. The rest of the page asks which of the three each documented design provides.

Where does an unapproved credential sit, and who can use it?

In the first state it sits wherever the page put it. A console that displays a token once has already delivered it to the screen, and a model that reads the screen holds it. From there it can be repeated in a summary, written to a file or carried into a transcript, and anything that reads those can use it for as long as the token lives. A token that carries more scope than its task needs is the overprivileged identity OWASP lists as NHI5 (OWASP, 2025).

The volume of credentials already in unsanctioned places is the reason this matters. SecretBench is "a labeled dataset of source codes containing 97,479 secrets (of which 15,084 are true secrets)," and a created token that reaches a file is one more true credential in that population (Basak et al., 2023).

The unapproved credential has a second exposure through the next step the agent takes. Code generating models hallucinate package names at a rate of "at least 5.2% for commercial models and 21.7% for open-source models" (Spracklen et al., 2025). An agent holding a live token that installs a package whose name it invented has put the token in reach of whatever that package does. The abstract does not say whether hallucinated names were registered and exploited, so the point concerns reach and not a measured attack.

What do the vendors themselves say?

The vendor pages below describe how credentials are wrapped, scoped, stored and tied to identities. They are the nearest documented controls to the third state, and each one governs a credential's life or holder. Each row states one thing and leaves one question with the buyer; read it for both.

Dimension Vendor, per its documentation What a buyer should verify
Single-use wrapped token HashiCorp's response wrapping documentation states that "A new single-use token is generated with the TTL supplied by the client" and that "Vault currently does not provide signed response-wrapping tokens, as it provides little extra protection" (HashiCorp, Response, 2026). The page gives no default or maximum TTL. Ask who sets the TTL for an agent-created credential, and whether an unopened wrapped value expires.
Scoped, short-lived token HashiCorp's tutorial states that "the agent receives a token that is read-only, repo-only, scoped to a single secret, and short-lived," and its wrapper script "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent" (HashiCorp, Secure, 2026). The raw token is in the agent process's environment, and the page does not say whether the agent can read it. Ask whether a person accepted the token before the agent received it.
Credential kept off the session machine Anthropic's Claude Code documentation states that "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM," and that "The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can" (Anthropic, 2026). The first statement concerns GitHub credentials in a cloud session and the second concerns shell commands. A token an agent creates on a console page is not described in the pages reviewed.
Agent identity Teleport's documentation states that "Your agents need 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" (Teleport, 2026). The page marks most listed capabilities as in progress or not started and gives no certificate lifetime. Ask which are available now and whether they cover a credential created on a page.
Workload identity Microsoft's documentation states that "Managed identities eliminate the need for developers to manage these credentials" and that token acquisition "doesn't require any secrets" (Microsoft, 2026). The design is for workloads on Azure resources, not for a console page. Ask what happens to a credential an agent creates outside that boundary.

The rows concern when a credential expires, how far it reaches and where it is stored. What a person accepts before a created credential works is a separate control, taken up next.

How does an approval gate change what happens to the credential?

Under a gate, the created value never reaches the model as a value. The page is drawn, the token displayed once is replaced in the agent's view by a placeholder such as TOKEN_001, and the real value is held and not used. The agent can still carry out the steps that need the token, because it names the placeholder, and nothing can present the real value until a person opens it, checks its scope and expiry and accepts it. Until then it is inert. That acceptance is the first approval in a flow of two; the second is the approval of the submission that uses the value, and Why Should Submitting a Credential Require Its Own Permission? covers it. A named person is accountable for that approval (What Is Supervised Delegation?).

Three outcomes follow. If the person accepts, the value is saved to a store and released only to approved destinations. If the person rejects, it is discarded and revoked at the issuer. If no one acts, it stays unused. The gate does not make the third outcome safe by itself: an inert value is not a revoked one, because the token still exists at the issuer. The reviewer needs a revoke path and a short expiry as well, and the record needs to show that the token was created, who was asked and what happened (What Is an AI Control Record?).

The designs in the previous section are the complement. Wrapping and short lifetimes bound how long a value works, and scoping bounds what it can reach. The gate decides whether it works before anyone has looked at it.

How can a team test what happens to an unapproved credential?

Name one agent and one task, use a test account, and have the agent create a token with a short expiry on a console page. Leave it unapproved. Then answer five questions from evidence and not from the product page. Does the transcript hold the value or a placeholder? Can the agent's session present the value to the service? Does the issuer's token list show the token as active, and with what scope? Does it stop working at its expiry? Is there a record of the creation and of the missing approval, with a named person?

A run of this kind separates the three states quickly. A transcript that holds the value is the first state. A transcript that holds a placeholder, with the token active at the issuer and no way for the agent to present it, is the third. The cases around it are covered in What Happens When an AI Agent Creates a GitHub Token in the Browser?, How Do I Stop a Browser Agent From Seeing the Token It Creates?, What Happens When an AI Agent Can See API Keys in a Console or Settings Page? and How Do You Let an AI Agent Manage API Keys Without Reading Them?.

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 TOKEN_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, including every payment, submission and record change. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this page's question, it turns a created credential from a live value in the model's context into a held value that no agent can present. The person who approves sees the token's scope and expiry, not its value, and the record shows who approved what and when. When the credential is used, the real value reaches the destination the person approved and not the transcript, the next page or a file the agent writes. If the person rejects it, nothing in the model's context needs cleaning up, because the value was never there.

It governs the rendered page and nothing else. A token created by an API call in a shell is outside it, and stays with the sandbox and the credential store the team configures for that agent.

Methodology and limitations

This page rests on three research preprints on credential memorization, package hallucination and credentials in source code, vendor documentation from HashiCorp, Anthropic, Teleport and Microsoft, OWASP guidance on non-human identities, one vendor research post from GitGuardian, 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 figures from research posts are cited as reported and not as independently measured. The preprints are cited for what 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" means not described in the pages reviewed. The two-approval flow is described as a design requirement and as RedactSure's current design, and not from a vendor page, and RedactSure is deploying now with enterprise and government customers. Teleport's page marks most listed capabilities as in progress or not started, and this page treats them as stated plans and not as shipped features. Vendor features change, and the page carries its date; a reader should treat a release after that date as unreviewed until the test above is repeated. The example describes a record type, a token captured and left unapproved, and not an organization.

Determinations about whether a credential practice 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 a test account, repeated after each release.

What the record shows

A credential an agent creates is live from the moment the page displays it, and the documented controls differ in what they limit: lifetime, scope or holder. Expiry and scope narrow what an unapproved credential can do; they do not decide whether it works before anyone has looked at it. A design that holds the value unusable until a person approves makes the unapproved case inert, but an inert value is not a revoked one, so the issuer's token needs a revoke path or a short expiry as well; RedactSure's environment is built on the hold. Pick one agent and one task for the test, have the agent create a test token and leave it unapproved, then write down where the value sat, who could use it and when it stopped working.

Frequently asked questions

What happens to a credential an agent created but I did not approve?

It depends on where the value was put. If the agent read it from the console page, the value is in the model's context and works until it expires or is revoked. If a control holds it outside the model, it stays unused until a person approves it, and the token still exists at the issuer. In both cases, find the token in the issuer's list and revoke it, or let a short expiry end it, and check the transcript for the value.

Does an unapproved credential still work?

At the issuer, yes: the console created it, and it works until its expiry or revocation. What changes under a hold is who can present it. If the value never reached the model and nothing can submit it before a person approves, the agent cannot use it, but anyone who obtained the value another way, including from a copy left in a log, can. Treat creation as the start of the credential's life and approval as the start of its use, and record both events.

Is a short expiry enough?

A short expiry narrows the window in which a leaked value works, which helps. It does not decide who can use the value during that window, and minutes are enough for an automated caller. Pair expiry with a hold on the value before its first use, and with a revoke path the reviewer can reach from the approval screen, so a rejected credential does not wait for its clock to run out and an approved one can still be withdrawn later.

What should a reviewer look at before approving a created credential?

The scope it carries, its expiry, the account that owns it, the task it was created for and the destination where it will be used. A credential broader than the task needs should be rejected and revoked, not approved with a note. The reviewer can judge every one of these fields without reading the credential itself, because scope and expiry are properties of the token and not the value, and the approval record can store the reviewer's name and the date of the decision beside them.

Can an agent leak a credential it created in a shell?

Yes, through any route outside the rendered page. A governed browser environment does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so a token created by an API call in a shell, or written to a file the agent later reads, is governed by the sandbox and the credential store a team sets up for its coding agent. The browser control governs the console page where the token is shown, and the shell needs its own control.

What should a team ask a vendor in writing?

Where an agent-created credential is held before a person accepts it; whether the model receives the value or a placeholder; how long the value lives and who can revoke it; who is named as the approver; and what record shows creation, approval or rejection. Treat any answer the documentation does not support as unanswered until a run with a test token confirms it, and keep the written answers beside that run's transcript, with the date of the run and the version of the tool.

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 Holds a Token an Agent Created Until a Person Approves It

A credential an agent creates is live as soon as the page displays it, and expiry only shortens that window without holding the value until a person approves.

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

Before: the agent creates the token, reads the value the console shows once, and carries it into its context and any file. Inside the governed environment: the model sees TOKEN_001, the real value is held and cannot be used until a named person approves it. If no one does, it stays unused, and the record shows the token was created and never accepted.

RedactSure is deploying now with enterprise and government customers. A study of code completion tools identified two valid credentials in what they returned.

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

See it on your own workflow

A token an agent created without approval should stay unusable until a person decides. Bring a task that creates a token and see, with test values, how it is held and what the record shows. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.