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

# Frequently asked questions

> Answers to the questions partners ask most while building an Agentic Autofill integration.

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

<StatusBadge>Partner preview</StatusBadge>

These are the most common questions from partners building integrations. If yours isn't here, ask your 1Password contact in your shared Slack channel.

## Getting started

<AccordionGroup>
  <Accordion title="How is this different from giving my agent a service account?">
    A service account gives a program standing access to whole vaults, and the person has to set it up and hand you its token. With Agentic Autofill:

    * The person connects with a standard web OAuth flow at 1password.com. There's no token for them to create or paste.
    * The person approves specific logins, for a stated goal, in their 1Password app. Your integration can use only those.
    * With extension fill, your platform and the model never handle the values. The extension fills the page.
    * The person's items stay end-to-end encrypted, and your integration never holds their vault keys.
  </Accordion>

  <Accordion title="Do I need the 1Password app or a Linux client in my agent's environment?">
    No. There's no 1Password app to install on your side. You load the 1Password browser extension into the Chromium browser your agent drives and call it over CDP. Any VM or sandbox in your setup is your own. The integration works on any operating system with a Chromium build that supports extensions.

    The person does need a 1Password app on their own device, signed in to the account they connected, to approve requests.
  </Accordion>

  <Accordion title="Which accounts do I build and test with?">
    Test on 1password.com. Register your OAuth client in your company's 1Password Business account, and use a separate Individual or Family account in the US as your test user. An existing personal account works, or sign up for a new one. Don't use your Business account as the test user: Business accounts don't get the consent screen. The development environment, `b5dev.eu`, can't show approval prompts with current 1Password app builds. See the [Quickstart](/agentic-autofill/partners/quickstart).
  </Accordion>

  <Accordion title="Why do I need a Business account?">
    Only Business accounts can register OAuth clients. Register your client in your own company's Business account on 1password.com, and choose Business, not Teams. Keep the account active: the approval prompt looks up your client there. Your end users connect with their Individual or Family accounts.
  </Accordion>

  <Accordion title="Do I need to send 1Password my client ID?">
    No. The 1Password app reads your integration's name and icon from your OAuth client registration. See [Go to production](/agentic-autofill/partners/production#register-your-production-oauth-client).
  </Accordion>

  <Accordion title="Which 1Password app do I test approvals with?">
    1Password for Mac, Windows, or Linux on the Nightly release channel: **Settings** > **Advanced** > **Release channel** > **Nightly**. Sign it in to your test account on 1password.com, and open approval links on that computer. Mobile approval isn't available to test yet.
  </Accordion>

  <Accordion title="Where do I get the extension?">
    Use the development build of the 1Password extension that 1Password sends you, loaded unpacked or with the extension installation mechanism your browser stack uses. 1Password will announce in your partner channel when Agentic Autofill is in the Nightly, Beta, or Stable channel on the Chrome Web Store, and when to switch. See [Load the extension](/agentic-autofill/partners/fill#load-the-extension).
  </Accordion>

  <Accordion title="Can I use the SDK instead of the extension?">
    Start with the browser extension. If your product needs the SDK, for example to ask for access before a browser exists, contact 1Password for guidance before you build with it, so we can review our shared security model with you. See [Use the SDK](/agentic-autofill/partners/sdk).
  </Accordion>
</AccordionGroup>

## Connecting users

<AccordionGroup>
  <Accordion title="How do I know a person's 1Password address to build the authorize URL?">
    You don't need it. Everyone authorizes at `https://my.1password.com`. Don't ask the person for their account address. See [Base URLs and endpoints](/agentic-autofill/partners/connect#base-urls-and-endpoints).
  </Accordion>

  <Accordion title="Why do I land on the 1Password home page instead of the consent screen?">
    There are two common causes. The authorize path must be `/oauth/authorize`, with no `/v1`. At launch, the consent screen appears only for Individual and Family accounts. In development, it's also available for Business accounts.
  </Accordion>

  <Accordion title="Why didn't my callback include an integration key?">
    1Password returns an integration key only when it creates a new one: on a person's first consent, or their first consent after you revoked the connection. If the person connects again while their key is still active, the callback has no key. That's normal. Keep the key you stored. See [When you receive a key](/agentic-autofill/partners/keys-and-tokens#when-you-receive-a-key).
  </Accordion>

  <Accordion title="How do I get a fresh integration key while testing?">
    Revoke the connection from your backend with `self:revoke`, then connect again. The new consent returns a new key. A person can't revoke from inside 1Password, so there's no screen for it in the account. See [Disconnect a user](/agentic-autofill/partners/disconnect).
  </Accordion>

  <Accordion title="How do I match a returning person to the key I stored?">
    Key your storage on the connection `path` inside the integration key: it names one OAuth client, account, and user. The token response can include `user_id`. Compare it with the user in the stored key's path. If they don't match, the person connected a different account and you don't have a key for it: revoke and have them connect again. Treat token strings as opaque rather than parsing IDs out of them.
  </Accordion>

  <Accordion title="What if the person doesn't have a 1Password account yet?">
    Send them a [connect link](/agentic-autofill/partners/connect-links). In the browser, it starts a 1Password account sign-up with their name and email address filled in, and the verification email names your product. Sign-up doesn't connect the account to your product, so connect the person with the authorization URL after they finish. Connect links are in development: check availability with your 1Password contact.
  </Accordion>

  <Accordion title="Can a person connect from the 1Password app on their iPhone?">
    It's in development. A [connect link](/agentic-autofill/partners/connect-links) will open the consent screen inside 1Password for iOS, already signed in, and then return the person to your app. Until that ships, people connect in the browser.
  </Accordion>

  <Accordion title="Can my mobile app use a custom URL scheme or localhost as its redirect URI?">
    No. Redirect URIs must use `https`. Use a universal link or app link, or a web page that hands the result back to your app. Your callback also has to read the URL fragment in a browser, because the integration key arrives there.
  </Accordion>

  <Accordion title="Why does the token exchange return 400 invalid_request?">
    Most often because you sent `client_id` in the form body as well as the HTTP Basic header. Authenticate with HTTP Basic only. See [Token exchange and refresh](/agentic-autofill/partners/troubleshooting#token-exchange-and-refresh).
  </Accordion>

  <Accordion title="Should my cloud browser provider own the OAuth client, or should I?">
    Register and own your own OAuth client, and pass the token, integration key, and reference to whichever service fills. The connection then belongs to you, so you can use more than one browser provider, or switch providers, without asking people to connect again.
  </Accordion>

  <Accordion title="Where do I store the tokens and the integration key?">
    In your backend, in a per-user secret store, protected at least as well as a refresh token. Give a browser session only a current access token and the integration key, in memory, for the length of a task. See [Store keys and tokens](/agentic-autofill/partners/keys-and-tokens).
  </Accordion>
</AccordionGroup>

## Requests and approval

<AccordionGroup>
  <Accordion title="Why do access requests go through the extension instead of an HTTP API?">
    The extension packages everything a browser agent needs: create, wait, and fill, with no other component. There's no separate HTTP endpoint for access requests. If your product needs to create requests outside the browser, contact 1Password for guidance and a review of our shared security model.
  </Accordion>

  <Accordion title="Does the browser need to stay open while the person approves?">
    No. 1Password keeps the request. You can check its status later from a new browser session, with the same person's token and integration key. The status call returns right away, so you poll it. If you poll from the browser, keep one CDP session attached while you do.
  </Accordion>

  <Accordion title="Can approval happen in my app, or count the OAuth connection as approval?">
    No. Approving a login is cryptographic work that needs the person's vault key, and only their 1Password app holds it. That's what stops a compromise of your platform from creating grants. Connecting over OAuth lets you ask for logins; it doesn't grant any.

    Ways to approve from inside your own iOS or Android app, still with 1Password doing the approval, are in development. Ask your contact if you're building a mobile app.
  </Accordion>

  <Accordion title="Does the person have to approve every time? Can they approve in bulk or share a vault with the agent?">
    The person approves once per login, not once per fill. After approval, your agent can fill that login as often as tasks need, for the life of the grant. To keep prompts down, batch every login a task needs into one request, and reuse references you already hold.

    Shared vaults aren't supported at launch, and wouldn't remove the approval step: approval is where the person's app gives your integration the keys for a specific item, wherever it lives.
  </Accordion>

  <Accordion title="How long does an approval last? Does it end with the chat session?">
    At launch, a grant stays valid for 30 days, and configurable lifetimes are planned. A grant isn't tied to a chat session. If your product promises approval per session, create a new request each session and don't reuse old references. See [How long a grant lasts](/agentic-autofill/partners/approval#how-long-a-grant-lasts).
  </Accordion>

  <Accordion title="Can my agent run scheduled or background tasks?">
    Yes, within a grant's lifetime. Fills don't involve the person or their 1Password app, so an agent can fill an approved login while the person is away. When a grant ends, the person has to approve again. Longer-lived access for scheduled jobs is planned.
  </Accordion>

  <Accordion title="Is mobile approval supported?">
    Not yet. Approval works today in 1Password for Mac, Windows, and Linux on the Nightly release channel. Approval in the 1Password mobile apps, and from inside your own mobile app, are in development. The person's 1Password app must be signed in to the account they connected.
  </Accordion>

  <Accordion title="Where does the approval prompt get my name and icon?">
    From your OAuth client registration. The consent screen and the approval prompt both show the name and icon you entered when you created the client. You can't add an icon after a client is created, so if you registered one without an icon, register a new client.
  </Accordion>

  <Accordion title="What if the person picks a different login than I asked for, or grants nothing?">
    The result may not match your entries one to one. A requested entry may have no corresponding grant because the person granted nothing for it, and a granted login can have no `entryId` because the person added one you didn't ask for. Match on `entryId`, never on position. See [Read what the person granted](/agentic-autofill/partners/approval#read-what-the-person-granted).
  </Accordion>

  <Accordion title="Is the request text end-to-end encrypted?">
    Not at launch. The goal, reasons, keywords, and websites travel to the person's 1Password app inside the approval link, as readable base64url JSON. Treat the link as sensitive, and keep personal data out of request text. Encrypting these fields is planned.
  </Accordion>
</AccordionGroup>

## Filling

<AccordionGroup>
  <Accordion title="What do I get from 1Password, and how does it reach the extension?">
    You get a reference for each granted login, a string such as `//api.1password.com/credential-broker/accounts/<account>/capability/login/configurations/<id>`. It's a pointer, not a credential and not an encrypted payload, and you don't transport any secret material. When you call `fillCredential` with the reference, the extension fetches the login from 1Password's credential broker over an attested, encrypted session, fills the form, and submits it. See [Security model](/agentic-autofill/partners/security#what-1password-guarantees).
  </Accordion>

  <Accordion title="What does the browser need, and can I give it a short-lived key instead?">
    Every extension call takes a current access token and the integration key. There's no narrower session key yet. Pass both from your backend when a task starts, keep them in memory, and drop them when it ends. The access token expires after 15 minutes. The refresh token and client secret never go to the browser.
  </Accordion>

  <Accordion title="Does this work with cloud browser providers?">
    Yes. It works with any Chromium browser, remote or local, that can load an unpacked extension and give you a CDP connection. Load the extension when you create the browser, and run one person per browser. If your provider drives the browser through its own automation API, you still need a CDP connection for the extension calls.
  </Accordion>

  <Accordion title="What is Agentic Mode, and do I have to turn it on?">
    Yes. Agentic Mode stops normal 1Password browser behavior, such as inline suggestions and save prompts, from exposing the person's state in pages your agent controls. Turn it on with `api.agenticMode.v1.enable` every time your agent starts working in the browser, for one tab or the whole browser. A fill in a tab it doesn't cover fails with `agenticModeNotEnabled`. See [Turn on Agentic Mode](/agentic-autofill/partners/fill#turn-on-agentic-mode).
  </Accordion>

  <Accordion title="Do I have to disconnect my agent from the browser during a fill?">
    You have to make sure the model and agent can't read the page until `fillCredential` returns, because the values are in the page between fill and submit. How you do it is up to you. If the browser runs on a different machine from the model, holding agent actions until the call returns is enough. A lock in your orchestrator that blocks DOM reads, screenshots, and other CDP commands to the tab also works.
  </Accordion>

  <Accordion title="Are passwords or codes left on the page after a fill?">
    No. When `fillCredential` returns `fill_submitted`, the form was submitted and the filled values are no longer present on the page. When it returns `fillFailed` or `autosubmitFailed`, 1Password clears what it filled before it returns.
  </Accordion>

  <Accordion title="Does fill_submitted mean the agent is signed in?">
    No. It means 1Password filled and submitted the form. The website may still reject the login or ask for another step. Check the page after the call returns.
  </Accordion>

  <Accordion title="Can several of my agents use one person's access?">
    Yes, but 1Password doesn't distinguish between them: they share one token and one integration key. If agent A mustn't use logins granted for agent B's task, enforce that in your system, for example by storing references per task and letting each agent use only its own.
  </Accordion>

  <Accordion title="Can I keep the token and integration key out of the agent's browser entirely?">
    Not at launch. Every extension call takes both. Keep them in memory for the length of a task, and keep the model off the page during fills. 1Password is looking at ways to keep them out of the agent's browser.
  </Accordion>
</AccordionGroup>

## Scope and roadmap

<AccordionGroup>
  <Accordion title="What's supported at launch?">
    Individual and Family accounts on 1password.com in the US, the person's own vault, and logins with a username, password, and one-time password, filled into Chromium browsers. See [What's supported](/agentic-autofill/partners#supported-today).
  </Accordion>

  <Accordion title="Are passkeys or social sign-in supported?">
    Not at launch. Both are planned.
  </Accordion>

  <Accordion title="Can people connect Business accounts, or use shared vaults?">
    Not at launch. Business accounts, shared vaults, and admin controls over agent access are planned. Tell your contact which of these your product needs and why.
  </Accordion>

  <Accordion title="Can I revoke access to a single login?">
    Not at launch. Revocation ends the person's entire connection. To stop using one login, stop filling it and drop its reference. See [Disconnect a user](/agentic-autofill/partners/disconnect).
  </Accordion>

  <Accordion title="Can a person revoke access from inside 1Password?">
    Not at launch. The person disconnects from your product, so make **Disconnect 1Password** easy to find.
  </Accordion>

  <Accordion title="Can I use this outside the browser, for example in CLI tools?">
    Your agent uses 1Password through the browser extension. If your product needs credentials outside a browser, contact 1Password for guidance and a review of our shared security model before you build with the SDK.
  </Accordion>
</AccordionGroup>

## Going to production

<AccordionGroup>
  <Accordion title="When can I test with real 1Password accounts?">
    Now. Production is live: OAuth connect, token exchange, refresh, and revoke work on 1password.com, and approval works in the 1Password desktop app on the Nightly release channel. Tokens and integration keys from the development environment don't work on production, so connect your test user again and store the new key.
  </Accordion>

  <Accordion title="Why can't I see OAuth Application or the Read credentials scope in my production account?">
    The person creating the client must be an owner, an administrator, or in the Security group, and 1Password has to turn the feature on for your account. Send your contact an admin's email address. After it's on, sign out and back in. See [Accounts and setup](/agentic-autofill/partners/troubleshooting#accounts-and-setup).
  </Accordion>

  <Accordion title="Can I register redirect URLs for my staging and development environments?">
    You enter the redirect URL yourself when you create the OAuth client. Register a separate client for each of your own environments, each with its own redirect URL.
  </Accordion>

  <Accordion title="I registered my production client without an icon. What do I do?">
    Register a new client with an icon: PNG, JPEG, or GIF, up to 1 MB. You can't add an icon after a client is created.
  </Accordion>
</AccordionGroup>


## Related topics

- [Authorize SSH requests with 1Password](/ssh/agent/authorization.md)
- [Manage SSH Bookmarks in 1Password (beta)](/ssh/bookmarks.md)
- [Upgrade to 1Password CLI 2](/cli/upgrade.md)