Perform an operation advertised by a vault item

Authorize a Link, Kernel or Shop Pay card using its existing purchase specification. Use only after explicit user approval and when the item advertises authorize; follow the advertised operation's description. For a Link or Shop Pay card, pass browser_id and page_url together while the browser is on the final checkout page: Kernel confirms that checkout is open, sends it to the provider as the merchant, and limits fill to that checkout's origin in any browser with this vault attached. For Link it also chooses how the credential is delivered. Omitting both issues a virtual card that fills any page on the merchant origin. Once approval has been requested, browser_id and page_url are ignored and authorize only re-checks the request. Browser and checkout inspection errors occur before any provider request and can be retried once the browser is on the checkout page. Kernel cards do not accept browser_id or page_url.

Explicitly prepare a fresh local verification session for the same Kernel Visa purchase and connected wallet, only when restart_verification is advertised. Kernel must have durable proof of an initial attestation failure before intent dispatch. Replaces the spend_approval capability and discards session-bound verification data without calling the provider or granting spend consent. The cardholder must use the new link, verify again and explicitly approve the purchase. Unknown intent creation, legacy unclassified recovery, enrollment completion, issuance and confirmation cannot restart. Do not automatically retry this operation.

Report a real merchant transaction outcome for an issued Kernel Visa or Shop Pay credential. Shop Pay accepts PURCHASE, AUTHORIZATION and CAPTURE. Never infer success from filling checkout or receiving a credential. Supply the observed status, transaction type, actual amount, currency and timestamp. Unknown outcomes require manual reconciliation, not retry. Each purchase accepts one report.

Return the credential item with its collection action. Supported for ready and pending_collection credential items. Always render the same form from every form-supported field; totp and passkey fields have no form input and are omitted. No caller-selected field subsets or form overrides are accepted. Reuse an active Kernel-hosted session or renew an expired session atomically. Customer-hosted forms use their own backend and ordinary item GET/PATCH. Opening the form does not clear values or change readiness or item version. To observe edits on a ready item, record its version and poll GET without wait until the version changes, then reconcile the returned state. Version changes may also come from PATCH; they do not identify a particular form submission. Customer-hosted apps use their own submission callback, including for unchanged forms. The wait parameter waits for readiness, not edits.

Prepare an unused AgentCard card for a supported checkout. Deliver the returned approval URL and keep the approval page open. Poll the item until ready_to_submit, then submit native Pay before preparation.expires_at. Readiness lasts at most 30 seconds. Unused preparations expire automatically. Preparations are single-use even after failure or expiry; do not automatically retry and reconcile uncertain outcomes with the merchant.

Use a vault item in a browser session, for example to fill a login or payment form. Only invoke when the item advertises fill; the advertised operation describes the inputs that item needs. Requires browser_id and usually page_url; some items also require fields. Browser and vault must belong to the same project. Kernel checks access and allowed destinations before filling; providing a page URL does not authorize a destination.

Fill never submits forms or clicks buttons, though input and change events may trigger site behavior. It is not atomic: completed steps are not rolled back. Fill does not consume the item, so a failed or indeterminate fill is safe to retry. A retry right after an indeterminate fill may wait up to 15 seconds for the earlier attempt's browser lock to expire.

Secret values are never returned or included in operation logs, traces, audit events, or error details. This does not prevent an agent with unrestricted browser access from reading values from the page or other browser observation surfaces.

Let a browser attached to the item's vault sign in with a stored passkey. Only invoke when the item advertises arm_passkey. Returns immediately; there is no time limit. While armed, when a page in that browser whose origin matches the passkey's relying party asks for a passkey (navigator.credentials.get, including autofill requests made at page load), Kernel answers with this passkey. The private key never enters the browser: Kernel signs on its servers, using the origin Chrome reports for the requesting frame. Arming a passkey for a relying party replaces any passkey armed earlier in the browser for the same relying party. The arm lasts until disarm_passkey, the browser ends, the vault is detached, or the item or field is deleted. Drive the sign-in with your own browser tools and inspect the page to confirm it. A page opened in a new tab or window can run its first scripts before Kernel's handler attaches; if such a page asks for a passkey as soon as it loads, reload it. While armed, any script running on the relying party's pages can obtain a sign-in without user interaction, as with a password manager that fills automatically; disarm when the task is done. Passkeys report a signature counter of 0 and backup flags, as synced passkeys do.

