Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is Zero-Knowledge Credential Handling for AI Agents?

A design in which the platform can route and enforce a credential without being able to read it: the value is encrypted to the developer's key and released into an enclave or an adapter, so neither the operator's console nor the model holds the plaintext. Ask which component can read the value, and when.

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

The phrase borrows its authority from cryptography, and the borrowing is loose. A credential is zero-knowledge here in one narrow sense: the platform that routes it, logs the run and enforces the policy cannot read it. The value is encrypted to a key the developer holds, released into an enclave or an adapter at the moment of use, and never rendered in plaintext where an operator console or the agent's model can see it.

Three shapes appear in vendor documentation: a wrapped single-use token that carries a credential to one request, a hosted connected account that acts for the user, and a proxy or gateway that substitutes the value after the model has written the request. Each shape leaves a different component able to read the plaintext, and that component is the answer to the only test the term supports: who could read it, and when.

The decision a buyer faces is whether a vendor ships a real design or a masked field, and the five vendors quoted below can be sorted on that question. The record throughout is one connector credential on a settings page in a platform operator's console, the entry an agent opens to rotate a provider key.

Key findings

  • The Teleport Agentic Identity Framework states that "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key," a design for what an agent may reach rather than for what its model reads, and marks most capabilities "In-progress" or "Not started" (Teleport, 2026).
  • 1Password's post on its OpenShell integration states that "Inside the sandbox, the agent sees placeholders rather than real credentials, including a placeholder for its model key," with the gateway holding the value (1Password, 2026).
  • A token substituted before any model reads the screen keeps the value out of the context for the whole run, so an agent that rotates a connector key on a settings page works with CRED_001 and the plaintext stays in the adapter (Enterprise Browser or Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, so the plaintext meets one request while the transcript keeps CRED_001 (What Is Least Exposure?).
  • Veracode's press release states that "GenAI models make the wrong choices nearly half the time, and it's not improving," which puts the code an agent writes around a credential in the same review (Veracode, 2025).

What does zero-knowledge credential handling mean for an AI agent?

The term names a property of the platform, not of the agent. The platform can route a credential to the service that needs it, enforce a policy on the request and record what happened, and still cannot read the value: the value is encrypted to a key the developer holds, released into an enclave or an adapter rather than a general-purpose store, and never written in plaintext to a log, a console or the page a model reads.

The test the term supports is a question about readers. Ask who could read the credential at each step and name the component: the operator who runs the console, the engineer with database access, the model that reads the screen, the adapter that terminates the request, the key holder. A vendor that says it cannot see your credentials has answered for one of those readers, and the documented designs differ on which reader they answer.

The term is about readability, not about trust: a platform that cannot read the value can still route it, revoke it and log the action.

One control class here sits at 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. The vendor designs quoted below sit elsewhere, in proxies, gateways and identity frameworks.

The record for this page is one connector credential on a settings page in a platform operator's console, the entry an agent opens when it rotates the provider key a connector uses. The field shows dots until someone clicks it, and the value is stored by reference. The question is what the model receives when the agent opens that page.

Which party can read the credential in each design?

The first design holds ciphertext and moves it under a wrapper. The platform stores the credential encrypted to the developer's key and issues a wrapping token that the client exchanges for the value. HashiCorp's Vault documentation states that "A new single-use token is generated with the TTL supplied by the client", a wrapper that carries a response to one request, and the page gives no default or maximum TTL (HashiCorp, 2026). The reader is whoever redeems the token, usually the workload, and the platform's role is to hand it over once.

The second terminates the connection. A proxy that only forwards encrypted traffic cannot insert a credential into a request, so the documented designs decrypt at the proxy, add the value and re-encrypt. Infisical's write-up states that "In a traditional proxy, that tunnel remains opaque, simply forwarding encrypted traffic", and describes terminating TLS so the proxy can insert the credential, which puts the plaintext in the proxy at the moment of the request (Infisical, 2026). The reader is the proxy operator, its logs and anyone who can change its rules.

The third and fourth shapes are variants of a custody decision. A hosted connection has the user sign in on the vendor's page, and the vendor holds and refreshes the account. A placeholder gateway holds the value and gives the model a stand-in for an approved host.

Design Who can read the plaintext What the model receives What to verify
Encrypted to the developer's key, opened by a wrapping token The workload that redeems the token Whatever the page renders Token lifetime, single use, and what the platform can decrypt
Proxy that terminates TLS The proxy, at the moment of the request The page content, not the credential Whether the proxy logs request bodies
Hosted connected account The vendor that holds the account The page content, not the credential Refresh and revocation behavior, and storage
Placeholder gateway The gateway, on a request to an approved host A placeholder Which hosts are approved, and who changes the list

What do the vendors themselves say?

Teleport's framework is the closest to an identity answer. It lists "Comprehensive audit trails and behavior analysis for agent actions across infrastructure", which is a record of what an agent did and not of what its model read (Teleport, 2026).

Composio's documentation states that "The user signs in on the hosted link and Composio stores the resulting connected account", so the vendor holds a token the model never touches (Composio, 2026). The same documentation states that "If a refresh token is revoked or expires, the connection moves to EXPIRED and the user has to reconnect", a lifecycle the platform runs without the model's involvement (Composio, 2026).

1Password's post states that "1Password stores them by reference rather than by value", which keeps the value out of the agent's context and leaves 1Password as the component that resolves it (1Password, 2026). Independent testing or audit of the integration is not described in the pages reviewed.

The same identity logic appears in privileged access: CyberArk's approach to agentic AI is described as "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).

Vendor What its documentation states What it leaves to another component
Teleport A cryptographic identity tied to where the agent runs, with audit trails for actions What the model reads; most capabilities marked in progress
Composio A hosted connection the vendor stores and refreshes Encryption and storage, delegated to a token custody page
1Password A gateway that swaps a placeholder on an approved host Independent testing of the integration
HashiCorp A single-use wrapper token with a client-supplied TTL The value the token opens, and who can decrypt it
Infisical A proxy that terminates TLS to insert the credential The plaintext in the proxy at request time

Where does the borrowed term stop being true?

The term answers one question and leaves three others.

Authority is the first gap. A tether, in the sense that What Is a Tethered Agent? uses the word, describes authority rather than capability: the agent goes where its supervisor could go and does real work there. Google's guidance for Workspace administrators holds that "the super admin account should be used only when needed", a rule for people that applies with more force to an agent (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?). The design can be zero-knowledge and still leave every page visible.

Action is the second gap. Five of the steps in a cloud account launch commit the account to something you cannot take back, and those five stop for approval (How to Use AI Agents to Launch an EC2 GPU Instance). An approval gate governs what the agent does with a credential and not the value it read first.

Read-side controls are the third gap. Willison writes that "These design patterns constrain the actions of agents to explicitly prevent them from solving arbitrary tasks", which limits what a run may do and not what it may read (Willison, 2025). One pattern holds that "Agents can trigger tools, but cannot be exposed to or act on the responses from those tools", a read-side limit rather than a custody design (Willison, 2025). Outside its scope: trust in the enclave operator, the endpoint, and the injection the model meets on a permitted page.

What breaks a zero-knowledge design in practice?

Three failures show up in the record.

The approval step is forgeable. OWASP's attack page describes a class of attack that "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations", which a tokenized screen does not prevent (OWASP Foundation, n.d.). The model can hold a token and the person can still approve the wrong action.

The record can misattribute the actor. AWS's guidance states that "audit logs attribute every action unambiguously to either an agent or a human actor", which is what a record needs before it can answer who used a credential (AWS, 2026). An agent acting under the developer's own login leaves a record in the developer's name.

The masking that exists may be off. Salesforce's Trailhead states that "data masking for LLMs is currently disabled for agents", which leaves the screen itself as the exposure (Which Enterprise AI Agents Can Work on Screens With PII Today, and What Does Each One Read?). Leaked credentials arrive in bulk: How Do You Let an AI Agent Manage API Keys Without Reading Them? counts "28,649,024 new secrets exposed in public GitHub commits across 2025".

Each failure is about a reader the custody design did not name: the person at the dialog, the auditor reading the log, the agent reading the screen.

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so a credential field shows CRED_001 and the model works on that token. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, and a credential rotation or a payment 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 it changes which reader is answered. The designs above answer the operator, the log and the vendor; the governed environment answers the model. The page the agent reads is rendered with tokens, so a value the platform could not read is also a value the model cannot read, and the plaintext meets one destination after a person approves it.

It also changes what a successful injection collects. A model holding CRED_001 can still be induced to act, the action still requires approval, and the record shows which page rendered which token. What it cannot collect is the credential, because the environment never rendered it to the model.

The record is the second change. An audit log says who did what; a record of screens as tokens says what the model saw before it acted, the half the custody designs above leave unrecorded.

Its scope is the rendered page, and it does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP.

Methodology and limitations

This page rests on five vendor documentation pages, an OWASP community attack page, AWS Well-Architected guidance, one practitioner analysis of agent design patterns, one vendor press release reporting a research result, and existing RedactSure research pages. The RedactSure pages linked in the body supply the least-exposure definition and the API key account, cited as design statements rather than as independent evidence. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quotations are given in the wording of the page that states them, and the Veracode figures are cited as that release reports them.

RedactSure did not test any of the named products hands-on. Where this page says a behavior is not described in the pages reviewed, it means the recorded facts for that vendor page do not cover it, not that the vendor does not do the thing. Vendor features change, and the page carries its date; a release after that date is unreviewed until a reader repeats the check. Statements about RedactSure describe current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, one connector credential on a settings page in a platform operator's console, and not an organization. Nothing on this page was measured on a live account.

Determinations about whether a credential-handling design meets a contractual, statutory or regulatory 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 its own connector, repeated after each vendor release, with the record of what the model received kept beside it.

What the record shows

The documented designs answer the first reader and leave the others. A wrapping token, a terminating proxy, a hosted connection and a placeholder gateway each keep the plaintext from the operator, the log or the vendor, and each resolves the value in a component the design names. None of them governs what a model reads on the page where the credential is displayed, and none of them turns an approval dialog into evidence. A buyer who asks only whether the platform can read the credential will get a true answer and an incomplete one. RedactSure's environment sits on that missing step, at the render layer. To test a design, a buyer should name one agent and one task, ask which component could read the credential at each step, and write down what the model received on the settings page where the credential lives.

Frequently asked questions

What is zero-knowledge credential handling for an AI agent?

A design in which the platform can route a credential, enforce policy on its use and record what happened without being able to read the value. The value is encrypted to a key the developer holds and released into an enclave or adapter at the moment of use. The term is narrower than it sounds: it describes what the platform can read, not what the agent's model reads on a page. Ask which component could read the plaintext at each step, and write the answer down for the run.

Is a masked field the same thing?

No. A masked field hides the value from a person looking at the screen and often reveals it on a click, and the browser still holds the real value in order to submit it. A zero-knowledge design keeps the platform from holding the plaintext at all, or releases it only into a component that terminates the request. Check whether the mask is a display setting or a boundary, and what the page returns when the field is revealed. A display setting is not a boundary.

Which component reads the credential in a proxy design?

The proxy. A proxy that forwards encrypted traffic without terminating it cannot insert a credential into a request, so the documented designs terminate TLS and add the value there. That places the plaintext in the proxy at the moment of the request, which is a real trust boundary: the proxy operator, its logs and its configuration can reach the value. Ask whether the proxy records request bodies and who can change its rules. Get the logging configuration in writing.

Does zero-knowledge handling stop prompt injection?

No. It changes what an injection collects. If the model never reads the plaintext, an injected instruction can still act with the credential through the adapter, and it can still misdescribe an approval. The failure is bounded by what the model can see and what the approver can check, not removed. Run a test with an injected page and read the record for what the model held before it acted. A token is still an authority that injection can use.

What should a buyer ask a vendor that claims it?

Which component can read the plaintext, at which step, and who operates that component. Whether the value is encrypted to a key the buyer holds and what the vendor can decrypt without it. What the model receives on the page where the credential is displayed. What the record shows about reads as well as actions, and who approved each use. An answer that covers only storage leaves the moment of use open. Ask for the record, not the architecture diagram.

Can an agent rotate a credential it cannot read?

Yes, if the rotation runs through a connector or an adapter that holds the value. The agent requests the rotation, the adapter performs it against the provider, and the model sees a token or a confirmation rather than the new credential. The limit is the control plane: an agent that can rotate a credential can usually revoke one too, so the approval belongs on the action rather than on the reading. The approval is the control, not the rotation.

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 a Connector Credential Out of the Model

The designs above keep the plaintext from the operator, the log and the vendor, yet each still resolves the value on a page the model reads.

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

Before: the agent opens the connector settings page, clicks the masked field and copies the provider key into the rotation request. Inside the governed environment the page renders CRED_001, and the real key reaches the connector's approved endpoint after a named operator approves.

RedactSure is deploying now with enterprise and government customers. Veracode reports that GenAI models make the wrong choices nearly half the time.

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

See it on your own workflow

Rotating a connector key should not require the model to hold the key it is rotating. Bring a connector rotation your team performs and see, with test values, what the model reads in the masked field. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.