> ## Documentation Index
> Fetch the complete documentation index at: https://www.1password.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Security model

> How Agentic Autofill protects logins, what your integration must protect, and the security requirements it must meet.

export const StatusBadge = ({children}) => <span className="op-status-badge not-prose">{children}</span>;

<StatusBadge>Partner preview</StatusBadge>

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](https://aws.amazon.com/ec2/nitro/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](https://noiseprotocol.org/). 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.


## Related topics

- [About 1Password Connect Server security](/connect/security.md)
- [1Password Service Account security](/service-accounts/security.md)
- [1Password SDK local integration security](/sdks/desktop-app-integrations.md)