Security and trust model

The VaultPilot security and trust model shows operators the trust boundaries, the assets they must protect and the update trust chain.

Trust boundaries

BoundaryWhat crosses itOperator rule
Browser to VaultPilot serverSigned-in requests and encrypted vault material.Use HTTPS for production access and keep browser sessions locked when unattended.
VaultPilot server to its databaseEncrypted secret payloads and operational metadata.Do not copy or publish the database; rely on encrypted backup workflows.
Update Center to the release hostSigned manifest and release assets.Trust only assets whose manifest signature, hash and size verify; the signer is checked only when the manifest names one.
Browser extension to serverPairing code, wrapped vault keys and encrypted snapshots.Pair only approved devices and revoke stale devices.
DC Agent to serverDirectory metadata and agent status.Keep AD bind password local to the agent setup flow; never send it to support.
External sharingEncrypted selected-record package and passphrase-protected open flow.Share only selected records and communicate passphrases out of band.

What VaultPilot protects

  • Password records, credentials, API keys, secure notes, certificates and file-backed secrets.
  • Vault unlock material while the browser session is active.
  • Share packages through expiry, max-open controls and encrypted package metadata.
  • Update packages through manifest signature, hash, size and MSI signer when one is named.
  • Audit evidence through visible event history and chain state.

What operators must protect

  • Master passwords and authenticator devices.
  • License private or issuer-side material.
  • Update signing private keys.
  • Certificate private keys and PFX/P12 files.
  • Databases, backups and logs that may contain sensitive metadata.
  • AD bind credentials and agent tokens.
  • Real screenshots showing records, users, internal hostnames or customer data.

Update trust chain

  1. VaultPilot downloads the signed update manifest.
  2. VaultPilot verifies the manifest signature.
  3. VaultPilot verifies release URLs stay on the allowed release host.
  4. VaultPilot compares MSI SHA-256 and file size.
  5. If the manifest names a signer, VaultPilot checks that the MSI is signed by it.
  6. The published 3.0.3 MSI is unsigned; it is trusted only from the allowed release address after the valid Ed25519 manifest, exact SHA-256 and file size checks. MSI files placed on the server by hand still need a signer.

CA-backed or trusted-signing certificates remain recommended for Windows reputation.

Public evidence rule

If support needs evidence, send only:

  • Version numbers.
  • Redacted service state.
  • Redacted error messages.
  • Manifest version, hash, size and signer status.
  • Screenshots with all real records, URLs and users removed.

Never send plaintext secrets, master passwords, license private material, AD bind passwords, databases, backups, private keys or PFX/P12 files.

Back to Documentation