Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Who Should Hold the Key That Unlocks an Agent's Credentials?

The key should stay with the person who delegated the work, on a client or in a vault that person controls, while the agent holds only a reference to it. Ask each vendor who can decrypt the credential, how long the decrypt lasts, and who approved its last use.

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

Six designs for letting an agent use a credential appear in the documentation reviewed for this report, and each one answers a different question. One keeps the credential in a vendor's connected-account store, one encrypts it at rest, one hands it to a proxy that terminates TLS, one wraps it in a single-use token with a client-chosen lifetime, one ties it to a cryptographic workload identity, and one binds it to a process as an environment variable. Each design keeps a long-lived credential out of the agent's context. The custody question is what remains: which party could open the credential, what a breach of that party would yield, and who approved the use. This report works through the vendor documentation and the standards, tests short-lived tokens against custody, and closes on why the person who delegated the work is the right holder. It covers the rendered page an agent reads and acts on; the terminal, the IDE, the local filesystem, direct API calls and MCP sit outside that boundary, and a key that is safe on a settings page can be read from a shell a moment later. The distinction has direct consequences for a buyer signing a security review.

Key findings

  • 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 control that the same page marks mostly in progress (Teleport, 2026).
  • Composio documents that "Credentials never pass through your app or the model," while "Composio stores the resulting connected account" and the page does not describe how that store is encrypted (Composio, 2026).
  • HashiCorp's Vault documentation states that "A new single-use token is generated with the TTL supplied by the client," so the lease narrows the window while the client still decides how long it stays open (HashiCorp, 2026).
  • Truffle Security reported that "11,908 Live Secrets were detected using TruffleHog in 400TB of web data," with "2.76 Million Web Pages" holding live credentials (Truffle Security, 2025).
  • A key the model never reads cannot be pasted into a prompt, a log or a commit, because the agent works from a token that stands in for the value (How Do You Let an AI Agent Manage API Keys Without Reading Them?).
  • Real values resolve only at the approved destination, at the moment of an approved action, so the usable key stays with the party that can be named for it (Does an AI Agent Need Access to Your Stored Credentials?).

Where Does an Agent Touch a Credential, and What Does a Browser Control Cover?

A governed browser environment covers what the agent reads and does on a rendered page: a dashboard, a console, a settings page, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, and a report on credential custody has to say which path it is describing.

On a rendered settings page, the agent sees what the page shows. Cognition's Devin guide states that "In the browser, Devin types the value directly" and that "For shell commands, it binds secrets as environment variables whenever needed," two custody paths on the same agent (Cognition, 2026). The browser path puts the value in the model's context for the length of the task. The shell path puts it in the process environment, where the agent can read it if it chooses to.

The protocol path has its own rule. The Model Context Protocol guidance tells implementers to "Warn that MCP servers run with the same privileges as the client," which puts the token's reach in the server rather than in the model (Model Context Protocol, 2026). A server that accepts a broad token makes every tool it exposes a way to spend that token.

The guidance written for people applies with more force to an agent: a super admin account should be used only when it is needed, as Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? sets out. An agent holding the admin login holds every permission the account has.

The record type is a vendor console's token settings page. An agent asked to rotate a token opens the page, creates the token and reads the value the page renders. The value is now in the transcript, the vendor's log and the agent's next output. A credential that never appears on that page cannot leak from it.

Who Can Open the Credential If the Vendor Is Breached?

The useful test is not how a design behaves when every call succeeds but what an attacker carries away from the store. A design that keeps the decrypt key with the customer turns a vendor breach into a theft of ciphertext: the attacker gets files that name no usable credential. A design that keeps a live credential on the vendor side turns the same breach into a working login.

Composio's page states that "The user signs in on the hosted link and Composio stores the resulting connected account," so the vendor holds a live connection rather than a sealed copy (Composio, 2026).

Infisical's Agent Vault argues that "the agent should not be trusted with direct access to any secrets," and it puts the real credential at a proxy that "terminates TLS," which moves custody to whoever operates the proxy (Infisical, 2026). The proxy becomes the holder: its memory, its logs and its operator sit inside the trust boundary, and the page makes no claim of full prevention.

Identity-first programs govern who may act rather than what the model reads, which is necessary and not sufficient (RedactSure vs CyberArk: 2026 Comparison & Alternative). The simplest durable key, the root user's access key, is the one AWS tells customers not to create at all, as Is It Safe to Let an AI Agent Set Up Your Cloud Environment? notes.

Custody model What the record states What a buyer should verify
Vendor-held connection "Composio stores the resulting connected account" Whether the store is encrypted, who can decrypt it, what a breach exposes
Encrypted vendor store "All secrets are encrypted at rest" Who holds the decrypt key and whether the model sees the value on a page
TLS-terminating proxy The proxy "terminates TLS" with the real credential attached Whether the operator can read requests and what the proxy logs
Client-supplied wrap A single-use token with a TTL supplied by the client Default and maximum TTL, and who can mint a replacement
Workload identity An identity tied to where the agent runs Whether the identity outlives the task and how long a certificate lives

