Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does a Coding Agent Need Approval Before Using a Credential for the First Time?

Yes, and the first use is where the approval belongs: it is the moment the scope, destination and lifetime of the grant are set, and later calls within them need no new prompt. Ask a tool to show the grant behind the first call and the record of who approved it.

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

A coding agent that holds a credential can call a service on its own, and whoever approved the agent has to decide when a person is meant to look. The answer this page builds is that the look belongs at the front: the first call is where someone settles which credential, which destination, how long it lasts and how many calls it covers, and later calls spend a decision already made. Approval stays on under this design; it separates a decision about a range of work from the work itself, which is the difference between a person who reads ten requests and a person who reads one. The evidence is what Cursor, OpenAI, 1Password, Doppler and Teleport document about approvals and credential handling, tested against one record type, a grant covering ten calls, and the control class that makes such a grant visible. One limit runs through it: an approval governs what the agent may do, and says nothing about what its model was shown while it did, which is why the last section states the control class separately. A reviewer should therefore ask for two records before approving a grant: its terms and what the model was shown.

Key findings

  • Cursor's documentation states that "by default, terminal commands need your approval" and that "all MCP connections need your approval," which places the approval on an action or a connection rather than on a credential's first use (Cursor, 2026).
  • Doppler's page tells teams to "give every coding agent its own scoped, read-only, expiring set of credentials," a grant with a scope and an end date rather than a prompt before every call (Doppler, 2026).
  • The 1Password and Browserbase design states that "credentials are not shared with the LLM or exposed in Browserbase logs and repos" and lists "real-time approval prompts" as the human step, so the person approves an access the model never holds (1Password and Browserbase, 2025).
  • A governed environment keeps the model out of the credential path: the value is substituted before the screen is read, and real values resolve only at the approved destination at the moment of an approved action (Does an AI Agent Need Access to Your Stored Credentials?).
  • The record answers what the model saw and who answered for what it did, which is the question neither a system of record nor a log answers on its own (What Is an AI Control Record?).
  • FINRA's 2026 oversight report, as summarized by Debevoise & Plimpton, 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).

Where does a first-use approval apply when the agent works on a page?

The answer depends on where the credential is used, and this page keeps to the rendered page. A governed browser environment covers what the agent reads 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 exported into a shell session, a key read from a file, or a call made straight to an API from a script is outside it, and the sandbox and credential store a team configures govern those paths.

The split decides what first use means. On a rendered page the credential is usually visible: a repository's token settings page shows the token string, its scopes and its expiry, and an agent that opens it reads all three. The first approval is where a person decides whether the agent may open that page, and later what it may do with what it read. In a shell there is no page and no rendering: the credential is a string in a file or a variable, and the question becomes how the sandbox is built rather than what the model was shown.

The record worked through here is a grant covering ten calls. The first call opens a token settings page to confirm the scopes on a credential, and the nine after it use that credential against an API. The grant makes ten calls one decision, and it is why the eleventh call is a separate question. A sign-up form shows the same shape with a card in place of a token, and the approval is the difference between a number the model read and one it never saw (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?).

Why is the first use different from the tenth call?

Approval is a decision, and a decision has a subject. When a person approves a credential's first use, the subject is not one call: it is a credential, a destination, a set of operations, a lifetime and a count of calls. The ten-call grant is that subject written down. The tenth call spends the same decision, so no new prompt appears, because no new decision is being made. The first call is different because it is the only one where the person can still change the terms, which is why a review has to check the terms rather than the prompt.

The other designs fail in ways a record shows. A prompt on every call makes the person the rate limiter, and a person who sees ten prompts learns to accept the eleventh without reading it. Auto-approve removes the person altogether and leaves nothing to review. A grant with a scope, a destination, a lifetime and a count keeps the person at the decision.

Design What the person decides What the run may do afterward Where it fails
Prompt on every call One call at a time Exactly the call shown Ten calls, ten prompts, and reading stops
Auto-approve Nothing Whatever the agent proposes No human decision to review
First-use grant Credential, destination, operations, lifetime, count Every call inside those terms Terms too wide, or never reviewed

The failure mode of the grant is scope, not timing. OWASP's non-human identity list defines secret leakage as the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores" and gives overprivileged identities an entry of its own (OWASP, 2025). That entry is the reason the first approval has to be an approval of terms rather than a yes. The person who signs those terms is the person a review will ask about, which is the accountability most agent deployments cannot name today (What Is Supervised Delegation?).

What do the vendors themselves say?

Five vendor pages bear on this question, and each places the decision at a boundary, not at first use.

