Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does 1Password OpenShell Show the Agent Placeholders or Real Credentials?
Placeholders: inside the OpenShell developer preview the agent receives an opaque placeholder, and the gateway attaches the real value only on a request to an approved host. Check where that substitution sits, because it covers the agent's requests and not the values a rendered page shows.
A personal access token sits in an OpenShell sandbox while an agent fixes a failing build, and the reviewer's first question is what the model holds while it works. 1Password's Environments integration answers it: the sandbox receives a placeholder, and a gateway outside the agent's process replaces it with the real value when a request goes to an approved host (1Password, Workflows, 2026). That departs from pasting a token into an environment variable: the value the model would otherwise carry never enters its context.
Where the substitution happens decides how far the protection reaches. A gateway that rewrites an outbound request governs what leaves the sandbox; it does not govern what a page renders inside it. An agent that opens a repository's token settings page and reads the value listed there still receives whatever that page displays, including the token itself when the page shows it.
For a team that lets an agent touch production repositories, that gap decides what a prompt injection collects: a placeholder it cannot use, or every value the open page showed.
Key findings
- For a credential to stay out of a model's reach, the value it would read has to be replaced with a consistent token before the model receives it, with the real value released only at the approved destination (What Is Render-Layer Tokenization?).
- That control also needs a named person approving each consequential request and a record of what the model received, because substituting the value decides where it goes and not whether the action should happen (How Do I Know Which Credentials a Coding Agent Has Touched?).
- 1Password's OpenShell pages describe substitution at the request boundary and do not describe replacing values on a rendered page before the model reads it (1Password, Workflows, 2026).
- 1Password's developer documentation states that "Secret values never enter the agent process or context," which is the claim the rest of the page tests (1Password, Environments, 2026).
- NVIDIA's best-practices page gives the same rule from the runtime side: "The agent receives an opaque placeholder, not the real API key or access token" (NVIDIA, Best practices, 2026).
- GitHub documents that "Each token can be further limited to only access specific repositories for that user or organization" (GitHub, 2026).
What does the agent read inside an OpenShell sandbox?
OpenShell's control covers the credentials a sandboxed process uses rather than the content of a page. The sandbox starts with a placeholder in place of the credential, including one for the model key the agent uses, and the OpenShell Gateway replaces it only when the agent sends a request to a host on the approved list (1Password, Workflows, 2026).
The developer documentation is explicit: "Secret values never enter the agent process or context," and "Requests to any other host don't receive the credential" (1Password, Environments, 2026).
A governed browser covers a different surface. It replaces values on a rendered page before the agent reads them (What Is a Protected Browser for AI Agents?), and its scope does not include the terminal, the IDE, the local filesystem, direct API calls or MCP. OpenShell governs what leaves the sandbox as a request.
An agent asked to push a branch reads the repository and calls the repository host's API with GH_TOKEN_01 in its environment; the request leaves through the CONNECT proxy, and the gateway attaches the real value for the approved API host (1Password, Environments, 2026). Give the same agent a task that requires reading the page where the token is listed (What Can an AI Agent See in Your GitHub Settings?), and the model receives the page as rendered.
Who approves a request, and where does the real value go?
Two gates sit close together here and they are not the same gate. OpenShell's gate is a destination: the gateway releases the value for a host on the approved list, and the developer page does not describe a person approving each request (1Password, Environments, 2026). A destination list decides where a value may go, not whether the action should happen (How Do I Keep Credentials Outside the Sandbox Where the Agent Runs?).
The research record treats human approval as its own control. A governance paper from OpenAI calls human approval "a standard way to limit egregious failures" (Shavit et al., 2023).
The difference matters when a request is plausible and wrong. An agent steered by a page it read can compose a valid request to an approved host, and the gateway attaches the real value because the host is on the list. NVIDIA's page names the consequence: "Each allowed endpoint is a potential data exfiltration path" (NVIDIA, Best practices, 2026).
EchoLeak shows the pattern: the Microsoft 365 Copilot client "automatically fetches the external image URL included by the attacker" (Reddy and Gujral, 2025). A person approving the action sees the destination and the arguments, which a host list cannot do.
What do the vendors themselves say?
1Password and NVIDIA describe the same mechanism from two sides of the process boundary.
| Dimension | 1Password and NVIDIA, per their documentation | What a buyer should verify |
|---|---|---|
| Where the control sits | The gateway, outside the agent's process: "OpenShell enforces these controls outside the agent's process, so the agent can't change or get around them" | Which component holds the value, and who operates it |
| What the model receives | "The agent receives an opaque placeholder, not the real API key or access token" | Whether that covers the model key too |
| When the real value appears | "OpenShell Gateway replaces a placeholder with the real value only when the agent sends a request to an approved host" | The host list and who changes it |
| How the value is held | "1Password stores them by reference rather than by value" | Where the reference resolves |
| What the sandbox decides | It "shares the boundary with the untrusted agent, so it never makes policy decisions" (NVIDIA, Architecture, 2026) | That policy lives in the gateway |
Both also describe the limits. NVIDIA's page states that "Each allowed endpoint is a potential data exfiltration path," which is a precise way to describe a host allowlist (NVIDIA, Best practices, 2026). 1Password's developer page explains that the integration is in beta, and it does not explain how the gateway stores the values or what follows if the gateway is compromised (1Password, Environments, 2026).
What the pages do not address is the rendered page: they describe a credential that never enters the agent process, and they describe no control over the values a page draws (1Password, Workflows, 2026).
The 15 AI agents reviewed for payment controls do not include OpenShell, and the group splits the same way: 9 of the 15 document keeping passwords or credentials away from the model, and 0 document the same for the customer data on a page (Do AI Agents Ask Before Making a Payment?).
What record exists of what the agent read and used?
The OpenShell pages describe the control and not the ledger. They state that enforcement sits outside the agent's process, and they do not describe a per-run record of which placeholder became which value at which host, or of what the model had read before it asked (1Password, Environments, 2026). A gateway log that shows the destination and the outcome is a start, but it does not show the page.
AWS's guidance for agent architectures makes the requirement concrete: "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026). In this integration the actor is the sandboxed agent, and the person who set the approved hosts is a separate actor whose decision belongs in the same log. The AICPA & CIMA criteria are the frame an assessor will bring, because they exist "to evaluate and report on controls over the security, availability, processing integrity" (AICPA & CIMA, 2023). A control the customer cannot test stays a claim until the first run.
A value that appears in the model's transcript was in its context; a value that appears only in the gateway log stayed outside it. That comparison tests the vendor's claim in the reviewer's own environment, and the gateway configuration and host list are enough to run it. A team that keeps the transcript from one run holds the evidence an assessor will ask for.
What should a security team ask for in writing?
A buyer can settle most of this before a pilot with six questions in writing. The first is what the model receives from a rendered screen: when the agent opens a page that displays the token, does the model read the value, and does any control replace it before the page is rendered? The OpenShell pages answer the credential question and leave that one open.
| What to ask | What the documentation shows | What to require |
|---|---|---|
| Which values the model reads on a page | Placeholders for the credential, with no statement about rendered values | A per-task rule on which values the model may read |
| When the real value appears | At the gateway, for an approved host | The host list and who changes it |
| Who approves the action | An approved host, not a per-request person | A named approver for each consequential request |
| What follows a gateway compromise | Not described | A written answer and a recovery plan |
| What record exists | Enforcement outside the agent's process | An export of what the model read and what each request carried |
| Status of the integration | A developer preview in beta | A date and a support commitment |
Two rows are the ones buyers skip. The record row lets an assessor test the claim after the fact, and the gateway-compromise row is the one the documentation leaves open (1Password, Environments, 2026). Least privilege governs the credentials and the actions an agent may take; it does not govern the content of the page it reads (What Is Least Exposure?).
What does a governed environment change?
A governed environment moves the substitution one layer earlier. Values chosen by policy are replaced with consistent tokens such as ACCT_001 or TOKEN_001 before any model reads the page or the request it builds, so the agent works on the token in its context and in the request it composes. The real value resolves only at the approved destination, at the moment of an approved action, and a named person approves each payment, submission or record change. Every screen, action and approval with a name is exported as a record the customer holds.
Next to OpenShell's design, the difference is one layer rather than one principle. OpenShell substitutes at the request boundary, which protects the credential the sandbox uses; render-layer tokenization substitutes at the page, which protects the values the model reads. A team whose agents cross a repository console and a bought application needs both, because a console page renders values that no gateway inspects, the gap the 1Password comparison sets out (RedactSure vs 1Password: 2026 Comparison & Alternative).
The two controls compose: a placeholder in the environment keeps the credential out of the model's context, and tokenization of the rendered page keeps the record data out of it.
What the record shows
Substitution before the model reads the value is the stronger half of the answer, and the documented design does it: the model holds a placeholder and the gateway attaches the value at an approved host. What the design leaves open is the page. A token listed on a settings page, a customer record in a console and a billing detail in an admin screen are rendered content the gateway never sees, and each reaches the model as the page draws it. A two-task test settles the boundary. Pick a token, ask the agent to use it against its API, and confirm that the transcript shows only the placeholder. Then ask the same agent to open the page where the token is displayed and compare the transcripts. The first should be clean, and the second is where the answer changes.
Methodology and limitations
This page rests on vendor documentation, one peer-reviewed exploit study, a governance paper and two standards entries, all read as of October 20, 2026. The 1Password pages, NVIDIA's OpenShell pages, GitHub's token documentation, the AWS guidance and the AICPA & CIMA criteria were read in full, and documentation read that way gives a sound view of where a product applies its control.
No product on this page was tested for this page. "Not described in the pages reviewed" means the recorded pages for that product do not address the point, not that the product cannot do it. The OpenShell integration is a developer preview in beta, vendor features change, and the page carries its date. The example describes a record type, not an organization. RedactSure is deploying now with enterprise and government customers. Determinations about compliance belong to counsel and assessors.
Frequently asked questions
Does 1Password OpenShell show the agent placeholders or real credentials?
Placeholders. The agent process receives an opaque placeholder, including for the model key it uses, and the OpenShell Gateway replaces that placeholder with the real value only when a request goes to an approved host. 1Password's developer documentation states that credential values never enter the agent process or context, and that requests to any other host do not receive the credential. The page the agent reads is a separate surface.
What does the model receive inside the sandbox?
A placeholder for each credential the integration covers, including the key the agent uses to reach its model provider. The value stays with the Environments vault and the gateway, which stores it by reference rather than by value, so the agent can work against real systems without holding the credential in its context. That is the vendor's wording, and it is specific about the process boundary. The rendered page is a different question.
Who approves the request that gets the real credential?
No person, from the pages reviewed. The gate the documentation describes is the approved host: the gateway releases the value when the agent sends a request to a host on the list. A destination list is not an approval of the action, since an agent steered by a page it read can compose a valid request to an allowed host. A named approver for consequential requests is a separate control a buyer has to add.
Does OpenShell record what the model read?
The pages describe enforcement, not a transcript. They state that the controls run outside the agent's process and that the agent cannot change or get around them, and they do not describe a per-run record of which value went to which host or what the model had read before it asked. A team that needs that record should ask for an export pairing the screen the agent saw with the request it made.
What should a reviewer check on a rendered screen?
Whether the page displays the value at all. A token settings page, an admin console and a billing page each render fields the gateway never inspects, and a model reading them receives what they show. Ask for the page to be tokenized before the model reads it, or keep that task away from an agent that holds a real credential. One transcript from such a page is the quickest evidence.
Can an agent bypass the gateway by calling another host?
Not through the sandbox's own network path, according to the documentation, since every outbound connection goes through the CONNECT proxy and the gateway replaces the placeholder only for an approved host. The risk sits in the list rather than the bypass: every endpoint on it can carry data out, which NVIDIA's page states directly. A short list, reviewed on a schedule, is the control that follows.
How RedactSure Covers the Page a Sandboxed Agent Reads
A placeholder outside the agent's process protects a sandboxed credential and stops at the page, where rendered values still reach the model. 1Password's announcement says the agent "sees placeholders rather than real credentials," which covers the credential and not the page (1Password, Workflows, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent read the token on the repository's token settings page, and the value entered its context. Inside the governed environment, that page renders as TOKEN_002, the agent works against the placeholder, a named person approves the call to the API host, and the real value resolves there while the page stays tokenized.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A token used in a header can stay out of the model's context while every value on the page stays exposed. Bring a token and a page, and see with test values what the model reads and where the real value lands. Book a demo