Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can a Vendor Read Credentials Encrypted to My Own Key?

Not from the stored ciphertext, if the private key never leaves your side, but that is the at-rest half: a service that must act with the credential has to decrypt it or receive it. Ask each vendor what it would produce under subpoena, ciphertext or plaintext, and which process could decrypt it.

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

A credential encrypted to a key you hold is unreadable to anyone without the private half. That is the property behind bring-your-own-key encryption, and it is true of the file at rest. It is not the whole question. A vendor that must rotate the credential, inject it into a request or hand it to an agent needs the plaintext at that moment, and the documented designs differ on where that moment happens. One holds the credential and issues a short-lived token. One stores a connected account and acts for the user. One terminates TLS so a proxy can insert the credential. Each keeps something out of the model's reach, and each leaves a component that can read the value. The useful question for a buyer is narrower than whether the data is encrypted: which artifact would the vendor produce if compelled, and which process held the plaintext when the credential was used. This page separates the at-rest claim from the at-use claim, works through one record type, a subpoena for ciphertext, and ends with the questions to put to a vendor in writing. Does a Confidential VM Hide Sensitive Data From AI? covers the enclave claim, where the host cannot inspect the machine but the workload inside still receives the data.

Key findings

  • HashiCorp's tutorial states that "Token lifetime is reduced from days or weeks to minutes" and that "the agent receives a token that is read-only, repo-only, scoped to a single secret, and short-lived," a scope that still leaves Vault holding the credential (HashiCorp, Secure, 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," while "Composio stores the resulting connected account," so the model is kept out and the vendor is not (Composio, 2026).
  • Infisical's write-up states that "the agent should not be trusted with direct access to any secrets" and that "To solve this, Agent Vault terminates TLS," which removes the credential from the agent and puts the plaintext in the proxy (Infisical, 2026).
  • A token substituted before any model reads the screen keeps a credential out of the model's context, so an agent working a repository settings page holds DEPLOY_KEY_001 and never the key (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, so the key reaches the one form a named person approved and not the transcript (What Is Least Exposure?).

What does encrypting a credential to my own key protect?

Encrypting a credential to your own key makes the ciphertext portable and useless. Only the holder of the private key can turn the bytes back into a password, a token or a key, so the stored artifact can sit on a vendor's disk without giving the vendor the credential. That is what bring-your-own-key encryption buys, and it is a real defense against a stolen database and a demand for the stored bytes. It holds while the private key stays outside the vendor's reach.

The moment of use is a different question, and it is the one the title is really asking. A service that must rotate the credential, inject it into a request or hand it to an agent needs the plaintext then. The designs below answer that need in three shapes: a vault that keeps the credential and issues a scoped token, a connected account the vendor holds, and a proxy that terminates TLS to insert the credential.

The line between a credential store and a screen is worth stating. A governed browser environment covers what an agent reads and does on a rendered page, including dashboards, consoles, settings pages and sign-up forms, and it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A key service sits below that line.

The record this page works through is a subpoena for ciphertext: a legal demand served on a vendor for the encrypted contents of a repository's credential store, the deploy keys and CI tokens a team keeps there. The demand asks for an artifact, not an explanation, which makes it a clean test of custody. A vault also protects only what was put in it, and "It has no entry for the records already on the screen when the agent arrives" (Secure VM, Confidential VM or Render-Layer Controls?).

Where does the private key have to stay?

The private key can sit with the customer in a hardware module or a key service the vendor cannot call, in the vendor's key service under a customer-managed key, or with the vendor outright. The first keeps the stored bytes out of the vendor's reach, the second until a policy allows an unwrap, and the third not at all.

HashiCorp's Vault documentation describes response wrapping as a way to deliver a credential: "Vault includes a feature called response wrapping," where "A new single-use token is generated with the TTL supplied by the client." Wrapping governs delivery, not custody: Vault still holds the credential the wrapper points to (HashiCorp, Response, 2026).

HashiCorp's tutorial shows the same gap for agent permissions. The wrapper script "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent," so the raw token sits in the agent's environment, and the page does not say whether the agent can read it (HashiCorp, Secure, 2026). Teleport removes the shared credential instead: "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key," an identity design that leaves the certificate authority able to mint the workload's identity (Teleport, 2026).

The durable key is the one to retire first. AWS strongly recommends not creating access keys for the root user, which rules out a simple permanent credential for an agent or a vendor (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). A decryption key is the same asset: if it exists, it can be copied, escrowed or subpoenaed.

What do the vendors themselves say?

Three vendor pages bear on the title, and each places the plaintext somewhere different at the moment of use.

HashiCorp's tutorial scopes the token tightly: "the agent receives a token that is read-only, repo-only, scoped to a single secret, and short-lived," which limits what a stolen token opens without changing who holds the credential (HashiCorp, Secure, 2026).

