> ## 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.

# How Agentic Autofill works

> The components of an Agentic Autofill integration, what the person sees, and what each party holds.

Partner preview

An integration runs across the person's device, your infrastructure, and 1Password's services. Your agent never holds credential values. It holds references to logins the person approved, and the 1Password extension uses those references to fill forms.

## The parts

```mermaid theme={null}
flowchart LR
    subgraph device["The person's device"]
        direction TB
        yourapp["Your app"]
        opapp["1Password app"]
    end
    subgraph infra["Your infrastructure"]
        direction TB
        backend["Your backend"]
        agent["Your agent"]
        ext["1Password extension<br/>in your agent's browser"]
    end
    subgraph onep["1Password"]
        direction TB
        web["1Password on the web"]
        api["1Password API"]
    end
    backend <--> yourapp
    yourapp -->|"opens link"| opapp
    backend -->|"tokens, revoke"| api
    agent -->|"CDP"| ext
    ext -->|"requests, fills"| api
    opapp -->|"approve"| api
    yourapp -.->|"connect once"| web
    style device fill:transparent,stroke:#949494
    style infra fill:transparent,stroke:#949494
    style onep fill:transparent,stroke:#949494
```

| Part | Built by | What it does |
| - | - | - |
| Your app | You | Where the person talks to your agent. Starts the connection flow, shows an approval button, and displays results. It can be a mobile app, a web app, or a chat surface. |
| Your backend | You | Holds your OAuth client secret and, for each user, the tokens and the integration key. Exchanges and refreshes tokens, and revokes the connection when the user disconnects. |
| Your agent's browser | You, or a cloud browser provider | A Chromium browser with the 1Password extension loaded. Your agent drives it. Your code calls the extension over the Chrome DevTools Protocol (CDP). |
| 1Password extension | 1Password | Exposes `api.agenticAutofill.v1` and `api.agenticMode.v1` on its service worker: create a request, check the decision, turn on Agentic Mode, fill. Shows no 1Password interface in pages it controls in Agentic Mode, and needs no sign-in. |
| 1Password on the web | 1Password | Where the person signs in and approves the consent screen when they connect. It can also show the approval prompt in a popup opened by your web app. See [Approve in the browser](/agentic-autofill/partners/browser-approval.md). |
| 1Password app | 1Password | Opens the approval link, shows the request, and creates the grant for each login the person approves. |
| 1Password API | 1Password | Issues OAuth tokens, tracks access requests, and delivers granted logins to the extension. |

## What the person sees

**1. Setup**

The person turns on the 1Password connection in your app. A one-time web flow opens: they sign in at 1password.com and approve a consent screen that lists what your integration can and can't do. After that you can send them access requests, but you can't read any of their items.

**2. The agent asks for logins**

The person asks your agent to do something that needs a sign-in. Your agent creates an access request, and your app shows an approval button. When the person taps it, their device switches to the 1Password app. If 1Password is locked, they unlock it with Face ID, Touch ID, or their account password.

1Password shows which integration is asking, the goal of the task, and suggested logins for each website. The person picks the logins to share, approves, and lands back in your app.

**3. The agent finishes the task**

Your agent fills the approved logins for the rest of the task. It works in the background and needs nothing more from the person. 1Password doesn't need to be running or unlocked on their device.

Approval is the last step that requires the person's attention. After they approve, they can close 1Password or lock their device.

## A task from request to fill

```mermaid theme={null}
sequenceDiagram
    participant Agent as Your agent
    participant Ext as 1Password extension
    participant App as Your app
    participant OPApp as 1Password app
    participant OP as 1Password API

    Agent->>Ext: createAccessRequest
    Ext->>OP: Register request
    Ext-->>Agent: accessRequest, appLink
    Agent->>App: Send appLink, not through the model
    App->>OPApp: Person taps, unlocks, approves
    OPApp->>OP: Create a grant per login
    loop On the polling schedule, while pending
        Agent->>Ext: getAccessRequestStatus
        Ext-->>Agent: state
    end
    Note over Agent,Ext: resolved, with a reference per granted login
    Agent->>Ext: agenticMode.enable(tabId)
    Agent->>Ext: fillCredential(reference, tabId)
    Ext->>OP: Fetch the granted login
    Ext->>Ext: Fill and submit the form
    Ext-->>Agent: fill_submitted
```

Your agent makes these calls through the extension. If your product needs to make them outside the browser, such as before a browser exists, contact 1Password to review the security requirements. See [Use the SDK](/agentic-autofill/partners/sdk.md).

## Why approval happens in the 1Password app

Every item in a 1Password account is end-to-end encrypted, and 1Password's servers can't decrypt a stored item on their own. Approving a login is cryptographic work: the person's 1Password app uses keys only it holds to make that one login usable by your integration and no one else.

That has two consequences:

* Nothing you hold can create a grant. Your tokens and integration key let you ask for logins and use the ones the person approved. They can't add a login the person didn't approve.
* The person needs a 1Password app on their device, signed in to the account they connected, to respond to your requests.

## What approval covers

Approval covers the logins the person selected for use by your integration. It isn't tied to a chat session, and one approval can authorize multiple fills, including multi-page sign-ins.

* If your product promises approval per session, enforce it yourself: create a new access request for each session, and don't reuse references from an earlier one.
* At launch, a grant lasts 30 days. It ends sooner if you disconnect the person or their connection expires. When a fill fails because access ended, create a new access request.

## What each party holds

| Item | Where it lives | Used for |
| - | - | - |
| OAuth client secret | Your backend | Token exchange and refresh |
| Access token | Your backend. In memory in the browser session during a task. Expires after 15 minutes. | Every extension call, and revocation |
| Refresh token | Your backend only | Getting new access tokens. It rotates on every use. |
| Integration key | Your backend secret store, per user. In memory in the browser session during a task. | Every extension call. Only you hold it. |
| Access request and entry IDs | Your storage | Checking status and matching grants to what you asked for |
| Credential reference | Your storage | Filling one granted login. It's a pointer, not a credential. |
| Login values | The person's vault, end-to-end encrypted | Decrypted for a fill inside 1Password's attested enclave and handed to the extension, which fills the page |

See [Store keys and tokens](/agentic-autofill/partners/keys-and-tokens.md) for handling rules, and [Security model](/agentic-autofill/partners/security.md) for the protections 1Password provides and the responsibilities your integration retains.


## Related topics

- [1Password Environments MCP Server](/environments/mcp-server.md)
- [Autofill public keys](/ssh/public-key-autofill.md)
- [Secure secrets for AI agents and tools](/get-started/secure-ai-access.md)