Document 1Password Agentic Autofill for vault credentials

[rgarcia]

Summary

Adds vaults/1password.mdx ("1Password Agentic Autofill"), a page that covers using 1Password Agentic Autofill in a Kernel browser, with KERNEL-hosted collection as the fallback:

• KERNEL-hosted collection: a short summary that links to the existing credential item and fill docs instead of repeating them.

• 1Password brokered approval: a credential item with provider: "1password", built on 1Password Agentic Autofill and linked to 1Password's partner docs. The page is organized around two OAuth client choices:

  • KERNEL-managed OAuth client: create a credential_account to link the user's account, create a credential referencing it by item key (account), then request access and run 1pw_fill once the user approves. KERNEL runs the OAuth flow, stores the connection, and refreshes its tokens. 1Password's consent screen and approval prompt show KERNEL.
  • Your own OAuth client: you run account linking yourself (redirect URI, PKCE, integration key capture, token exchange, refresh, revocation), with links to the matching 1Password guides. Create a credential holding the access_token and integration_key (encrypted, never returned) with optional access_token_expires_at. Before each task, refresh the token on your backend and send it with 1pw_update_access_token, which keeps the integration key, requests, and pending or approved state.

• Choosing between them: the page tells integrators to ask the end user whether they want to use 1Password. If they do, link the account and request the login through 1Password; if they don't, or that path fails (declined consent, declined or failed access request, repeated fill failures, unsupported account), fall back to a KERNEL-hosted credential item. It also calls out 1Password's API limits: the login must be in a private, non-shared vault, and passkeys aren't supported. The vaults overview and credential item pages repeat the fallback.

The brokered section also covers:

• Requests: one to five login entries, with entry_id on 1pw_fill when several approved entries share the page origin.
• Access requests: 1pw_create_access_request (the 1Password extension loads into the browser on demand), the native approval link, and 1pw_access_request_status.
• Fill: the extension fills and submits the form, and clears what it filled if it can't submit (per 1Password's docs). Covers outcomes, origin checks, and calling 1pw_fill again on each page of a multi-page sign-in, including a later one-time password page. A note says the browser is locked while 1pw_fill runs: inbound control surfaces such as CDP and browser API calls are blocked.
• Grant lifetime: per 1Password's docs, grants last 30 days at launch and end sooner if the connection ends (about 90 days at most); approval prompts close after 2 minutes. The item stays ready after a grant ends, so asking again means a new credential item. Links to 1Password's grant and connection lifetime sections.
• Failures and cleanup: an access request with an uncertain outcome stays blocked and must not be retried automatically. Also covers account-link recovery with 1pw_recover, deletion order, and limitations.

It also links the page from the vaults overview and nav, and adds a note to the Managed Auth 1Password page that separates the two integrations.

Also adds provider: "kernel" to the existing credential create samples in vaults/credentials.mdx and snippets/collect-browser-credentials.mdx. The generated SDK types require the field. The API still treats a create without provider as kernel, so existing integrations and the CLI example keep working. Update samples are unchanged because updates don't accept provider.

Written against an unmerged API change

• Source: the in-progress kernel/kernel API change for 1Password vault items. Don't merge this until that ships.
• SDK: no SDK preview exists yet for the latest revision of that change. Samples were typechecked against the newest available preview, whose vault item types match except for the stored-token fields and 1pw_update_access_token. Re-typecheck against the first published SDK release that includes 1Password vault items.

Testing

• Typecheck: extracted every TypeScript and Python block from vaults/1password.mdx, vaults/credentials.mdx, and the collect and fill snippets. tsc --strict and pyright report 0 errors against the newest available preview, except for the two stored-token blocks.
• Stored-token blocks: they fail only on the fields that preview lacks. Their request bodies validate against the current OpenAPI schemas from the API change, and so do the account-key, multi-entry, and entry_id bodies. The same schemas reject account_id, six entries, and customer_managed clients.
• Negative checks: a Kernel create without provider fails typechecking.
• Links: mint broken-links finds none.
• Rendering: in mint dev, /vaults/1password, /vaults/credentials, /vaults/overview, and /auth/fill-from-vault return 200 and contain no preview-build or TODO text. No visual screenshot was taken.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
Kernel	🟢 Ready	View Preview	Sep 30, 2026, 3:31 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[cursor]