Cursor's Agent Security page states that "by default, terminal commands need your approval" and that "all MCP connections need your approval," and it does not describe how credentials are stored or protected (Cursor, 2026).

OpenAI's Codex documentation states that "by default, the agent runs with network access turned off" and that "Codex asks for approval to edit files outside the workspace or to run commands that require network access," so the prompt follows a boundary, not a first use (OpenAI, 2026). An OS-enforced sandbox limits what the agent can touch, and the page does not describe how credentials are stored locally.

The 1Password and Browserbase announcement states that "secure agentic autofill allows AI agents to authenticate with web services without ever exposing credentials" and that "human-in-the-loop authorization: real-time approval prompts" are how the person is asked, with no detail on how the injection works (1Password and Browserbase, 2025).

Doppler's page says credentials are "injected at runtime instead of written to a .env, so agents can't read, log, or commit them," and it does not say whether an agent can read the variables injected into its own process (Doppler, 2026).

Teleport's framework states that "your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key," an identity in place of a shared credential, though most listed capabilities are marked in progress (Teleport, 2026).

Dimension Cursor, per its documentation What a buyer should verify
What triggers approval Terminal commands and MCP connections, by default Whether the trigger is first use or the action itself
First use of a credential Not stated on the page Which approval covers the first call and what it names
Where a credential lives Not described in the pages reviewed Storage, read access and rotation
Strength of the guardrail "Best-effort guardrails rather than a hard security boundary" Whether the control is enforced outside the model

What should a grant covering ten calls record?

Six fields make the grant reviewable: who approved it, which credential, which destination, which operations, how long it lasts and how many calls it covers. A grant missing any of them cannot answer what the tenth call was allowed to do, and a person asked to approve it is being asked to guess.

Field Question it answers Test
Approver Who decided, by name The record shows a person, not a role
Credential Which credential, at which version The credential can be identified without printing it
Destination Where the value may go A second destination is refused
Operations What may be done A write is refused when only reads were granted
Lifetime and count When it ends The eleventh call is refused

The fields are also what makes the grant testable. Run the ten calls, then attempt an eleventh to a different destination; an environment that enforces the terms refuses both, and a tool that stores a policy may only log them.

The lifetime is the field teams leave blank most often. A grant that expires with the task needs no cleanup and no revocation step; one that outlives the task becomes a standing key that nobody re-approves, and the review never happens because no prompt appears again. Writing the expiry into the grant is what keeps a first approval a decision rather than a default.

The second OWASP entry matters here: NHI5 is overprivileged identities, which is what a grant becomes when its terms are wider than the task (OWASP, 2025). Over-sharing is the same error in another system: an agent reads every field a page or a repository renders for the account, and the fields it does not need turn a narrow grant into an incident (How Do You Stop an AI Agent From Seeing Employee Personal Information?). A grant written to the task is the smallest thing a person can approve and the easiest thing to review.

What goes wrong when the first grant is never reviewed?

The quiet failure is not a wrong approval but one that was right for a task and stayed in place. A grant created for ten calls and left running is a durable credential in all but name, and it is the shape Datadog found: "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions," a long-lived identity in a pipeline where no person approves a first use (Datadog, 2025).

Credentials outlive decisions at scale. Truffle Security reported that "11,908 live secrets were detected using TruffleHog in 400TB of web data" and that "2.76 million web pages contained live secrets," a population of keys created for a task and then forgotten (Truffle Security, 2025). A grant with no expiry feeds that population; a record is how an organization finds its own entries in it.

An unreviewed grant also widens what a successful injection collects. One approval on a cloud console can set up resources a team then keeps (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?), and the GPU instance walkthrough in How to Use AI Agents to Launch an EC2 GPU Instance shows five steps that commit an account to something it cannot take back, the calls a grant should bound. The same logic covers an admin login for a SaaS tool, where Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? describes an agent acting with more authority than the task needs.

What does a governed environment change?

A governed environment is a control class that acts before the model does. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so a credential on a settings page arrives as TOKEN_001 and stays TOKEN_001 for the run. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the policy and approves each consequential action, and every screen, action and approval is written to a record that exports to the organization's own monitoring.

For this page's question, the change is where the approval sits. The first use becomes a decision about terms the environment can enforce: the credential, the destination, the operations, the lifetime and the count are the grant, and later calls inside them reuse the token without a new prompt. A call outside them is a new decision, and the record shows which one it was. That is how one approval covers ten calls without becoming auto-approve: the difference is a written grant, not a missing prompt.

Its scope is the rendered page, not the terminal, the IDE, the local filesystem, direct API calls or MCP, so a credential used from a shell stays with the sandbox and credential store a team sets for that agent. Within the page, the control pairs substitution with approval: the model plans on tokens, the person approves the terms, and the value appears only where the person approved it. The export is what lets an auditor check the tenth call against those terms rather than a memory of the prompt.

