Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Does It Mean to Encrypt a Credential to the Developer's Public Key?

Encrypting a credential to a developer's public key means encrypting it with that public key so that only the matching private key can decrypt it, and every relay in between holds ciphertext. Check who holds the private key, what authorizes its use, and whether the agent read the plaintext before encryption.

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

A public key works as a one-way address: anyone can use it to lock a value, and only the private key that matches it can open the result. A credential encrypted that way can pass through a vendor, an agent and a log without any of them holding the plaintext, which is why the phrase sounds like a complete answer. A key pair is a lock and a key, and it sets no policy about what may be read. The encryption covers the blob. It does not cover the moment the agent reads the credential on a rendered page or types it into a form, and it says nothing about who can call the private key or what they may do with the result once it is open. Those three moments are where the questions in this page sit.

The page starts with scope, then works one record type throughout: a captured token that a run stores as ciphertext. The key pair governs the stored copy, while the exposure sits where the plaintext exists before encryption and with whoever can use the private key. A team should therefore look for a control that governs the reading rather than the file.

Key findings

  • Cognition's Devin guide states that credentials are "scoped purely to the current session and are not saved for any future sessions" and that "All secrets are encrypted at rest," while its browser path has Devin type the value directly, so the plaintext is on the page before storage encryption applies (Cognition, 2026).
  • OpenAI's Codex cloud page, marked Legacy, states that credentials "are stored with an additional layer of encryption and are only decrypted for task execution," which is vendor-side encryption at rest and not encryption to a key the developer holds (OpenAI, 2026).
  • Infisical's Agent Vault post states that "the agent should not be trusted with direct access to any secrets" and that "Agent Vault terminates TLS," which moves custody to a proxy rather than to a key the developer holds (Infisical, 2026).
  • Truffle Security reports that "11,908 Live Secrets were detected using TruffleHog in 400TB of web data," the plaintext population that encryption to a key is meant to keep a captured credential out of (Truffle Security, 2025).
  • A governed environment replaces a value with a consistent token before any model reads the screen, so an agent working a token field holds a placeholder and never the string (What Is Least Exposure?).
  • Real values resolve only at the approved destination at the moment of an approved action, so a decrypted credential reaches the one form the approver named and not the transcript (What Is a Tethered Agent?).

What does a browser environment cover when a credential is encrypted to a key?

A browser environment governs what an agent reads and does on a rendered page: a dashboard, a console, a token settings page, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An agent that encrypts a credential inside a shell script with its own key pair is outside the page; an agent that reads the credential while filling a form is inside it, and the reading happens before any ciphertext exists.

Encryption is a storage and transport control. It runs after a value has been captured, and it protects the captured copy rather than the capture. On a rendered page the capture is a render: the field is populated, the model receives the screen, and the value is in the context whether or not anything is written to disk afterward. A policy that covers the terminal but not the browser leaves the browser as the open path.

The worked record for this page is a captured token: a run collects an access token from a token settings page and stores it as ciphertext. The page is rendered; the store is encrypted. The question is what the agent held at each step, and the answer is not in the key pair.

A login handed to an agent is durable authority of the kind Google's Workspace guidance says a super admin should use only when needed (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?). Encryption to a public key narrows who can open the stored value, not who can reach the page that shows it. The same test applies to API keys a run manages: what matters is what the model reads, not only where the key is stored (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

How does a key pair turn a captured credential into ciphertext?

A key pair has two halves. The public key can be published, pasted into a configuration or handed to a service, and anything encrypted with it can be opened only by the private key that matches. The private key stays where its owner puts it. The sender needs no shared password, and the relay needs no access to the plaintext, which is the property the phrase points at.

For a captured credential the flow is short. The run takes the value, encrypts it to the developer's public key and stores the result. A vendor holding the store, an agent holding the run or a log holding the bytes sees an encrypted blob. At use the private key decrypts, and the plaintext appears at whatever destination the key holder chooses. Everything the phrase promises sits in that last clause.

The table separates what the key pair answers from what it leaves open.

Question What encryption to a public key answers What it leaves open
Who can read the stored value? Only the holder of the matching private key Whether that holder is one person, a shared device or a process acting for an agent
What does the vendor hold? Ciphertext, if the implementation is sound Whether the vendor can ask the key holder's client to decrypt
What did the agent hold? The ciphertext it stored What it read on the page before encryption
Where does the value go next? Nowhere until decryption What the destination does with the plaintext after it opens
What record exists? None by itself Who decrypted, when, and for which action

The key pair is necessary and not sufficient. It does not say who may invoke the private key, it does not produce an audit trail, and it does not govern the render that preceded it. A credential can be encrypted to a developer's key with sound cryptography and still have been read by a model two seconds earlier.

That is why the custody question comes before the algorithm. Devin's guide scopes credentials to the organization, a person, a repository or a session, and states that "All secrets are encrypted at rest," a storage control the vendor operates (Cognition, 2026). The scope limits how long a value lasts; it does not change what the model read. Cloud deployment is the same question on a larger canvas; the walkthrough for How to Use AI Agents to Deploy Azure GPU Virtual Machines puts a run behind a console.

