Skip to main content
keep an existing credential vault as your source of truth while using KERNEL to fill browser forms. this is the credential-source setup for Fill from Vault: your trusted backend reads the source credential, copies it into a KERNEL credential item, and updates or deletes that copy as the source changes.
fill doesn’t currently read directly from a third-party vault or accept a provider reference in a fill request. KERNEL stores an encrypted copy of the values. Your backend is responsible for synchronization and deletion.

​
How it works

1

Read the Source Credential

read the credential with the third-party vault’s server-side sdk. Keep provider tokens and returned values in your trusted backend.
2

Copy It into a Credential Item

create a KERNEL credential item with the same field names and values. Mark secrets and any identifiers that don’t need a read path as sensitive.
3

Fill an Attached Browser

attach the KERNEL vault when you create the browser, then invoke fill with field names and selectors. The fill request and response don’t contain the stored values.
4

Synchronize Its Lifecycle

update the KERNEL item after the source rotates. Delete the KERNEL item when your retention policy no longer permits KERNEL to hold the copy.

​
Copy a credential

use the canonical copy values from an existing vault example for TypeScript and Python. it reads an account credential from aws secrets manager, validates it, and copies it into a KERNEL credential item. the same trusted-backend boundary applies to other providers.

​
Synchronize rotations

run synchronization from your backend after the source vault rotates, or immediately before a workflow that requires a fresh value. follow read and update values for the canonical TypeScript and Python examples, immutable item identity checks, version preconditions, collection-session invalidation, and conflict handling. KERNEL doesn’t poll the source vault. If the source is unavailable, don’t replace the KERNEL item with empty or partial values. Decide whether your policy permits the last copied value to remain usable before starting the browser workflow.

​
Coordinate deletion

deleting or revoking the source credential doesn’t delete its KERNEL copy. Delete the KERNEL credential item when:
  • the source credential is deleted or access is revoked.
  • the end user disconnects the source vault.
  • the workflow no longer needs the credential.
  • your retention policy no longer permits KERNEL to store the copy.
Keep the source credential’s immutable identifier alongside the KERNEL vault and item ids in your backend. Use that mapping for authorization, rotation, and deletion without putting credential values in application logs or metadata.

​
Compare with Managed Auth and 1Password

KERNEL’s 1Password integration is specific to Managed Auth. Managed Auth retrieves matching values from 1Password when it authenticates and doesn’t store them in KERNEL. Fill from Vault uses a different boundary:

​
Security checklist

  • keep source-vault credentials and KERNEL api keys in trusted backend code.
  • authorize the mapping between the end user, source secret, KERNEL vault, and credential item.
  • keep password, totp, and other secrets marked sensitive: true.
  • don’t put values in agent prompts, frontend code, command-line arguments, logs, traces, or metadata.
  • attach a vault only to browser sessions authorized to use all of its items.
  • treat values as exposed to the browser after fill; page scripts, extensions, developer tools, or an unrestricted agent can read them.

​
Next steps

Define Credential Items

define fields and update copied values without returning sensitive fields.

Fill Browser Fields

attach the vault, map fields to selectors, and handle the fill outcome.