Risk assessment: Very Low

I reviewed the diff (4 files, +552/−1). Every change is documentation for the Mintlify site:

• docs.json adds vaults/1password to the vaults sidebar.
• integrations/1password.mdx adds a note that links to the new page.
• vaults/overview.mdx adds a short availability note and a related link.
• vaults/1password.mdx is a new page: prose, tables, and TypeScript/Python SDK samples.

Nothing here changes runtime code, auth, permissions, infrastructure, CI, schemas, or model-instruction files. The main branch ruleset does not require code owner review, and this PR had no existing approval.

Approving as Very Low risk.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 01f93d9. Configure here.}

[cursor]

Risk assessment: Very Low

Re-evaluated after 1f2e679 ("Shorten 1Password page description"). The existing approval from this automation still applies, so I am not approving again.

The new commit changes one frontmatter line in vaults/1password.mdx: the page description is shortened to a single sentence. The rest of the PR is unchanged from the previously approved commit.

Full diff vs main (4 files, +552/−1) is still Mintlify documentation only:

• docs.json adds vaults/1password to the vaults sidebar.
• integrations/1password.mdx adds a note linking to the new page.
• vaults/overview.mdx adds a short availability note and a related link.
• vaults/1password.mdx is a new page of prose, tables, and TypeScript/Python SDK samples.

No runtime code, auth, permissions, infrastructure, CI, schemas, or model-instruction files changed. The main ruleset does not require code owner review. Risk did not increase, so the existing approval stands.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[cursor]

Risk assessment: Very Low

Re-evaluated after 10eff0f (“Send provider kernel in credential create samples”). The existing approval from this automation still applies, so I am not approving again.

The new commit stays inside Mintlify docs:

• snippets/collect-browser-credentials.mdx and vaults/credentials.mdx add provider: "kernel" to the TypeScript and Python credential-create samples, plus a sentence that points at the 1Password page.
• vaults/1password.mdx moves the unreleased-SDK note from a rendered <Note> into a hidden comment.

Full diff vs main (6 files, +555/−2) is still sidebar config, prose, tables, and SDK samples. No runtime code, auth, permissions, infrastructure, CI, schemas, or model-instruction files changed. The main ruleset does not require code owner review. Risk did not increase, so the existing approval stands.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[cursor]

Risk assessment: Very Low

Re-evaluated after 046ae70 (“Update 1Password docs for renamed access request operations”). This automation already approved the PR, and the new commit does not raise the risk, so I am not approving again and I am not dismissing the existing approval.

The new commit stays inside Mintlify docs (vaults/1password.mdx, vaults/credentials.mdx, snippets/collect-browser-credentials.mdx):

• Operation names in prose and samples change from 1pw_request_access / 1pw_poll_access to 1pw_create_access_request / 1pw_access_request_status.
• Fill, recovery, and isolation wording is tightened (fill might submit; the extension is not removed after use).
• Credential-create copy notes that a missing provider still defaults to kernel.

Full diff vs main is still 6 documentation files: sidebar config in docs.json, a cross-link note, prose, tables, and TypeScript/Python samples. No runtime code, auth, permissions, infrastructure, CI, schemas, or model-instruction files changed. The main ruleset does not require code owner review (require_code_owner_review is false) and does not dismiss stale reviews on push. Risk did not increase, so the existing approval stands.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[cursor]

Risk assessment: Very Low

Re-evaluated after b8d0c24 (“Update 1Password docs for account keys, stored tokens, and multi-entry fill”). This automation already approved the PR, and the new commit does not raise the risk, so I am not approving again and I am not dismissing the existing approval.

The new commit changes only Mintlify docs:

• vaults/1password.mdx rewrites the brokered-approval page: connected-account vs stored access_token / integration_key, multi-entry requests, entry_id on 1pw_fill, and updated limitation wording. Samples stay TypeScript and Python inside the docs page.
• vaults/credentials.mdx updates a hidden maintainer comment that records which SDK preview the samples were checked against.

