Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can 1Password Capture a Token an Agent Generates Mid-Task?
No, 1Password's agent features deliver credentials you already stored and issue them at runtime, and its pages describe no feature that captures a key an agent creates on a vendor console before the model reads it. Ask what the model receives from the rendered page when a key is created, and which person stores the value.
An agent that provisions its own access creates the credential inside the run: it opens a vendor's API keys page, names a key, chooses a scope, and the console draws the value once. A vault that hands out credentials it already holds has nothing to hand out at that point, and 1Password's documented agent features begin with an item someone stored earlier (1Password, Secure Agentic AI, 2026). The gap is easy to miss because the same product keeps delivered credentials out of the model's context in wording that promises more.
What the model receives on that page settles the question. If the console draws the new key as itself, the model reads it, and the value joins the context, the transcript and whatever the agent writes next. 1Password's pages describe controls at the vault and at the request boundary, which sit before and after the render frame where the value first appears (1Password, Environments, 2026).
The decision is where capture happens and who owns the key. A value that reaches the model is spent, whatever the vault does.
Key findings
- For a key an agent creates to stay out of the model's context, the value would have to be replaced with a consistent token on the rendered page before the model reads it, and released only at the approved destination (What Is Render-Layer Tokenization?).
- That control also needs a named person approving each new credential and a record of what the model received, because capture decides what the model holds and not whether the key should exist (How Do I Capture a Token the Moment It Appears on Screen?).
- 1Password's agent pages describe delivery from a managed vault and access issued at runtime, and they do not state that a value the agent creates on a vendor page is captured before the model reads it (1Password, Secure Agentic AI, 2026).
- 1Password's solutions page says it can "Issue AI agents their access needed at runtime, scoped to the task, and revoked when the work is done" (1Password, Secure Agentic AI, 2026).
- 1Password's OpenShell documentation states that "Secret values never enter the agent process or context," which covers the credentials that integration delivers and not a key a dashboard prints (1Password, Environments, 2026).
- OWASP's non-human identity list calls credential leakage NHI2, the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores" (OWASP, 2025).
What does the model read when an agent creates a key on a dashboard?
The record is a new API key on a dashboard: a project's API keys page, a Create key button, a name field, a scope selector, and a dialog that prints the value once. The agent was asked to connect a service to that API, so it provisions the key itself, which is the autonomy the cited definition describes: systems "capable of pursuing goals autonomously by making decisions, taking actions, and adapting to dynamic environments without constant human oversight" (MIT Sloan Management Review, 2025).
The dialog is the exposure event. A console that prints a new key once will not print it again, so the string lives in the page's text, in the view the browser builds, and in the model's context for the rest of the run. Every later turn can repeat it, and every page the agent reads can ask for it (Can a Browser Agent Read an API Key It Just Generated?).
Nothing in 1Password's pages describes a step at that dialog. Its controls act on a credential that already exists: the vault holds it, the agent receives a reference or a filled field, and a gateway attaches the real value when a request goes to an approved host (1Password, Environments, 2026). A key that first exists there has to be saved by a person or read by the model, and the pages reviewed describe no third path (How Do You Let an AI Agent Manage API Keys Without Reading Them?).
Does 1Password's design cover a value an agent creates?
1Password's agent product is a lifecycle for stored credentials. Its solutions page says the product can "Issue AI agents their access needed at runtime, scoped to the task, and revoked when the work is done," using encrypted credentials "retrieved from a managed vault at runtime" (1Password, Secure Agentic AI, 2026).
Secure Agentic Autofill applies that order to a login form. The announcement states that "Credentials are not shared with the LLM or exposed in Browserbase logs and repos, maintaining 1Password's security model" (1Password and Browserbase, 2026). That covers the credential the feature fills, not a value the page generates after sign-in.
OpenShell is the most explicit case. Its developer documentation states that "Secret values never enter the agent process or context" and that "Requests to any other host don't receive the credential" (1Password, Environments, 2026). A placeholder is issued for a value the environment holds, and the dialog that prints a new key has none until someone captures it.
In the October 2026 review of ten coding agents and sandboxes, 1 of 6 coding agents describes keeping a real value from the model, an option per secret in Cursor Runtime Secrets, while all 4 sandboxes describe a placeholder or proxy design, 2 of them by default (Can AI Coding Agents Read Your API Keys?). The count reads vendor documentation rather than enforcement.
Research on defenses locates that boundary: a "simple, modular, and model-agnostic defense operating at the agent-tool interface" (Bhagwatkar et al., 2026). Least privilege governs the credentials and actions an agent may use, not the content of the screen the agent reads (What Is Least Exposure?).
What do the vendors themselves say?
| Dimension | 1Password, per its documentation | What a buyer should verify |
|---|---|---|
| Where the control sits | A managed vault, and for OpenShell a gateway outside the agent's process: "OpenShell enforces these controls outside the agent's process" | Which component holds the value and who runs it |
| How coverage starts | A credential already stored, "retrieved from a managed vault at runtime" | Whether a key created during the run can enter the vault at all |
| What the model receives | "Secret values never enter the agent process or context" for delivered credentials, and "Credentials are not shared with the LLM" for autofill | Whether either sentence covers a value the page prints |
| Who approves | Real-time prompts for autofill, "via 1Password mobile or desktop"; the OpenShell gate is an approved host | Whether a person approves the creation of a new key |
| Status | The OpenShell integration is in beta | A date and a support commitment |
1Password's developer page says the gateway attaches the real value only for an approved host (1Password, Environments, 2026). NVIDIA's architecture page draws the same line: the sandbox "shares the boundary with the untrusted agent, so it never makes policy decisions" (NVIDIA, Architecture, 2026). Both place the decision in the gateway, and both leave the page outside it.
Who approves a new key, and what record shows where it went?
Approval and capture are separate decisions, and the pages reviewed describe the first one for a stored credential only. Autofill prompts a person in real time before a stored login is used (1Password and Browserbase, 2026). The OpenShell gate is a host list: the value is released when a request goes to an approved host, and no person is described at that point (1Password, Environments, 2026). A host list decides where a value may go; it does not decide whether a new key should exist.
A gateway log can show that a request reached an approved host, and the pages do not describe a per-run record of what the model read before it asked. For a key created mid-task, the record that matters is the page: what the dialog displayed, what the model received instead, who approved the creation and where the value resolved. That is the difference between filtering a request and tokenizing a screen (Screen-Level Tokenization vs API Filtering for AI Agents).
An agent that holds a key for one system can use it in another, the "insufficient isolation between apps and the system" the IsolateGPT authors describe (Wu et al., 2025). The incidents that make that reach costly are actions: "Cursor's agent deleted PocketOS's production database via a single rogue API call" (Columbia DAPLab, 2026). The approval has to attach to the creation, and the record has to show what the model held when it used the key.
What should a security team ask for in writing?
The first question to put in writing is what the model receives from a rendered screen at the moment a credential is created, because every other control depends on that answer.
| What to ask | What 1Password's documentation shows | What to require |
|---|---|---|
| What the model reads on the page that prints a new key | Vault delivery and request-boundary substitution; no statement about a value a rendered page prints | A per-task rule on which values the model may read |
| When the real value appears | At the approved host, for a credential the vault holds | The destination list and its owner |
| Who approves a new key | A person approves a stored login; no per-creation approval described | A named approver for each new credential |
| What record exists | Enforcement outside the agent's process | An export pairing the page, the value and the approval |
| What happens if the key is never saved | Not described | A documented path and a named owner |
The first row is the one a pilot can answer in an afternoon: open the console page where the agent creates a key, let it create one with test values, and read the transcript. The value is there or a token is there, which decides whether the rest are worth asking. The fifth row decides ownership, because a key that is never saved is lost or kept somewhere nobody governs.
What does a governed environment change?
A governed environment captures at the point where the value appears. Values chosen by policy are replaced with consistent tokens such as TOKEN_001 before any model reads the page, so the dialog that prints a new key renders as a token and the model works with that label. The real value resolves only at the approved destination, at the moment of an approved action, and a named person approves each new credential, payment, submission or record change. Every screen, action and approval with a name is exported as a record the customer holds.
For this question, the difference is where the first step happens. A vault holds a credential that already exists and hands it to a workload. A render-layer control acts in the frame where the credential first appears, which is the only point at which a new key can be captured before the model reads it. The two compose: the vault keeps a delivered credential out of the process, and the render layer keeps a created one out of the context.
A team whose agents cross a vendor console and a bought application needs both, the gap the 1Password comparison sets out (RedactSure vs 1Password: 2026 Comparison & Alternative). The capture is the first step, and every other control depends on it.
What the record shows
A render-layer control decides what the model receives from the page, and this record is a key that appears once: whether the model read the string or a token, who approved the creation, and where the real value went. The documented design answers the stored-credential version and leaves the created-key version open, because its controls start from a vault entry and act at the request boundary. A two-part check on one console page settles it. Create a key with test values while the agent watches, then read the transcript; if the string appears, the page is unprotected. Repeat with the value replaced by a token and confirm that the write to the vendor API still succeeds while the transcript shows only the token.
Methodology and limitations
This page rests on vendor documentation from 1Password and NVIDIA, one preprint on injection defenses at the agent-tool interface, a standard from OWASP, and two industry analyses, all read between October 20, 2026 and October 22, 2026. The 1Password pages, the OpenShell architecture page and the vendor announcement were read in full, and documentation read that way gives a sound view of where each product applies its control.
None of the products on this page was tested for this page, and "not described in the pages reviewed" means the recorded pages do not address the point, not that a product cannot do it. 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, assessors and the organization's own security and compliance officers.
Frequently asked questions
Can 1Password capture a token an agent generates mid-task?
No, not from the pages reviewed. 1Password's agent features deliver credentials already stored in a managed vault, issue access at runtime for a task, and keep delivered values out of the agent process and context. None of that describes a feature that notices a new key on a vendor console, stores it, and substitutes a token before the model reads the page. The value stays outside the design until a person saves it where the vault can reach it.
What does the model receive when 1Password delivers a credential?
A placeholder or a filled field, depending on the feature. The OpenShell integration gives the agent an opaque value and attaches the real credential at an approved host, and the announcement for autofill states that credentials are not shared with the LLM. Both describe a credential the vault holds. The page the agent reads while creating a new key is a different surface, and the model receives what it draws.
Who approves the creation of a new key?
No one, from the pages reviewed. Autofill prompts a person in real time to approve the use of a stored login, and the OpenShell gateway releases a value for an approved host rather than for an approved action. A key created in a console has no approval step described, which leaves the decision with whoever reviews the transcript or the bill. That is a review after the work, not a gate before it.
What record exists of what the model read?
Not a per-run record of the page, from the pages reviewed. The documentation describes enforcement outside the agent's process and a gateway that controls which host gets a value. A log of destinations and outcomes is useful and does not show the dialog that printed the key. A buyer who needs that pairing should ask for an export of the page, the value and the approval from the same run.
What should a team do when the model reads a key an agent creates?
Treat the value as exposed the moment the page renders it. Have the agent write to a field the environment controls, or create the key through a path that stores it before the model reads it, and rotate anything that reached a transcript. If a person must save it, give that step an owner and a place to record it, because a key shown once is easy to lose and hard to revoke. The owner is the part most teams are missing.
Is a short-lived token a substitute for capture at creation?
Only partly. A short-lived credential limits how long a leaked value works, which reduces the cost of a mistake. It does not keep the value out of the model's context during the run, and an attacker who reads the transcript can use the token before it expires. Lifetime and capture are separate controls, and a team needs to know which one it has before it counts the exposure as handled.
How RedactSure Captures a Key the Agent Creates in a Console
Approaches that deliver a stored credential stop at the dialog where an agent creates a new key, because the value exists only on that page. 1Password states that "Secret values never enter the agent process or context," which covers what it delivers (1Password, Environments, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent created the key, read the value from the dialog and carried it into every later turn. Inside the governed environment, the dialog renders as TOKEN_004, a named person approves the creation, and the real value resolves at the vendor's API when that action submits it.
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 key that appears once on a console stays in the model's context for the run. Bring a task where your agent creates access and see, with test values, what it reads and where the value resolves. Book a demo