What do the vendors themselves say?

Five vendor pages reviewed here describe how they hold or reuse credentials, and none describes encrypting a captured credential to a developer's own public key. They are cited for the custody patterns they record and for the limits those patterns carry.

Devin's browser path is the closest to a rendered page. The guide says that "In the browser, Devin types the value directly," which puts the plaintext on the page before any store sees it, and whether the model sees that value is not described in the pages reviewed (Cognition, 2026).

OpenAI's Codex cloud page, marked Legacy, states that credentials "are only available to setup scripts" and "are removed before the agent phase starts," a design that keeps a credential out of the agent phase but not out of a rendered page (OpenAI, 2026). The same page states that "Environment variables are set for the full duration of the chat (including setup scripts and the agent phase)," so a value placed in a variable rather than a secret is in the agent's reach for the whole task (OpenAI, 2026).

Infisical's post states that in a traditional proxy the tunnel "remains opaque, simply forwarding encrypted traffic," before "Agent Vault terminates TLS," placing custody in a proxy the vendor operates (Infisical, 2026).

Vendor What its documentation records What a buyer should verify
Cognition, Devin Session-scoped credentials; "All secrets are encrypted at rest"; in the browser Devin types the value directly Whether the model sees the typed value; which key opens the stored copy
OpenAI, Codex Cloud Credentials available to setup scripts and decrypted for task execution; environment variables set for the full chat Whether the key is customer-held; what the agent phase can read
Browserbase Reuse saved authentication state; store cookies, session tokens and local storage in Contexts How usernames and passwords are stored; whether a login outlives the run
Infisical, Agent Vault The agent should not have direct access to credentials; the proxy terminates TLS Whether the proxy reads plaintext at the destination
Teleport Cryptographic identity for the agent, not a shared API key; audit trails for agent actions Whether identity covers a captured credential; most capabilities are marked in progress

Where does the plaintext exist before it becomes ciphertext?

Every encryption starts with a value someone could read, and an agent run has three such places. The first is the rendered page: a token settings page draws the token, the agent reads it, and the model receives it. The second is the form the agent fills: a field populated from a store still passes through the page. The third is the process: an environment variable or a value the agent writes into its own workspace.

Browserbase's guidance shows the alternative to holding a password: "Log in once, then reuse the saved authentication state," with cookies and session tokens stored in Contexts, which keeps a live login instead of a decryptable credential and does not explain how the password itself is stored (Browserbase, 2026).

Truffle Security reports that "2.76 Million Web Pages contained live secrets," evidence of scale in public data rather than of any one model's training set (Truffle Security, 2025).

The code that handles the plaintext is another exposure. Veracode's research release states that "GenAI models make the wrong choices nearly half the time, and it's not improving," a reason to keep the decrypt-and-use step out of agent-written code where it can be avoided (Veracode, 2025).

For the record type used here, a captured token passes through a token settings page before it is stored as ciphertext, and that page is the step the key pair cannot govern. A sign-up form has the same shape: the card field is rendered before any storage decision, as Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? sets out.

Who can use the private key, and what does that authorize?

Encryption to a public key moves the decision to the private key holder, which is a question about people and processes, not mathematics. If a person unlocks a laptop key for each use, the authorization is a human act. If the key sits in an agent's environment, the agent can decrypt anything it captured, and the encryption has become a storage format. If a vendor holds the key, the vendor can decrypt on request, and the phrase describes custody rather than control.

The approval step is where the designs diverge. A person approving a decryption should see the action, the destination and the value's scope on a screen the model did not draw. OWASP's attack page describes HITL dialog forging, which "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations," the reason an approval has to be rendered by something other than the agent asking for the credential (OWASP Foundation, n.d.).

The record should match the act. AWS's Well-Architected guidance says that "audit logs attribute every action unambiguously to either an agent or a human actor," and a key-use record has to do the same: name the person, the action and the destination for each decryption (AWS, 2026).

Identity is a separate question from decryption. Teleport's agent identity documentation states that "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key," an identity for the agent rather than an encryption key for a captured credential; most of its capabilities are marked "In-progress" or "Not started" (Teleport, 2026).

Revocation is the last piece. A key that cannot be withdrawn keeps decrypting the copies made during the run, so it needs an owner, a rotation path and a way to retire a grant. An agent given durable authority over a cloud account is the same problem at a larger scale, which is why AWS advises against access keys for the root user (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?).

What does a governed environment change?

A governed environment is a control class that acts where the screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders such as TOKEN_001. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the policy and approves each consequential step, and 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, the control class changes what the key pair is for. Encryption to a public key protects the stored copy; it does not protect the render that produced the copy. A governed environment protects the render: the token settings page is drawn with a placeholder, the model reads the placeholder, and the real value is resolved only when an approved action needs it at the destination the approver named. The ciphertext still exists and the private key still decides who can open it, but the agent no longer has to hold either the plaintext or the key for the work to proceed.

