Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is the Difference Between Approving a Credential and Approving Its Use?

One approval lets a credential exist in a store under a named owner; the other lets a specific agent use it for a specific task. Check which of the two a tool records, and whether the second names the agent, the task, the destination and an expiry.

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

A vault entry and a token in an agent's hands are two different permissions, and most consoles ask for one and imply the other. The first is a decision about existence and custody: whether a value may be kept, who owns it, how long it stays and how it is rotated. The second is a decision about a task: whether a named agent may present that value on a named operation, and where the result may go. Neither decision contains the other, and a store that is read as a standing permission turns a kept credential into a used one without anyone choosing that.

The two are hard to see apart because they often share one button and one dialog, and because the second is often implicit: an agent that can reach a store reads what it needs. This means an approval given for keeping a token is often read as approval to use it, and a reviewer should look for two events where the console shows one. One token on a code host's settings page is followed here through both. The record of that run is what What Is an AI Control Record? sets out, and the handling question is worked through in How Do You Let an AI Agent Manage API Keys Without Reading Them?.

Key findings

  • HashiCorp's Vault documentation describes the delivery of a value as its own event: in response wrapping "A new single-use token is generated with the TTL supplied by the client," so a credential can be handed over once, on a clock the requester chooses (HashiCorp, Response, 2026).
  • "All dynamic secrets in Vault are required to have a lease," and "When a lease is revoked, it invalidates that secret immediately and prevents any further renewals" (HashiCorp, Lease, 2026).
  • The Model Context Protocol's security guidance puts the test at the token's audience: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server" (Model Context Protocol, 2026).
  • Infisical's Agent Vault design starts from the reverse default: "In short, the agent should not be trusted with direct access to any secrets" (Infisical, 2026).
  • A governed environment substitutes a consistent token for a stored value before any model reads the screen, so the model works on TOKEN_014 while the store keeps the value (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, so the second approval names a place and an act rather than a stored copy (What Is an AI Control Record?).

What does a governed browser environment cover when a token is approved?

The scope comes first, because the two approvals in this title happen in different places and only one of them is visible to a browser control. A governed browser environment covers what an agent sees and does on a rendered page: dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A token that a person approves in a vault and a shell then exports is inside the custody question and outside a browser control; a token that an agent reads on a provider's token settings page is inside both.

The record for this page is one token on a code host's token settings page, approved once and then granted once. The page renders the token list, a name field, a set of scope checkboxes and an expiry date. The first event happens there when a person decides the token may be created and kept in the workspace store, which fixes the owner, the retention and the rotation schedule and names no agent. The second happens when a person decides that one named agent may present the token for one task, which fixes the repository, the operation and the run, and creates no new value.

The two events leave different traces. A store entry has an owner and no end date; a grant has an end date and no stored value. A team that can point to both, and can say which one a given dialog asked for, has the distinction the title names; a team that can point only to the store has a credential that anything with read access may spend.

A third case sits between them: a person approves a token on a settings page, and the agent that later reads it may not be the one the person had in mind, because nothing in the first approval records which agent will do the reading.

Question Approval to keep Approval to use
What it names The value, the store, the owner, the retention The agent, the task, the operation, the destination
How long it lasts Until it is revoked or rotated The run, or the stated expiry
What it leaves behind A store entry A grant line in the record
What it leaves unsaid Who may use the value Whether the value should exist at all

What does the approval to keep a credential authorize?

The first approval is a decision about custody. It says that a value may exist in a particular store, under a named owner, for a stated retention and rotation. It says nothing about which process may read the value, because in most stores reading is a property of access policy rather than a separate decision. A vault entry is a permission to hold, and who may spend the value is left to whatever can reach the store.

Microsoft's documentation describes a design that removes the first approval by removing the stored credential: "Managed identities eliminate the need for developers to manage these credentials," and "This token acquisition doesn't require any secrets and is automatically authenticated based on the environment where the code runs" (Microsoft, 2026). The limit is the setting: it is a design for workloads on Azure resources, and it describes no token rendered on a settings page and no person approving a use.

Infisical's Agent Vault takes the custody question to the request path. The post argues that "In a traditional proxy, that tunnel remains opaque, simply forwarding encrypted traffic," and that "To solve this, Agent Vault terminates TLS" (Infisical, 2026). A terminated connection lets a proxy place the credential instead of handing it to the caller, though the post does not claim the design fully prevents credential exfiltration and describes no per-task approval by a person.

What do the vendors themselves say?

HashiCorp's response wrapping page documents a one-time delivery: "A new single-use token is generated with the TTL supplied by the client" (HashiCorp, Response, 2026). The token can be unwrapped once, which makes the handover an event rather than a state. The page is explicit about the limit: "Vault currently does not provide signed response-wrapping tokens, as it provides little extra protection," and it gives no default or maximum TTL, so the lifetime is the operator's to set.

The lease page carries the same idea for issued credentials. "Vault promises that the data will be valid for the given duration, or Time To Live (TTL)" (HashiCorp, Lease, 2026). A lease is what makes an approved use expire without another decision, and revocation is the other half: "When a lease is revoked, it invalidates that secret immediately and prevents any further renewals" (HashiCorp, Lease, 2026).

Teleport's agentic identity page argues for identity in place of a shared key: "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key" (Teleport, 2026). That binds a use to a workload, which is the property a static store entry lacks. The page marks most of its listed capabilities "In-progress" or "Not started" and gives no certificate lifetime, so a buyer should read it as a direction rather than as a shipped control.

Dimension HashiCorp Vault, per its documentation What a buyer should verify
Second step A wrapping token, single use, with a TTL supplied by the client Whether the handover is logged against the agent that received it
Lifetime Leases on issued credentials, with no default TTL stated Who sets the TTL, and whether a policy caps it
Reversal Revoking a lease invalidates the credential at once How fast a revocation reaches a running agent
Identity Response-wrapping tokens are not signed Whether anything binds the use to a workload identity
Model view Not described in the pages reviewed What the model received on the page that held the value

What does the approval to use a credential add?

The second approval is narrower than the first in every dimension except one: it is the only one that names an agent. It names the agent, the task, the resource, the destination and an end.

The Model Context Protocol's guidance states the rule as audience. "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server," and "Poor scope design increases token compromise impact, elevates user friction, and obscures audit trails" (Model Context Protocol, 2026). The guidance is written for MCP implementers and does not describe how a coding agent's own credentials are held.

HashiCorp's tutorial shows a scoped use grant in practice: "the agent receives a token that is read-only, repo-only, scoped to a single secret, and short-lived" (HashiCorp, Secure, 2026). The same page shows how the token arrives, with a wrapper script that "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent" (HashiCorp, Secure, 2026). That places the raw token in the agent's environment, and the page does not say whether the agent can read it.

An identity-first privileged access design governs the same layer. CyberArk describes "an identity-first approach to agentic AI security built on tight privilege controls," which governs the identity rather than the model's view (RedactSure vs CyberArk: 2026 Comparison & Alternative). A use approval at the identity layer can be tight and still leave the model reading a page with a live value on it.

What happens when one approval stands in for the other?

When a store entry is read as permission to use, the second decision never happens and nobody notices, because the value works. The record says that a credential exists and nothing says who spent it.

Datadog's DevSecOps research gives one shape of the failure at scale: "We found that 37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions" (Datadog, 2025). An IAM user is a stored identity: it exists once and every workflow that holds its keys uses it, so the approval that created it stands for every later use. The sample is Datadog's own customer base, which limits how far the percentage travels.

Truffle Security's scan of web data shows the other cost of a value that lives in many places: "11,908 Live Secrets were detected using TruffleHog in 400TB of web data," across "2.76 Million Web Pages" (Truffle Security, 2025). The post does not establish that any particular training set included those pages, and it does not need to for this point: a credential copied into a store, a variable and a page is live in each of them.

The keep decision belongs where the value will sit, and the use decision belongs where the action happens. AWS strongly recommends not creating access keys for the root user, which removes the most durable credential an account can have, as Is It Safe to Let an AI Agent Set Up Your Cloud Environment? records. A cloud build makes the use rule visible: five steps of an EC2 GPU launch commit the account to something it cannot take back, and each of those five stops for an approval, a sequence How to Use AI Agents to Launch an EC2 GPU Instance sets out.

What does a governed environment change?

A governed environment is a control class that acts where a page 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_014. 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, and every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring (What Is Supervised Delegation?).

For this page's question the change is in where the two decisions are made. The keep decision still happens in a store, and the environment does not remove it: a value still has an owner, a retention and a rotation. The use decision moves to the page, where the environment can see the task, hold the value back, and record what the model was shown. The store entry and the grant stop sharing a surface.

The distinction becomes checkable. A reviewer can ask for the policy that set the tokens, the grant that named the agent and the task, the name beside the approval, and the page as the model saw it (What Is Render-Layer Tokenization?). A store cannot produce the second and third of those, and a page control cannot produce the first. The separation is what makes each question answerable on its own.

Methodology and limitations

The page rests on vendor documentation from HashiCorp, Teleport, Infisical and Microsoft, on the Model Context Protocol's security guidance, and on two vendor research posts, Truffle Security's scan of web data and Datadog's DevSecOps survey. Each is cited for the fact recorded beside it and for nothing else. Vendor and standards pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Where a page states a limit, the limit is repeated beside the fact. The RedactSure research pages are cited for definitions this page uses, not as evidence about a third party.

No vendor was tested hands-on for this page. Where the page says something is not described in the pages reviewed, it means the pages listed in Sources, not a statement about a vendor's whole product. Vendor features change and the page carries its date, so a reader should confirm a quoted sentence on the page itself before relying on it. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The token settings page is a record type, not an organization: no customer, repository, token or approver in the example is real, and the example is written to be repeated with test values.

Determinations about whether a particular control satisfies a regulation, a framework or an internal policy belong to the organization's counsel, its assessors and its own security and compliance officers. This page records what the documentation states and what follows from it. It does not decide whether a given deployment meets an obligation, and a comparison between a store and a page control is a design question whose answer depends on the deployment.

What the record shows

Approving a credential and approving its use are different decisions because they answer different questions. The first says that a value may exist, who holds it and how long it stays. The second says that this agent may present it for this task, at this destination, until this run ends. The vendor designs reviewed here supply the second as its own artifact, a single-use wrapping token, a lease, a token scoped to one credential for a short time, and each of them leaves the first decision in the store. The record is where the separation becomes visible: one entry with an owner, one grant with an agent and an end. A practical test names one agent and one task, asks which approval named the token and which named the use, and then reads the page as the model saw it after each step. If the same dialog answers both halves, the two decisions have not been separated.

Frequently asked questions

What is the difference between approving a credential and approving its use?

The first approval is about existence and custody: a value may be kept in a named store, under a named owner, for a stated period. The second is about a task: this agent may present the value here, for this operation, until this run ends. The second does not follow from the first, and the first is not repeated for every task. Ask a tool which of the two it is recording when it asks you to click, and ask to see both entries afterward.

Who should give each approval?

Approval to keep is usually an owner or platform decision: whoever answers for the store, its retention and its rotation. Approval to use belongs with the person accountable for the work the agent performs, because that person knows the repository, the operation and the consequence. Both records should carry a name rather than a role, since a role cannot answer a question after an incident. A shared service account erases the distinction before anyone has a chance to use it, and it leaves no name to ask afterward.

Does a vault entry count as permission to use a credential?

Only if the tool says so, and most do not say. A vault entry records that a value exists and who may administer it; it does not name an agent, a task or a destination, and it usually carries no end date. Access to the store is a permission to read, which is a different grant from a permission to act. Treat a store that any process can read as a standing use approval that nobody gave, because in practice that is what it becomes.

What should a use approval name?

The agent, the task, the resource the task touches, the destination the result may go to, and an expiry. It should also name the person who gave it, in a form the record keeps. One documented shape is a single-use delivery token whose lifetime the requester supplies, so that handing over a value is an event with a clock. An approval that names only the application has named nothing a reviewer can check later, and nothing the record can show.

Does a short-lived token make the second approval unnecessary?

No. A short lifetime limits how long a mistake lasts; it does not decide whether the use should happen. A five-minute token in an agent's environment is still a token the agent can spend on any operation its scope allows, in any repository the scope reaches. Lifetime and approval answer different questions, and a useful control names both in the same record, with the task and the destination beside them. Neither substitutes for the other.

What record should show both approvals?

One that keeps them distinguishable: the entry that admitted the value to the store, with its owner and date, and the grant that allowed the run, with the agent, the task, the destination and the approver. If the two collapse into a single line, a reviewer cannot tell whether a use was ever decided. The test of the record is whether it answers what the model was shown as well as what it did, and whether a reader can separate them without asking anyone.

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 Separates Keeping a Credential From Using It

A store answers whether a value may exist, and the designs above issue permission to use it separately without holding the two apart on the page.

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

Before the control, the model on that token settings page read the token value, the scopes and the expiry as text. Inside it, the page renders as TOKEN_014, the grant names one repository and one operation, and the approver is named in the record.

RedactSure is deploying now with enterprise and government customers. Datadog found 37 percent of the customers it studied running GitHub Actions on IAM users.

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

See it on your own workflow

Approving a credential and approving its use are separate decisions, and most tools merge them. Bring a token task and see, with test values, each approval in the record and what the model reads. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.