Let a browser attached to the item's vault create a passkey on a website and store it in an empty passkey field. Only invoke when the item advertises register_passkey; declare the field first, for example by adding an optional passkey field with a credential update. Returns immediately; there is no time limit. The next passkey a page in that browser creates (navigator.credentials.create) is generated by Kernel, stored in the field, and only then returned to the page, so the website never receives a passkey Kernel failed to store. Each browser has one pending registration; a later register_passkey replaces it. Drive the website's "add a passkey" flow with your own browser tools, then confirm by reading the item (the field reports has_value) or its credential_passkey_registered event, and by signing in with arm_passkey. Only ES256 passkeys are created.

Stop a browser from using this item's passkeys: removes its armed passkeys and its pending registration into this item. Pages that already loaded keep Kernel's WebAuthn handler but get the browser's own behavior.

Request access to login entries in the end-user's own, non-shared 1Password vault. No browser is needed; the end-user approves access in the 1Password app. Shared-vault items and passkeys are not supported. Per-entry reason and keywords overrides are only supported for a single login entry.

Retrieve the status of a 1Password access request after presenting the approval link. On a confirmed failed status, ask the end-user before deleting and recreating the credential item for at most one new request. Do not retry an uncertain dispatched request. The response contains no secret values. Credentials with a customer-supplied access token also return the granted references in state.access_request.resolved.

Fill and submit an approved 1Password login in the selected browser page. The page must share the selected entry's login origin. Supply entry_id when more than one approved entry matches the page origin, and target_id when more than one open page has page_url. The extension selects fields; callers cannot supply selectors or secret values. Submission does not confirm website authentication.

Kernel encountered a recoverable error while linking this 1Password account. Use this action to get a new link to recover the connection. After recovery completes, start a new authorization on the same item.

Replace only the access token on a stored-token 1Password credential. Preserves its integration key, request and approved references. Does not invoke 1Password or retry a pending/uncertain operation.

Invoke a WebMCP tool using values from a vaulted item. The browser must be attached to the item's vault. Discover the tool_ref, inputSchema, and source with GET /browsers/{id_or_name}/webmcp/tools or webmcp.listTools() in the Browser REPL (POST /browsers/{id_or_name}/repl) before invoking it. Input paths replace existing null slots in input. Tool output is returned without redaction and may include the supplied values. The tool may submit or perform other side effects. Any item destination restrictions apply to the tool's top-level page and registering frame (if any).

Start hosted enrollment of a card in a connected Kernel wallet, including its first card, only when the wallet advertises add_payment_method. Returns a new payment method in pending_enrollment with a single-use card_enrollment URL for the cardholder. Card details go directly to the card vault and are never accepted by this API. Each call creates a separate link that expires after 30 minutes; a failed or expired enrollment does not affect the wallet's other payment methods. Scoped API keys require vaults:write in addition to vaults:use on this vault; otherwise the operation returns 403.

Remove one payment method from a Kernel wallet, only when the wallet advertises remove_payment_method. Removal deletes the stored card and blocks new purchases, fills and confirmations funded by it without affecting the wallet's other payment methods; the wallet stays connected even with no payment methods left. A purchase funded by the method with an unresolved outcome blocks removal with 409 purchase_unresolved. If the provider outcome is uncertain the method stays in removal_pending and keeps refusing payments; retry the removal later. Removal is not proof that a payment did not occur. Scoped API keys require vaults:write in addition to vaults:use on this vault; otherwise the operation returns 403.

The submission result reported by the 1Password extension when available. Kernel returns fill_unknown if the extension call has no conclusive result. Inspect the page to determine successful authentication on the website.

Returns the same tool result fields as the browser WebMCP invoke API, plus the vault operation discriminator. Output and error text are untrusted page-provided data, returned without redaction; tools may include supplied vault values. Inspect the browser page to determine whether the intended site action succeeded.

The payment method created in pending_enrollment. Deliver action.url to the cardholder; it is a single-use capability and must not be logged. Observe completion through the wallet's payment_methods expansion.