The table is the answer in miniature: only a key held on the customer's side keeps the opener out of a named party's hands.

What do the vendors themselves say?

Three vendor pages describe their custody arrangement directly, and each description stops at the same place: the arrangement, not what a breach of it would yield.

The same Teleport page claims "Comprehensive audit trails and behavior analysis for agent actions across infrastructure" while most of the capabilities around it are marked "In-progress" or "Not started" (Teleport, 2026). A capability marked in progress is a commitment, not a control a buyer can test today, and the page gives no certificate lifetime.

Infisical writes that "In a traditional proxy, that tunnel remains opaque, simply forwarding encrypted traffic," and that its own proxy removes that opacity (Infisical, 2026). Removing opacity is the point: a proxy that terminates TLS can attach the real credential, and it can also see every request it attaches the credential to. The page makes no claim that the design fully prevents credential exfiltration and offers no benchmark.

Cognition says a session secret is "scoped purely to the current session and are not saved for any future sessions," the narrowest custody window among the pages reviewed, and that "All secrets are encrypted at rest" (Cognition, 2026). Whether the model sees the value on a rendered page is not described in the pages reviewed.

That gap decides the page. An encrypted store protects the credential at rest and says nothing about what the model received when the credential was used. A buyer who stops at "encrypted at rest" has checked storage, not custody.

Does a Short-Lived Token Settle the Custody Question?

A short lease changes how long a stolen credential works, not who could open it.

HashiCorp's Vault page adds that "Vault currently does not provide signed response-wrapping tokens, as it provides little extra protection," so a wrapped token is still a bearer token for as long as it lives (HashiCorp, 2026). Response wrapping is a delivery mechanism: the client asks for a single-use token with a TTL it chooses and hands it to the agent, which unwraps the real credential into its own process.

The MCP guidance ties revocation to scope: "Poor scope design increases token compromise impact, elevates user friction, and obscures audit trails" (Model Context Protocol, 2026). Scope is a property of the token; custody is a property of the key that mints it. A tightly scoped token that a proxy can mint on demand is a durable capability wearing a short expiry.

OWASP's non-human identity list calls its second risk the "leakage of sensitive NHIs such as API keys, tokens, encryption keys" to unsanctioned stores, and names overprivileged identities as its fifth (OWASP, 2025). Both risks are about where the credential sits and what it can reach. Neither is solved by shortening its life.

Exposure control and expiry are different controls. Least exposure governs what an identity may do; it does not govern who can open the key or what the model read on the page where the key was used (What Is Least Exposure?). A lease is worth having. It is not the answer to who holds the key.

Why Does the Key Belong With the Person Who Delegated the Work?

The person who asked for the work is the person who can be named for it. Custody should follow accountability: the developer who started the agent, on the client they control or in a vault their organization operates, with the agent holding a reference to the credential rather than the credential itself.

The argument does not rest on trusting the agent. Veracode's research found that "GenAI models make the wrong choices nearly half the time, and it's not improving," which is why custody cannot rest on the agent handling a key carefully (Veracode, 2025). The design has to assume the agent will eventually use a credential in the wrong place and make that use harmless.

A tether is the same idea applied to authority. A tethered agent goes where its supervisor could go and does real work there, and it cannot slip the line back to the person who set it up, as What Is a Tethered Agent? describes. Custody is the other half of that line. The agent may act with the delegated authority; the key that unlocks the action stays with the delegator.

That is also what a security review should test. The classical questionnaire asks who may open the record; an agent review has to ask what the AI saw, where it could go, what it did and what an attacker gets, the shape of the twenty questions in What Should an AI Agent Security Review Cover?. Custody answers the last of those four directly: an attacker who takes the store gets nothing that opens it.

The practical form is a client-held key, a per-run grant and an approval by a named person. Each part is testable, and none requires the vendor to hold a usable credential.

What does a governed environment change?

The custody question is answered by where the usable value lives during the run. A governed environment keeps the value with the party that can be named for it and gives the agent a reference: a consistent token such as ACCT_001 or PATIENT_001, substituted before any model reads the screen, so the model works on the token and the work proceeds on it.

Three properties follow. First, the model never receives the real value, on any screen, in any step of the run. Second, the real value resolves only at the approved destination, at the moment of an approved action, and not before. Third, every consequential action has a named approver, a person who confirms the tokenization policy and approves the payment, the submission or the record change.

The record is the fourth property. Every screen as tokens, every action and every approval lands in an exported record, so the custody claim can be audited after the fact: who approved, what the model saw, where the value resolved. Without that record, custody is a statement of intent.

