Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is a Private Adapter for AI Agents?

A private adapter is a component outside the agent's sandbox that holds the service credential, makes the call the agent asked for and returns only the result, so the agent reads the repository files and never the token. Check where the credential lives, what the grant allows and what the returned files carry.

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

Security and platform teams that let an agent read private repositories need a precise name for where the credential sits, and the term private adapter names a position and a division of labor rather than a product. Put the credential in a process on the far side of the sandbox boundary, let the agent ask that process for a named resource, and the agent can read a repository without ever holding the key that opens it. Everything else in the definition follows from where the line is drawn: what the adapter holds, what the agent sends, what comes back, and what the agent can do with the answer. The distinction matters because two neighboring designs are routinely described as if they were the same thing. A credential store hands a value to the process that asks for it, and a substitution proxy swaps a value on the wire for hosts on a list. A private adapter does neither: the request arrives without a credential and the credential never leaves the adapter. Each arrangement fails differently, and a team that cannot name which one it runs cannot say where the value sits when a run goes wrong. The finding that shapes the rest of the page is that an adapter governs the call and leaves the result with the agent, so a second control class has to cover the half an adapter cannot. The running example is one record type, a repository file fetched through an adapter: one repository, one directory, one read, and a token that never appears in the transcript.

Key findings

  • A private adapter is a process outside the agent's sandbox that holds the credential, makes the requested call and returns only the result, so the agent gets repository files and never the token (What Is a CodeCell?).
  • HashiCorp's tutorial issues the agent a token that is "read-only, repo-only, scoped to a single secret, and short-lived", and its wrapper "exports it as VAULT_TOKEN, and launches the agent", so the process holds the raw value (HashiCorp, Secure, 2026).
  • Anthropic's Claude Code page states that "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM" and that the VM holds a short-lived credential scoped to that session, for cloud sessions only (Anthropic, 2026).
  • Cognition's guide has "In the browser, Devin types the value directly" and binds credentials "as environment variables" for shell commands (Cognition, 2026).
  • GitGuardian reported that "over 1,200 leaked at least one secret" and that "Copilot generates 2702/900 = 3.0 valid secrets for one prompt on average", the repetition a fetched file of credentials faces in context (GitGuardian, 2025).
  • The control that changes what the model reads sits before the screen is rendered: values become consistent tokens such as REPO_001 for the whole run, and real values resolve only at the destination a named person approved (What Is Least Exposure?).

What is a private adapter, and what does it not cover?

The definition has four parts. The adapter is a process outside the agent's sandbox, on the organization's side of the boundary. It holds a service credential the agent does not hold. It accepts a request that names a resource and an operation rather than a credential. It makes the call itself and returns the result. The word private names the position: the adapter and the credential belong to the organization running the agent.

In the record used here, the agent asks for one file in one repository at one path on one branch. The adapter checks the request against its grant, authenticates with the credential it holds and returns the file body. The transcript shows the request and the body, and it does not show the token, because the token never entered the process that writes the transcript. That is a property of the path, not of the agent's behavior: a compromised agent can still ask for every file its grant allows. The pattern is the one How Do You Let an AI Agent Manage API Keys Without Reading Them? sets out for keys, applied to a repository.

A governed browser environment covers what an agent reads and does on a rendered page: dashboards, consoles, settings pages and repository pages. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. The adapter is the direct-API-path case, so a governed browser environment does not govern it, and an adapter says nothing about a page. A team running agents on its own machines needs both answers, because a repository page can display the same key the adapter holds.

How does a private adapter keep a token out of the agent's hands?

The exchange is short. The agent sends a request that names what it wants, such as a path and a branch. The adapter checks the request against its grant, attaches the credential it holds and returns only the response.

Scope is the first control and not the whole of it. 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", and its wrapper "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent", which puts the raw token in the agent's environment; the page does not say whether the agent can read it (HashiCorp, Secure, 2026). That is a narrow grant around a value the process can still hold, not an adapter that never hands it over.

Vault's lease documentation supplies the lifetime half: "All dynamic secrets in Vault are required to have a lease", so the value is valid for a stated duration, and "When a lease is revoked, it invalidates that secret immediately and prevents any further renewals" (HashiCorp, Lease, 2026). An adapter's grant should have the same shape: one service, one repository, one operation, a stated lifetime, and a revocation that takes effect at once.

The test is whether the value can appear in the agent's own output: ask for the environment, the transcript, the logs and any file it writes. If the token can appear in any of them, the boundary is scope and not custody.

What do the vendors themselves say?

Two vendor pages describe designs close to the definition above, and each stops at a different point.