Methodology and limitations

This page rests on five vendor documentation pages and one vendor press release, from Cursor, OpenAI, 1Password and Browserbase, Doppler and Teleport; two standards and regulatory sources, OWASP's non-human identity list and a law firm summary of FINRA's 2026 oversight report; two pieces of industry research, from Truffle Security and Datadog; and existing RedactSure research pages. Vendor statements are quoted from the pages cited, and research figures are reported as those posts state them. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page.

RedactSure did not test any of the named products hands-on. Where the page says a behavior is not described in the pages reviewed, the recorded pages for that product do not state it; the vendor may describe it elsewhere or add it in a later release. The five vendor pages describe approval defaults and credential custody separately, and none of them presents the two as a single grant. 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 covering ten calls, and not an organization.

Determinations about whether an approval flow, a grant or a credential-handling 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 credential and a test destination, repeated after each vendor release. A team should treat the grant's terms as the artifact under review and keep the exported record beside that test, so the next reviewer starts from evidence rather than from a description of a prompt.

What the record shows

The record points one way. The first use is the only moment when the terms of a credential's use can be set cheaply, and it is also the moment at which the vendor controls reviewed here are least specific: Cursor and OpenAI gate an action at a boundary, 1Password gates an access, Doppler scopes and expires the credential, and Teleport replaces a shared credential with an identity. A grant that carries an approver, a credential, a destination, a lifetime and a count turns those pieces into one decision a person can make and a reviewer can check. The remaining risk is scope, which is why the grant is reviewed rather than renewed. A reviewer can test this on one agent and one task by finding the grant that covers the first credential use, naming who approved its terms, and comparing them with what the eleventh call did.

Frequently asked questions

Does a coding agent need approval before using a credential for the first time?

Yes, if the credential reaches anything the organization cares about. The first use is where a person can still set the credential, the destination, the operations and the lifetime; after that, a call inside those terms spends a decision already made. Approval does not have to mean a prompt on every call. It means one decision, written down, that the environment enforces, and a review when the grant turns out wider than the task required.

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

Approving a credential is a custody decision: who holds it, where it is stored, and who can read it. Approving its use is an action decision: this agent, this destination, this operation, now. The first use combines the two, which is why it carries more weight than the tenth. A tool that stores a credential well and approves nothing has answered half the question, and one that prompts on every call without a stored scope has answered the other half.

Does one approval cover every later call?

Only inside the terms it set. A grant that names a destination, a set of operations, a lifetime and a count covers the calls that fit, and a call outside them is a new decision. The count matters as much as the scope: a grant for ten calls is a different object from a grant for a month. When a tool cannot state those terms, treat each call as a new decision whatever the interface suggests.

What should the first approval show the person?

The credential by name and version, the destination, the operations, the lifetime and the number of calls. It should also show what the agent read before the prompt appeared, because a page that rendered the credential in full has already exposed it to the model. A prompt that says only that an agent wants access gives a person nothing to decide with, and a person who cannot see the terms learns to approve without reading them. Keep those terms beside the grant.

Is auto-approve the answer to approval fatigue?

It is the answer that removes the decision. Auto-approve keeps a run moving and leaves the organization without a person, a scope or a record; the fatigue it avoids is real, and the cost of it lands at the first incident review. A scoped, expiring grant addresses the same fatigue by making the decision once, where the terms can still be set. The test is whether the tenth call rests on a written grant or on an absence of prompts.

Where does RedactSure fit for a coding agent?

The governed environment covers the rendered page, so its part of this question is the screen where a credential appears, such as a repository token settings page, and the approval a person gives before a value resolves at the destination. Work in the terminal, the IDE, the local filesystem, direct API calls and MCP stays outside that scope and remains with the sandbox and credential store a team configures, and every screen and approval is written to the AI Control Record. That record is the artifact a reviewer asks for.

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 Turns a First Credential Use Into One Approved Grant

A prompt before the tenth call repeats what the first approval settled, and a first approval covers a run only when its terms are enforced.

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

Before: the agent reads the credential string on the token settings page and carries it through ten calls. Inside: the page shows TOKEN_001, and the real value appears at the approved destination after the named person approves.

RedactSure is deploying now with enterprise and government customers. Datadog found 37 percent of the customers sending it CloudTrail logs using IAM users in GitHub Actions.

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

See it on your own workflow

The first use of a credential is when the scope of an agent's access gets decided. Bring a task that needs a new token and see, with test values, how that first use is approved and what the model reads. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.