The two controls answer different questions, and a team needs both. Encryption answers who can read a stored credential. Governance answers what the model was shown while the credential was in use. A page that offers only the first can be accurate about its ciphertext and silent about the transcript, and the transcript is where a captured credential usually travels.

The control class covers the rendered page, not the terminal, the IDE, the local filesystem, direct API calls or MCP. A credential encrypted inside a shell script stays a shell-script problem, and a credential rendered on a settings page is the one this class can govern.

Methodology and limitations

This page rests on five vendor documentation pages from Cognition, OpenAI, Browserbase, Infisical and Teleport, two standards and guidance pages from OWASP and AWS, two industry research posts from Veracode and Truffle Security, and three RedactSure research pages. 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 figures from research posts are cited as reported, not as independently measured. The distinction between public-key encryption and vendor-side encryption at rest is drawn from what those pages state about their own designs, not from a reading of their code.

RedactSure did not test any named product hands-on. "Not described in the pages reviewed" means the recorded facts for that page do not cover the point, and it is not a statement that the vendor does not do it. Vendor features change, and the page carries its date; a feature released 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 captured token stored as ciphertext, and not an organization.

Determinations about whether a particular encryption scheme, key custody arrangement or approval flow meets a contractual, regulatory or industry requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a review of the implementation that produces and stores the ciphertext, or a test of the page the agent reads before it does.

What the record shows

Encryption to a public key is a real control with a narrow subject: it decides who can open a stored copy. The vendor pages reviewed here record custody designs that keep credentials out of an agent phase, encrypt them at rest, terminate TLS at a proxy, or reuse a saved session, and none describes encrypting a captured credential to a developer's own public key. The research record explains why the distinction matters: live credentials sit in public data in the millions, and a model that reads one holds it in context regardless of what happens to the copy afterward. The key pair and the render are separate questions, and a team that answers only the first can hold sound ciphertext and a transcript full of plaintext; RedactSure's environment is built on the second. Running one capture against one agent and one token settings page is the practical test: write down where the plaintext existed, who could decrypt the stored copy, and which named person approved the reveal.

Frequently asked questions

Does encrypting a credential to my public key keep it out of the agent's context?

No, not by itself. The encryption runs after the agent has captured the value. If the agent read the token on a settings page or typed it into a form, the model received the plaintext before any ciphertext existed, and the key pair only decides who can open the stored copy. Keeping the value out of the context is a separate control at the render layer. Encrypting the copy is still worth doing, because it narrows who can read what was stored.

Which key does a vendor hold when it says credentials are encrypted at rest?

Usually the vendor's own key, not yours. "All secrets are encrypted at rest" describes storage, and the service that stores them can normally decrypt them to run the task. Codex cloud says credentials are decrypted for task execution, and Devin scopes credentials and encrypts them at rest, but neither page describes encryption to a key the customer holds. Ask who controls the key, whether the vendor can decrypt on its own, and what record names the decryption.

Can an agent use a credential without ever seeing it?

Yes, by custody or by substitution. A proxy can hold the credential and attach it to an approved request, which is the design Infisical describes when it says Agent Vault terminates TLS. A governed page can render a token and resolve the real value at the destination. Both keep the plaintext out of the model's context, and neither is the same thing as encrypting the stored copy to the developer's public key. Which one a tool uses is the question to settle.

What does the private key authorize once the agent has it?

Everything the ciphertext protects. A process holding the private key can decrypt any copy it can reach, so if the key sits in the agent's environment, the encryption has become a storage format rather than a boundary. If a person holds the key and unlocks it for one action, the authorization is a human decision, and it should name the action and the destination. Key custody, not key length, is the part a buyer can check.

Does a public key replace an approval step?

No. Encryption says who can decrypt; approval says who agreed to the use. OWASP's Lies-in-the-Loop attack shows why the two cannot be the same control: an agent can forge the dialog that asks for approval, so the person may authorize something other than what runs. Keep the approval outside the model that wants the credential, and record the name, the action and the destination. A key pair produces none of that record on its own.

How do I test where a captured credential goes?

Take one test token, have the agent collect it from a token settings page, and write down three things: what the model received while the page was open, who could decrypt the stored copy, and which named person approved any use. Repeat the run after a vendor release. If the transcript holds the plaintext, the encryption protected the file and not the run. If no one can name the approver, the key pair is doing custody work without an authorization trail.

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 Captured Token Encrypted Until an Approved Reveal

A captured token needs two protections, encryption of the stored copy and control of what the model reads, and the custody designs above cover only the first.

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

Before, the agent reads the token on the token settings page and holds the plaintext while the copy is encrypted. Inside the governed environment, the page renders TOKEN_001 and the real value appears only at the destination a developer approved.

RedactSure is deploying now with enterprise and government customers. TruffleHog found 11,908 live credentials in 400TB of web data.

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

See it on your own workflow

Encryption protects the stored copy, but the question is whether the model ever reads the plaintext. Bring a token task and see, with test values, what the model reads on the settings page. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.