Composio keeps credentials out of the application and the model: "Credentials never pass through your app or the model, so it's safe to surface the link right in the chat," while "Composio stores the resulting connected account," so the vendor is the custodian, and revocation limits the life of that account, not who can read it while active: "If a refresh token is revoked or expires, the connection moves to EXPIRED and the user has to reconnect" (Composio, 2026).

Infisical argues that "the agent should not be trusted with direct access to any secrets," and describes a proxy that "terminates TLS" to insert the credential, and it notes that "In a traditional proxy, that tunnel remains opaque, simply forwarding encrypted traffic," the limit the design removes (Infisical, 2026).

Vendor What its documentation states Where the plaintext sits at the moment of use What a buyer should verify
HashiCorp Vault A single-use response-wrapping token with a client-supplied TTL, and agent tokens scoped to one credential In Vault, which issues the token; the agent process holds the token Whether the agent can read the exported token, and the TTL you set
Composio Credentials never pass through the app or the model; the vendor stores the connected account With Composio, which acts for the user How the connected account is encrypted and stored, and what an export contains
Infisical Agent Vault The agent has no direct credential access; the proxy terminates TLS In the proxy, at the moment it injects the credential Whether the proxy is self-hosted or vendor-run, and what its logs keep

The three pages describe scope, custody and termination. None claims that the vendor cannot read a credential it must use. The question is which design the vendor runs, and what its record would show.

What would the vendor hand over under a subpoena?

A subpoena for ciphertext is narrow with a broad reach. It names a vendor, a customer and a store, and asks for that store's contents over a date range. The artifact the vendor produces is the answer to the title.

Three artifacts are possible. If the private key is the customer's and no escrow exists, the vendor can produce ciphertext and the wrapped data keys, and state that it cannot decrypt them. If the vendor holds the key or can obtain an unwrap through a support process, it can produce plaintext, or perform a decryption for the demand. If a proxy handles the credential at use, the artifact may include request logs in which the credential appears.

An approval is a control on the action, not on the artifact. OWASP's attack catalogue describes an attack that "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations," so an approval is evidence only when the record shows what the approver saw (OWASP Foundation, n.d.). AWS states that "audit logs attribute every action unambiguously to either an agent or a human actor," which settles who acted and not what the actor could read (AWS, 2026).

The technical record matters as much as the legal one. A forged approval, a log that names an actor without recording what was read, and a token in an environment variable are three gaps a demand can reach.

The volume makes the point. GitGuardian's count, as reported by Help Net Security, found "28,649,024 new secrets exposed in public GitHub commits across 2025" (How Do You Let an AI Agent Manage API Keys Without Reading Them?). A repository's credential store is that kind of asset.

Which designs keep the vendor out, and which only move the trust?

The designs answer different questions, and each leaves a different party holding the plaintext. A customer-held key keeps the stored bytes out of the vendor's reach and says nothing about what the service sees at use. A vendor vault with scoped tokens limits the blast radius of a leaked token and not whether the vendor can read the store. A TLS-terminating proxy keeps the credential out of the agent's context and puts it in the proxy.

The enclave is the design most often offered as vendor-blindness. Confidential computing "protects a workload from its host," so "the cloud operator cannot inspect the machine," but in "every one of these designs the model receives the user's data in full" (Does a Confidential VM Hide Sensitive Data From AI?). The guarantee is about the provider's eyes, not the model's.

Willison's design patterns separate the component that reads untrusted content from the component that acts. They state that "These design patterns constrain the actions of agents to explicitly prevent them from solving arbitrary tasks" and that "Agents can trigger tools, but cannot be exposed to or act on the responses from those tools" (Willison, 2025).

A gateway handles credentials for traffic routed through it, and an enterprise browser governs human data movement; neither is key custody (RedactSure vs AI Gateways: 2026 Comparison & Alternative; Enterprise Browser or Render-Layer Tokenization?).

None of these designs is wrong. The custody design decides what a vendor can produce; the rendering design decides what a model can repeat; the record decides whether either claim can be checked.

What does a governed environment change?

A governed environment is a control class, not a product. Values chosen by policy become consistent tokens before any model reads the screen, so the model works on placeholders such as DEPLOY_KEY_001. Real values resolve only at the approved destination, at the moment of an approved action. A named person 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 monitoring.

For this page's question, the class adds two properties to the custody designs above. Key custody decides what a subpoena can produce; render-layer substitution decides what the model can repeat. The record decides whether anyone can check either claim. A vendor can hold the key and still never render the plaintext to the model; a vendor can hold no key and still let a model read a value typed on a page.

The record is the part most often missing. A statement that an action was approved is not a record of what the approver saw, and a log that names the actor is not a log of what the actor read. The governed record carries the screen as tokens, the action, the destination where a real value resolved, and the name of the person who approved it.

The scope is the rendered page. A credential store, a terminal, an API call and an MCP server sit outside it. A token substituted before the model reads the page keeps the value out of the model's context even when the vault's operator can decrypt what it stores (What Is Render-Layer Tokenization?). That is the property the class contributes: not vendor-blindness at rest, which is a key question, but model-blindness at use, which is a rendering question.