Anthropic's Claude Code documentation states that "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM" and that the VM holds a short-lived credential scoped to that session, custody the page describes for cloud sessions and not for local ones (Anthropic, 2026). That is the nearest documented arrangement, and the page is candid about the boundary: "The boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can", and "While these protections significantly reduce risk, no system is completely immune to all attacks" (Anthropic, 2026).

Dimension Anthropic's cloud sessions, per its documentation What a buyer should verify
Where the durable credential sits Encrypted on Anthropic's servers, never in the session VM Which party holds it, under which contract, and for how long
What the workspace holds A short-lived credential scoped to that session Whether the agent process can read or print it
Scope of use The page does not state which repositories or operations the short-lived credential covers The repository, operation and lifetime the grant names
Local sessions The custody is described for cloud sessions, not for local ones The same questions for every machine the team runs
What the model reads A permission prompt is the boundary, and render-layer substitution is not described What the model receives on a settings or token page
Record Not stated for this custody path A per-run record of what was fetched, under which grant, and who approved

Cognition's Devin guide documents a different arrangement. Credential scopes are organization, personal, repository and session, and a session credential is "scoped purely to the current session and are not saved for any future sessions"; for use, "In the browser, Devin types the value directly" and "For shell commands, it binds secrets as environment variables whenever needed"; and "All secrets are encrypted at rest" (Cognition, 2026). Encryption at rest protects the store, the browser path puts the value on the page and the shell path puts it in the environment, so whether the model sees the value is not described in the pages reviewed (Cognition, 2026).

Read together, the two pages answer who may use a credential and for how long. Neither answers what the agent receives, which is the question the rest of this page turns on.

Where does a private adapter stop protecting the agent?

The adapter governs the request, not the response. Every file body it returns enters the model's context, and a repository holds more than source code: configuration, test fixtures and committed credentials. GitGuardian's test of Copilot reported that "over 1,200 leaked at least one secret" and that "Copilot generates 2702/900 = 3.0 valid secrets for one prompt on average" (GitGuardian, 2025). Wiz reported that "Almost two-thirds of the AI companies analyzed had a verified secrets leak" (Wiz, 2025).

The grant bounds what a hijacked run can ask for, not whether it can ask. Against agentic coding editors, a prompt injection study reports that "attack success rates can reach as high as 84% for executing malicious commands" (Liu et al., 2026). A run that reads an issue or a file body can be steered to request another path inside the grant, and a read-only grant still returns every file it covers.

Indirect injection is the route: the instruction arrives in content the agent retrieves, not in the user's prompt (What Is Indirect Prompt Injection and How Does It Reach AI Agents?). The lethal trifecta names the three properties that make the result a theft: private data, untrusted content and external communication (What Is the Lethal Trifecta for AI Agents?). An adapter with one destination and one operation removes the third property for that run and leaves the other two. What it protects is the credential it holds, not the data it moves: a live key inside a fetched file still reaches the model.

How does a private adapter differ from a scoped token in the environment?

The difference is custody, not scope, and a table makes it visible. All four arrangements below can be described as least privilege, and only one keeps the value out of the agent's reach.

Arrangement Where the value sits What the agent can print What it does not cover
Token in the environment In the agent's process environment, exported before launch The token itself Nothing beyond the grant's scope
Credential store the agent queries In the store until the agent asks, then in the agent's process The value it fetched The same
Substitution proxy for listed hosts In the proxy, which swaps a placeholder for listed hosts The placeholder on the way out Hosts not on the list
Private adapter In the adapter, which the agent addresses by resource The result only The content of the result and the pages around it

Scope is real protection. Progent's abstract states that it "significantly reduces attack success rates while maintaining high utility" (Shi et al., 2026), the privilege-control route: limit what the agent may do and a successful injection accomplishes less. Least privilege governs actions and credentials, and it does not govern the content of the screen an agent reads (What Is Least Exposure?). An adapter says which calls the agent may make, not what it may see.

Tokenization covers the content. It exchanges a sensitive value for a token that carries no exploitable value on its own, with the original held apart from the operational data store, as Skyflow describes it (RedactSure vs Skyflow: 2026 Comparison & Alternative). A durable credential is the opposite design: AWS strongly recommends against creating access keys for the root user, which rules out the simplest way an agent might be given top-level power (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). The adapter's grant should resemble neither a root key nor a fetched credential: one destination, one operation, one run.

The practical difference appears when a run is compromised. A token in the environment is taken and used from anywhere; a store is asked; an adapter can only be asked for what its grant covers, so the attacker receives data and not authority.

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 the model works on placeholders such as REPO_001. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves every consequential action. 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 class adds the half an adapter cannot supply. An adapter decides what the agent may ask a service for, and it returns real content. The class decides what the agent sees while it works: the repository page, the settings page and the key list arrive as tokens. Put together, the run works on one repository with the adapter holding the key and the page rendering DEPLOY_KEY_001.

