> ## Documentation Index
> Fetch the complete documentation index at: https://kernel.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Use an Existing Credential Vault

> Copy credentials from an existing vault into KERNEL for browser fill

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](/docs/auth/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.

<Warning>
  `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.
</Warning>

## How it works

<Steps>
  <Step title="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.
  </Step>

  <Step title="Copy It into a Credential Item">
    create a KERNEL [credential item](/docs/vaults/credentials) with the same field names and values. Mark secrets and any identifiers that don't need a read path as sensitive.
  </Step>

  <Step title="Fill an Attached Browser">
    attach the KERNEL vault when you create the browser, then invoke [fill](/docs/vaults/fill) with field names and selectors. The fill request and response don't contain the stored values.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Copy a credential

use the canonical [copy values from an existing vault](/docs/vaults/credentials#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](/docs/vaults/credentials#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](/docs/integrations/1password) 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:

|                          | Fill from Vault with an existing vault   | Managed Auth + 1Password                             |
| ------------------------ | ---------------------------------------- | ---------------------------------------------------- |
| **who reads the source** | your trusted backend                     | Managed Auth                                         |
| **storage in KERNEL**    | encrypted credential copy                | values remain in 1Password                           |
| **synchronization**      | your backend updates or deletes the copy | Managed Auth retrieves values at authentication time |
| **login control**        | your application or agent                | Managed Auth                                         |

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

<CardGroup cols={2}>
  <Card title="Define Credential Items" icon="lock" href="/docs/vaults/credentials">
    define fields and update copied values without returning sensitive fields.
  </Card>

  <Card title="Fill Browser Fields" icon="input-text" href="/docs/vaults/fill">
    attach the vault, map fields to selectors, and handle the fill outcome.
  </Card>
</CardGroup>