Security model - 1Password Developer

Agentic Autofill lets your agent use a person’s logins without your platform or the model handling the values. This page explains which protections 1Password provides and which depend on your implementation.

What 1Password guarantees

Items stay end-to-end encrypted. Every item in a 1Password account is encrypted with keys that only the person’s 1Password apps hold. 1Password’s servers can’t decrypt a stored item on their own. Your integration’s keys are created in the person’s browser. At consent, the person’s browser creates your integration keyset and the key that unlocks it. The unlock key goes to you, once, in the URL fragment of your callback. It never reaches a 1Password server. Only the person can create a grant. Approving a login is cryptographic work that needs the person’s vault key, and only their 1Password app holds it. Nothing you hold can create a grant: not your tokens, not your integration key, not a reference. A compromise of your platform can’t add a login the person didn’t approve. OAuth tokens are limited to your integration’s permissions. An OAuth token for your integration can create access requests, check their status, and fetch the logins the person granted. It can’t list the person’s items or approve requests. Granted logins are decrypted only inside an attested enclave. When the extension fills a login, it first verifies an AWS Nitro Enclaves attestation for 1Password’s credential broker, including a check that the enclave runs code 1Password released. It then opens an encrypted session with the enclave using the Noise Protocol Framework. The enclave decrypts the one granted login and returns it inside that session. The 1Password services that relay the session can’t read it.

What your integration must protect

Account for these responsibilities when you design and describe your integration.

Area	What’s true	What you do
The page during a fill	The values are in the page between fill and submit. The extension removes them before `fillCredential` returns.	Keep the model and agent from reading the page, taking screenshots, or sending CDP commands to the tab until the call returns.
Tokens in the browser	Every extension call takes the access token and the integration key, so both enter your agent’s browser.	Keep them in memory only, give each session only a current access token, and run one person per browser.
Standing access	Approval limits which logins your integration can use, not how often. Whoever holds a valid token and the integration key can use every login the person granted, without the person present, until the grant ends.	Protect the token and key as one secret. Revoke the connection when the person disconnects or you suspect a compromise.
Several agents, one person	All of a person’s agents share one token and one integration key, so 1Password can’t keep one of your agents out of another’s logins.	Isolate agents yourself if your product needs it.
The approval link	It carries your request text as readable base64url JSON.	Don’t log it. Deliver it only over an authenticated, encrypted channel. Keep personal data out of request text.
Where a login is decrypted	A granted login is decrypted at fill time inside 1Password’s attested enclave, then filled by the extension in your browser.	Say “your platform and the model don’t handle the values”, not that credentials can never reach the agent’s environment.

Your security requirements

Every integration must meet these. Secrets

Never send OAuth tokens, integration keys, approval links, or credential values to a model.
Never put them in logs, error messages, analytics events, or query strings.
Keep the client secret, refresh token, and code verifier in your backend. Never expose them to browser code.
Keep the integration key in a per-user secret store, at least as protected as the refresh token, keyed on its connection path. Never put it in a browser image, extension storage, or your agent VM’s file system.

Browser sessions

Give each session a current access token and the integration key, in memory, and drop both when the task ends.
Run one person per browser environment.
Prevent the model from reading the page until fillCredential returns.
Don’t load extensions you don’t trust alongside 1Password.

Use of access

Use a credential reference only with the connection and access request that produced it.
Use a login only for the goal and reason the person approved.
If your product promises approval per session, create a new access request each session and don’t reuse old references.
Get the approval link in code, never through the model.

Connections

Validate state on every callback. Use PKCE with S256.
Store the integration key before anything else that can fail, then clear it from the URL.
Offer a Disconnect 1Password action that revokes the connection, and delete stored secrets only after revocation succeeds.
If you suspect your stored keys or tokens were exposed, revoke the affected connections and ask those people to connect again.

Report a security issue

Tell your 1Password contact right away if you find a vulnerability, suspect a key or token was exposed, or see behavior that doesn’t match this page.

​What 1Password guarantees

​What your integration must protect

​Your security requirements

​Report a security issue

What 1Password guarantees

What your integration must protect

Your security requirements

Report a security issue