Full diff vs main is still 6 documentation files (docs.json sidebar entry, cross-links, prose, tables, and SDK samples). No runtime code, auth or permissions implementation, infrastructure, CI, schemas, or model-instruction files changed. The main ruleset does not require code owner review (require_code_owner_review is false) and does not dismiss stale reviews on push. Risk did not increase, so the existing approval stands.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[cursor]

Risk assessment: Very Low

Re-evaluated after ce08ff9 (“Trim autofill lock note and remove preview pins from 1Password docs”). This automation already approved the PR, and the new commit does not raise the risk, so I am not approving again and I am not dismissing the existing approval.

The new commit changes only Mintlify docs:

• vaults/1password.mdx removes a hidden maintainer comment and shortens two sentences about what 1pw_fill blocks (CDP and browser API calls). The surrounding limitation still tells readers to use a dedicated browser and not to give untrusted automation access to it.
• vaults/credentials.mdx shortens a hidden maintainer comment about the provider field. The published sentence and the provider: "kernel" samples are unchanged.

Full diff vs main is still 6 documentation files (docs.json sidebar entry, cross-links, prose, tables, and SDK samples). No runtime code, auth or permissions implementation, infrastructure, CI, schemas, or model-instruction files changed. The main ruleset does not require code owner review (require_code_owner_review is false) and does not dismiss stale reviews on push. Risk did not increase, so the existing approval stands.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[AnnaXWang]

current wording understates the browser lock’s importance and should explain our security boundary

Can we describe it as “exclusive browser control during autofill” and explain the observable behavior:

• new customer CDP, WebDriver, and browser api requests receive 423 Locked
  existing proxied control connections are interrupted, not paused; clients may need to reconnect
• only KERNEL’s authenticated autofill connection can control the browser until 1pw_fill returns
• The current note at vaults/1password.mdx:620–624 is too vague. It also omits an important boundary: the lock covers KERNEL’s proxied control paths, not page scripts, other extensions, or live-view/out-of-band input.

Does live-view input remain possible during fill? If yes, we should disable it or call this exclusion out in our docs.

Suggested copy:

while 1pw_fill runs, KERNEL gives the autofill operation exclusive control of the browser. new CDP, WebDriver, and browser api requests are rejected, and existing control connections are interrupted. reconnect after the call returns.

this prevents concurrent automation from reading the page while credential values are present. it does not isolate credentials from the destination page, its scripts, or other extensions in the browser.

Also, add a short “how credentials are protected” section near the top, before the OAuth-client choices. Explain the lifecycle:

• the user chooses the exact login to grant in 1Password
• KERNEL stores encrypted connection material and credential references, not the login values
• the 1Password extension fetches the credential and fills it; KERNEL’s api returns status, never values
• KERNEL verifies that the destination shares the approved login’s origin
• KERNEL locks the browser while values are temporarily in the page
  on fillFailed or autosubmitFailed, the extension clears filled values before returning
• the destination website necessarily receives the credential, and its scripts can observe it
• use one user per dedicated browser and do not load untrusted extensions

[rgarcia]

@AnnaXWang addressed your review summary in 4368c6e:

• browser lock: the note in "fill and submit" now uses your copy under "exclusive browser control during autofill". It says new CDP, WebDriver, and browser API requests get 423 Locked, existing control connections are interrupted rather than paused, clients reconnect after the call returns, and only KERNEL's autofill connection controls the browser until 1pw_fill returns. It also says the lock doesn't isolate credentials from the destination page, its scripts, or other extensions.
• live view: yes, live view input is still possible during a fill. The lock covers the CDP, WebDriver, and browser API proxy paths, not live view. The note now says so explicitly and tells readers not to share live view with anyone who shouldn't see the login. Actually disabling live view during a fill would be an API change, so it's out of scope for this docs PR.
• how credentials are protected: added this section before the OAuth-client choices, with the lifecycle bullets you listed.