Methodology and limitations

This page rests on vendor documentation from HashiCorp, Teleport, Composio and Infisical, standards and official guidance from OWASP and AWS, one practitioner analysis from Willison, and existing RedactSure research. The vendor pages supply the custody designs, the OWASP and AWS pages supply the approval and audit evidence, and the practitioner analysis supplies the architectural separation. 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 no vendor was asked to answer a subpoena for this page.

RedactSure did not test the named products. "Not described in the pages reviewed" means the recorded facts for that page do not cover the point; it does not mean the vendor does not do it. Vendor features change, and the page carries its date, so a release after that date is unreviewed until the test below 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, a subpoena for ciphertext served on a vendor, and not an organization.

Determinations about whether a custody design meets a contractual, regulatory or legal requirement belong to counsel, assessors and the organization's own security and compliance officers. A subpoena is answered under law, and the lawful scope of a demand, the vendor's obligations and the customer's notice rights are legal questions rather than security questions. Nothing here replaces a legal review of the vendor's key custody or a test of the artifact the vendor would produce.

What the record shows

The at-rest answer and the at-use answer are different, and the title conflates them. A key you hold keeps the stored ciphertext unreadable, a real defense against a demand for the bytes; it does not keep a service from decrypting the credential when it must act, and the designs reviewed place that moment in a vault, a connected account, a proxy or an enclave. An enclave narrows who can inspect the machine without changing what the workload inside receives. The control that closes the gap keeps the plaintext out of the model and into a record: tokens before the screen is read, the real value only at the destination, and an approver with a name. RedactSure's environment is built on that control. For a buyer, the useful test goes to one named vendor in writing, for one credential and one action, asking which artifact the vendor would produce under subpoena and which component held the plaintext when it ran.

Frequently asked questions

Can a vendor read credentials encrypted to my own key?

Not the stored ciphertext, if the private key never leaves your side and is not escrowed with the vendor. The vendor holds bytes it cannot decrypt, and a demand for the stored artifact produces bytes. The answer changes at the moment of use: a service that must rotate or inject the credential needs the plaintext, so the question becomes which process decrypts it and whether that process belongs to the vendor. Ask for that artifact, and ask who would sign the answer.

What does bring-your-own-key encryption actually change?

It changes who holds the key that unwraps the data, not who can use the credential. With a customer-held key, the vendor stores ciphertext and the customer's key service performs the unwrap. If the vendor can request an unwrap through a support process, or the key is escrowed, the vendor can read the credential when it needs to. The design is only as strong as the policy on who may ask the key service for an unwrap and what record that request leaves. Read that policy, not the marketing page.

Where does the plaintext sit in a short-lived token design?

With the vault. A scoped, short-lived token limits what the agent can open and for how long, and it does not move the credential out of the vault that issues it. The agent's environment may hold the token itself, and a wrapper script that exports the token as an environment variable leaves it there. The token reduces the blast radius of a leak; it does not make the vendor blind to the credential the token opens.

Can a hardware enclave keep the vendor from reading the plaintext?

It can keep the host and the cloud operator from inspecting the machine's memory, which is a real limit on who can look. It does not change what the workload inside receives: the model or service in the enclave still works on decrypted data. An enclave answers who besides the workload can see the data, not what the workload itself sees. Ask what the workload may do with the plaintext once it has it.

What should I ask a vendor before accepting a subpoena answer?

Ask for the exact artifact the vendor would produce: ciphertext, a wrapped data key or a plaintext export. Ask which role can decrypt, whether a support engineer can request an unwrap, and whether the request is logged with a name. Ask whether plaintext appears in application logs, proxy logs or memory dumps, because a demand reaches those too. A written answer that names the artifact and the role is worth more than a statement that the data is encrypted.

Does a TLS-terminating proxy keep the credential away from the vendor?

It keeps the credential away from the agent and puts it in the proxy. A proxy that forwards encrypted traffic cannot insert a credential into a request, so a credential-injecting proxy terminates TLS, reads the request and writes the credential in. That is the design's function and its exposure: the proxy operator, its logs and its memory are places the plaintext exists. Whether that is acceptable depends on who runs the proxy and what it records.

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 Plaintext Out of Reach at the Moment of Use

An encrypted vault protects stored values until the service must use one, and scoped tokens, connected accounts, terminating proxies and enclaves each leave a component holding the plaintext.

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

Before: the agent opens a repository's deploy-key settings page, reads the key as the page renders it, and keeps the value in context for the rest of the run. Inside: the page renders DEPLOY_KEY_001, the model works on the token, and the real key resolves only at the destination after a named person approves the rotation.

RedactSure is deploying now with enterprise and government customers. HashiCorp's tutorial exports a raw Vault token into the agent's environment.

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

See it on your own workflow

Encryption to your key protects the stored copy, so the open question is where the plaintext appears in use. Bring a deploy key rotation and see, with test values, what the model reads and where the key resolves. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.