The record is the part a reviewer can use. The adapter's request, its grant and its result belong in the same record as the screens the agent read and the approvals it waited for, because the two halves answer one question: what did this run touch, and who allowed it. A record with the page as tokens but no account of the call, or the call but no account of the page, leaves out half the run.

The scope of the class is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, and that limit is why an adapter remains the mechanism for the API path. A team that wants one answer for a run should read the two together rather than treat either as a complete control.

Methodology and limitations

This page rests on two preprints on agent privilege control and prompt injection against agentic coding editors, vendor documentation from Anthropic, HashiCorp and Cognition, two vendor research posts from GitGuardian and Wiz, and seven existing 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 vendor research are cited as reported, not as independently measured.

RedactSure did not test any of the products hands-on. "Not described in the pages reviewed" means the pages cited here and nothing broader. The adapter is described as a design pattern assembled from vendor documentation and existing research, not as a feature of any one product. Vendor features change, and the page carries its date; a release after that date should be treated as unreviewed until the test 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 repository file fetched through an adapter, and not an organization. GitGuardian's post does not confirm whether the extracted credentials were still active, and Wiz's does not say how many of the 50 companies lacked a GitHub presence.

Determinations about whether a credential arrangement meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a review of the organization's own credential inventory, grant policy and approval workflow, or a test of its own agent against one repository.

What the record shows

For teams giving agents private repositories, the record supports a narrow conclusion. A private adapter moves the credential out of the agent's process and leaves the result in it, so the component answers the question of authority and not the question of exposure. The vendor pages reviewed show the pattern in pieces: a durable credential kept outside a session, a short-lived one inside it, and a token scoped to one credential and one operation. The research record shows why the second question cannot be skipped, because a fetched file can carry a committed credential and the model reads what it receives. The pairing is the point, with the adapter governing the call and a render-layer control governing the page, which is where RedactSure's environment sits. A team should run a small test before relying on it: name one agent and one repository, ask the adapter for one file, and write down what the token was, what came back, and who approved the call.

Frequently asked questions

What is a private adapter for AI agents?

It is a component outside the agent's sandbox that holds a service credential, takes the agent's request for a named resource, makes the service call itself and returns only the result. The agent works with the repository files and never with the token. The design is private in the sense that the adapter and the credential belong to the organization running the agent. An adapter is a boundary in a process diagram, so ask to see the diagram rather than the description.

Does a private adapter keep the agent from reading the files it fetches?

No. The adapter filters requests, not responses, so every file body it returns reaches the model as text. If a repository holds a committed key or a configuration value, the agent reads it with the rest of the file. That is why the component is described as credential custody rather than data protection. The grant, not the model, decides which files are reachable, so read the transcript for what came back.

How is a private adapter different from a secret manager?

A secret manager stores a value and gives it to the process that asks, which is useful when the process is trusted and the question is where the value lives at rest. An adapter never gives the value to the agent: it makes the call and returns the answer. The distinction shows in the transcript. If the agent can print the credential, the design is a store with a scope, not an adapter, whatever the vendor calls it.

What stops an injected instruction from using the adapter?

The grant does, and only partly. A read-only grant limited to one repository and one operation means a hijacked run can request files inside that boundary and nothing else. It can still choose which file, so the attacker reads whatever the grant covers. Injection studies report command execution success as high as 84 percent against coding editors, which is why the grant should be as narrow as the task and expire with it. Narrow it to the task in front of the agent, not the repository.

Does the adapter govern what the model reads on a page?

No. It governs the call, and the page is a separate path. If the agent opens a repository settings page or a token page, the browser renders whatever the service returns, and the model reads it. A governed environment covers that path by replacing values with tokens before the model reads the screen. The two controls meet in one run and answer different questions. Ask for the screen record beside the call record.

What should a team ask about a private adapter?

Where the credential lives and which party controls it. What the grant allows, down to the repository, the operation and the lifetime. Whether the agent process can read or print the value, and what the record shows about each call. Whether revocation takes effect immediately when a run stops. And what the adapter returns, because the files it hands over are the part of the run the credential design never governs. A written answer beside a run with a test repository is worth more than either alone.

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 Repository Page From Showing the Deploy Key

An adapter keeps the token out of the agent's process, but file bodies, key lists and settings pages still come back and reach the model as text.

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

Before: the agent opens the repository's deploy-key settings page and the key renders in the clear, so the model can repeat it. Inside: the page renders DEPLOY_KEY_001, the adapter holds the key, and it reaches GitHub when a named person approves the push.

RedactSure is deploying now with enterprise and government customers. A coding-editor injection study reports command execution success as high as 84 percent.

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

See it on your own workflow

A private adapter holds the deploy key outside the sandbox and makes the call, so the key never renders to the model. Bring a deploy key 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.