Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Should I See Before Approving an Agent's Access to a Credential?

An approval request should name the agent, the service, the resource, the operation, the destination and the duration, plus the credential's name rather than its value. Ask for those seven fields on one slip, and treat a request that shows the credential itself as too vague to approve.

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

An approval arrives as a request to use a credential, and it usually arrives as a sentence: the agent needs the deployment key, or the token for the billing service. A sentence cannot be checked. The request becomes checkable when it is rendered as a slip with fixed fields: which agent is asking, which service it will call, which resource it will touch, which operation it will perform, where the request will go, how long the access lasts, and the name of the credential rather than its value. A reviewer who can read those fields in ten seconds can say yes, no, or narrower. A reviewer who is shown the credential is being asked to judge a value instead of a request, and the request is too vague to approve. The person approving should be able to grant, deny or narrow the request on those fields alone, and the value itself belongs off the slip. Two questions run through it: what the slip must show, and what the person reading it should never be shown. The two are related: a slip that carries the value has no room for the fields that make the decision easy. The example throughout is one record type: an approval slip for a single agent run, read in ten seconds.

Key findings

  • Arcade frames the approval question as "Can this agent, acting for this user, perform this action on this resource?", four of the fields a slip needs before the credential's name is added (Arcade, 2025).
  • Teleport's Agentic Identity Framework states that "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key," which makes the agent field checkable rather than a label (Teleport, 2026).
  • Composio's documentation states that "Credentials never pass through your app or the model, so it's safe to surface the link right in the chat," so the approver can see a connection and its state instead of a token (Composio, 2026).
  • Doppler tells teams to "Give every coding agent its own scoped, read-only, expiring set of credentials," which supplies scope, permission and duration in one line (Doppler, 2026).
  • A governed environment replaces the credential's value with a consistent token such as DEPLOY_001 before any model reads the approval screen, so the request the agent proposes names the credential and never carries it (What Is an AI Control Record?).
  • Real values resolve only at the approved destination at the moment of an approved action, so an approval grants one use of the credential and not a copy of it (What Is Supervised Delegation?).

What does a governed approval cover in a developer workspace?

The scope comes first because the title says approval and a request can arrive in more than one place. A governed browser environment covers what an agent reads and does on a rendered page: the approval slip, the settings page where a credential is pasted, the console that lists tokens and their scopes. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A request that arrives as a shell prompt is outside this page; one rendered on a workspace page is inside it.

The record type for this page is one approval slip for one agent run, read in ten seconds. An agent asks to use a deployment credential to read one repository's release settings on a hosting console. The slip is a page: the reviewer opens it, reads seven fields, and approves, narrows or denies. Nothing on the page asks the reviewer to read the credential.

That split decides which control is being asked about. In the terminal, the approval belongs to the sandbox and the credential store a team configured, and the durable top-level credential is the one to avoid: AWS states that it strongly recommends not creating access keys for the root user (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). On a rendered page, the page itself is where the fields can be fixed, where a value can be replaced with a token, and where the decision and its approver can be written down. The next sections stay on the page.

Which fields belong on an approval slip?

The slip answers six questions and names one thing. The six are which agent, which service, which resource, which operation, which destination, and how long. The one is the credential's name. A reviewer who can answer all seven has enough to approve one use.

The agent field is the one most often asserted, not checked. Okta's developer documentation says Okta for AI Agents "manages the registration, configuration, and lifecycle of AI agents," with agent status deciding whether an agent can authenticate or connect, which is where a slip's agent field can be verified against a registry rather than believed (RedactSure vs Okta: 2026 Comparison & Alternative). Microsoft's description of Agent 365, "the ability to observe, govern, and secure the growing number of agents within organizations," does not place the product relative to the model or the screen (RedactSure vs Microsoft Agent 365: 2026 Comparison & Alternative).

Field What it prevents Question the reviewer can answer
Agent A request from an agent nobody registered Is this the agent that was approved for this work?
Service A credential used somewhere it was never scoped Is this the system that holds the resource?
Resource A blanket grant over a whole account Which repository, record or bucket?
Operation Read access that quietly includes delete or write What will the agent do there?
Destination A value sent to a host the reviewer never saw Where does the request go?
Duration A one-hour task that leaves a durable credential When does the access end?
Credential name The value, displayed to a second person Which credential is this, and who owns it?

The service and resource fields say where the credential will be used. The operation field is where read-only shows up: a review task does not need delete rights.

The credential's name is the seventh field, with the account and its state. A scoped account rather than a super admin login is the starting point, since Google's security guidance states that the super admin account should be used only when needed (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?).