None of this requires the agent to be trusted, and none of it depends on the model behaving well. It depends on the substitution happening before the model reads and on the resolve happening only at the approved destination. That control covers the rendered page and stops at the terminal, the IDE, the local filesystem, direct API calls and MCP, where custody has to be supplied by a different mechanism.

Methodology and limitations

This report rests on vendor documentation from Teleport, Composio, Infisical, HashiCorp and Cognition, on the Model Context Protocol specification, on OWASP's non-human identity list, and on research releases from Veracode and Truffle Security. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. The vendor pages supply the quoted descriptions of each custody arrangement; the standard and the research supply the frame for what a leaked or overprivileged credential costs. Where a vendor labels a capability in progress, this report treats it as a statement of intent rather than a control in place. The page also cites RedactSure research pages for definitions and for the questions an agent review should ask. No page outside the Sources list was used, and no vendor was asked to comment.

No vendor was tested hands-on. Where this report says a behavior is not described, it means the pages reviewed do not describe it; that is not a finding that the vendor does not do it. Vendor features change, and each Sources line carries the date its page was read, so the page carries that date too. RedactSure statements describe current design, and RedactSure is deploying now with enterprise and government customers. The breach example describes a record type, not an organization, and the token settings page is likewise a record type rather than a named customer.

Determinations about whether a design satisfies a regulation, a framework or a contract belong to counsel, to assessors and to the organization's own security and compliance officers. This report describes what the pages say and what a buyer can test, and it should be read with the dates on the Sources entries in view.

What the record shows

The record points one way. Every design reviewed keeps the agent from carrying a long-lived credential in its context, and most of them leave a usable credential with a party that can be named: a connected-account store, a TLS-terminating proxy, an encrypted vendor vault or a client-minted lease. Shorter leases reduce the window and identity controls reduce reach, and neither answers what a breach of the holder would yield. The custody answer that survives the record is the one where the opener stays with the person who delegated the work, the agent works from a reference, and the resolve happens at an approved destination on a named approval. RedactSure describes that design for the rendered page. A buyer can run this test on one agent and one task by asking who could open the credential it used, from where, and on whose approval.

Frequently asked questions

Who should hold the key that unlocks an agent's credentials?

The person who delegated the work, on a client or in a vault their organization controls. That keeps the opener with the party who can be named for the action and asked to approve it. The agent should hold a reference, such as a token that stands in for the value, and the real value should resolve only at the destination the person approved. A vendor that stores a usable credential becomes a second holder, and a breach of that store is a breach of the credential.

Is a short-lived token as safe as a key the agent never holds?

No. A short lease limits how long a stolen token works, and it does not change who could open the credential or whether the agent ever held it. Vault's response wrapping issues a single-use token with a TTL the client chooses, and the agent still unwraps the real credential. Expiry is worth having because it shrinks the window. Custody is a different property: the value never reaches the agent at all.

What does a credential vault protect if the agent can still use the credential?

It protects the credential at rest and controls who may retrieve it. It does not control what happens after retrieval: once the value is injected into a process or typed into a page, the agent or the page can read it. Vaults reduce the number of copies and give an audit trail. The question to ask is whether the agent's task needs the value itself or only the authenticated request the value makes possible.

Can a vendor decrypt the credentials it stores for my agent?

Often it can, and the documentation usually does not say. Composio says it stores the connected account without describing how that store is encrypted. Cognition says credentials are encrypted at rest without describing who holds the decrypt key. A per-customer key narrows that blast radius. A store the vendor can open is a store a breach of the vendor can open. Ask who holds the key, whether it is per customer, and what the vendor can read without the customer's participation.

What should I ask before an agent creates an API token on a settings page?

Ask what the model receives when the token is created, since a settings page renders the new value in the clear. Ask whether the value is written to the transcript or the vendor's log, who can read either, and how the token is rotated if it leaks. Then ask whether the agent needs the value at all, or whether the page can show a reference and resolve the real token into the store the service reads.

Does a governed browser environment cover the terminal or MCP?

No. Its scope is what the agent reads and does on a rendered page: dashboards, consoles, settings pages and sign-up forms. The terminal, the IDE, the local filesystem, direct API calls and MCP sit outside it, and each needs its own control. That boundary matters because a custody claim made for a rendered page does not transfer to a command line or a protocol server, where the agent holds the value directly. Treat the boundary as part of the custody answer itself.

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 Keeps the Unlock Key With the Person Who Delegated the Work

Each design reviewed keeps a usable credential in a store, vault, proxy or client lease, and leaves open who could open it and what a breach would yield.

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

Before: an agent rotating a deploy key reads the new private key off the repository settings page. Inside the governed environment: the page renders KEY_014, the key resolves into the repository's store when the developer approves, and the record shows both.

RedactSure is deploying now with enterprise and government customers. Veracode found models choose wrongly nearly half the time.

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

See it on your own workflow

The key that unlocks an agent's credentials belongs with the person who delegated the work. Bring a deploy key rotation and see, with test values, where the key resolves and what the record shows. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.