Why is the credential's value the wrong thing to show?

A value on an approval screen turns the reviewer into a second custodian of the credential. The value is in the page, and from there it can be copied into a ticket, captured in a screenshot, or pasted into another request.

Infisical's Agent Vault post states that "In short, the agent should not be trusted with direct access to any secrets," and explains why a proxy is not automatically enough: "In a traditional proxy, that tunnel remains opaque, simply forwarding encrypted traffic," and "To solve this, Agent Vault terminates TLS," so the proxy sees the plaintext even when the agent does not (Infisical, 2026). A slip that displays the value recreates the problem.

OWASP's non-human identity list defines NHI2 Secret Leakage as the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores" and names NHI5 as overprivileged identities (OWASP, 2025). What the reviewer needs is the credential's identity and state: name, owner, scopes, last rotation, and whether the connection is active. A stored credential can be requested by name and injected only when a person approves the access, the arrangement 1Password describes for browser agents, where "the AI agent and underlying LLM never need to see nor handle the credentials" (Does an AI Agent Need Access to Your Stored Credentials?). Naming a key without reading it is also the point of a managed API key workflow (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

What do the vendors themselves say?

The vendor pages reviewed describe how an agent is identified, how a credential is kept out of the agent's process, and how scope and duration are set. They do not describe an approval screen that displays the credential's value.

Teleport's Agentic Identity Framework grounds the agent field in cryptography: "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key." The same page marks most listed capabilities "In-progress" or "Not started" and does not give a certificate lifetime, so an approver should ask which parts are running (Teleport, 2026).

Composio documents a design in which the credential stays on the vendor's side: "Credentials never pass through your app or the model, so it's safe to surface the link right in the chat," and "If a refresh token is revoked or expires, the connection moves to EXPIRED and the user has to reconnect." The page does not describe physical storage of the credential and points to a separate token custody page (Composio, 2026).

Doppler's product page states "Give every coding agent its own scoped, read-only, expiring set of credentials," and says values are "Injected at runtime instead of written to a .env, so agents can't read, log, or commit them." The page does not say whether the agent can read the environment variables injected into its own process (Doppler, 2026).

Arcade asks the question the slip has to answer: "Can this agent, acting for this user, perform this action on this resource?" It does not explain token storage or refresh (Arcade, 2025).

Vendor What its documentation states What a buyer should verify before approving
Teleport Cryptographic agent identity; most capabilities marked "In-progress" or "Not started" Which capabilities are running, and what the audit record contains
Composio Credentials never pass through the app or the model; connection moves to EXPIRED Where the connected account is stored; the page points to a separate custody page
Doppler Scoped, read-only, expiring credentials injected at runtime Whether the agent can read the injected variables in its own process
Arcade Agent, user, action and resource as the authorization question Token storage, refresh, and any independent test of the design

How should a team test a slip before trusting it?

The test takes one agent, one task and one credential, and asks for a slip before anything runs. On a staging workspace, let the agent request a read of one repository's release settings, then read the slip without opening the credential. If any of the seven fields is missing, deny the request and ask for a new slip; a request that cannot supply them is the finding.

Willison's design-patterns post states that "These design patterns constrain the actions of agents to explicitly prevent them from solving arbitrary tasks," and that in one pattern "Agents can trigger tools, but cannot be exposed to or act on the responses from those tools," which is the difference between granting a use and handing over a credential (Willison, 2025).

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," which is why the approval has to be a reading of fields rather than a signature (Debevoise & Plimpton, 2026). A signature on a vague request records nothing to check.

Run the test twice: once with the fields, once with a slip that omits the destination and duration. The difference in what the reviewer can decide is the value of the slip. Then compare the approved slip with the run: the host the request reached, the operation it performed, and the time it ended. A slip that approved one host and a run that reached another is the failure the fields exist to catch.

What does a governed environment change?

A governed environment changes where the slip comes from. Instead of accepting the agent's prose description of its own request, the environment renders the request from its own record: which agent is registered for the task, which service and resource the policy covers, which operation was asked for, which destination is approved, and how long the grant runs.

The control class has four properties. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the agent that proposes the request sees DEPLOY_001 where the credential would sit. Real values resolve only at the approved destination, at the moment of an approved action, so the grant is one use rather than a copy. A named person confirms the tokenization policy and approves each consequential action, and an approval of a credential's use is one. 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, those properties change three things. The request stops being a sentence, because the environment will not render a slip with a missing field. The value stops being evidence, because the credential is named and its state is shown while the value stays in the store. The approval stops being a signature, because the person who approves is named in the record beside the fields that were on the screen.

It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP. A key exported into a shell session is the sandbox's problem, and a key pasted into a file is the file permission's problem. The approval screen governs what the agent reads on the rendered page and what the reviewer sees there, which is the moment this page is about.

Methodology and limitations

This page rests on five vendor documentation pages from Teleport, Composio, Infisical, Doppler and Arcade; OWASP's Top 10 Non-Human Identities Risks 2025; a law firm summary of FINRA's 2026 regulatory oversight report; a practitioner design post from Willison; and existing RedactSure research pages. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and a vendor's marketing page is cited for what it says, not for what it proves. The FINRA wording reaches this page through Debevoise & Plimpton's summary and is attributed there.

RedactSure did not test any named product hands-on for this page. The vendor pages describe identity, custody, scope and duration; an approval screen that displays the credential's value is not described in the pages reviewed, and the slip described here is assembled from the fields those pages do supply. Vendor features change, and the page carries its date; a release after that date should be treated as unreviewed until the test above is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, an approval slip for a single agent run on a staging workspace, and not an organization.

Determinations about whether an approval workflow 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 staging workspace, repeated after each change to the agent, the credential or the workspace.

What the record shows

The seven fields answer the title, and the value is what the answer must exclude. A slip names the agent that is asking, the service and resource it will touch, the operation, the destination and the duration, and the credential by name and state. The vendor pages reviewed supply those categories one at a time: identity from Teleport, a connection state from Composio, scope and expiry from Doppler, and the authorization question from Arcade. None of them needs the value on the screen, and a request that shows the value has displaced the fields that would make it decidable. A team without a governed environment can still ask for the fields on a page and deny the request that omits them. For one named agent and one task, ask for the next credential request in writing; the test passes when the reviewer can approve it without seeing the value.

Frequently asked questions

What should I see before approving an agent's access to a credential?

Seven things: the agent, the service, the resource, the operation, the destination, the duration, and the credential's name with its state. Together they describe a single use you can check in a few seconds, and each is a fact the requester should already know. If the request shows the credential's value, it has replaced the fields you need with the one thing you should not need, and it should be denied until it is restated with the fields the slip requires. All seven belong together.

Which of the seven fields can be left off?

None for a consequential request. A missing destination means the reviewer cannot say where the value would go; a missing duration means a one-hour task could leave a grant open for a quarter. A read-only request over one resource may need less detail about the resource than a write does, but the field still belongs. Ask for the slip again rather than filling the gaps with assumptions. The field belongs even when the agent is trusted.

Should the approver ever ask to see the credential's value?

No. The value does not help the decision and creates a second copy in a page, a screenshot or a ticket. What helps is the credential's owner, its scopes, its last rotation and whether the connection is active, all of which a vault or a hosting console already holds. A request that only becomes clear once the value is displayed is missing fields, not disclosure, and granting it moves the credential to a person who did not need it.

How long should an approval last?

Long enough for the task and no longer. A bounded run should carry an expiry measured in the task's own time, and a standing task should be split into grants rather than left open. The slip should state the end, and the record should show whether the grant ended when it said it would. An approval without a duration is a durable credential with a friendly name, and a reviewer who cannot see the end cannot judge the request it makes. Shorten the window instead.

What should happen when an agent cannot describe its request?

Deny it and ask for a new one. An agent that cannot name the service, resource, operation or destination has not established that it understands the task, and approving it moves the ambiguity to the person. If the agent cannot fill the slip, the environment can render the parts it knows from its record and mark the rest as missing, which is a clearer answer than a paragraph of prose. Keep the denial with the request it refused.

Does an approval slip replace a secret manager?

No. A secret manager stores and rotates the credential; the slip decides one use of it in front of a person. The two work together: the manager supplies the name, owner and state the slip shows, and the approval supplies the scope and the named decision the manager does not make. Keep the manager, and add the slip at the point where a request reaches a person, so the storage and the decision stay separate, and the record shows who decided and when. Keep that separation.

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 Vague Credential Request Into a Slip You Can Read

An approval is only as good as the request under it, and the identity systems and vaults reviewed decide which credentials exist without making requests readable.

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

Before: the request arrives with the credential in it, the model reads the value, and the approver is asked to look at the same value. Inside: the slip is rendered from the record, the agent sees DEPLOY_001, the approver sees the name, and the value reaches the console only after approval.

RedactSure is deploying now with enterprise and government customers. Teleport marks most of its framework's capabilities as not yet running.

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

See it on your own workflow

An approver should read a clear request about the action, not the credential itself. Bring a request your team approves today and see, with test values, what the approver and the agent each receive. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.