Enterprise Edge

Local Vault

Local Vault is een outbound-only customer edge component voor connector secret storage, source attestation signing, offline spooling, event relay, optionele customer-side witness operation en, in Local Vault 2.x, de Attesto 3 provenance mode, waarbij capsules op de edge host blijven en alleen commitments het platform bereiken. Het is geen HashiCorp Vault.

Responsibilities

Encrypt connector credentials lokaal.
Onderteken source attestations vóór relay.
Spool events tijdens network outages.
Replay spooled events in volgorde met idempotency.
Operate als customer-side witness wanneer tenant policy dit inschakelt.

Lokale image provenance gebruikt de geïsoleerde provider en encrypted keyed registry uit de AttestoMark Image-handleiding.

Installeren en draaien

Installeer Local Vault op de klantbeheerde edge host. Runtime-coördinaten mogen uit flags of environment variables komen, maar signing keys, spool encryption keys en connector credentials moeten uit de lokale deployment secret manager komen. Plaats ze niet in shell history, frontendconfig of Attesto-docs.

De aanbevolen installatie is het gesigneerde containerkanaal: een one-command installer haalt het vault-image gepind op digest binnen, maakt de state- en config-directories aan en installeert een attesto-local-vault wrapper zodat elk CLI-commando transparant in de container draait. Docker is vereist (Docker Desktop op macOS en Windows).

# Linux / macOS
curl -fsSL https://get.attesto.eu/local-vault/install.sh | sh

# Windows (PowerShell)
irm https://get.attesto.eu/local-vault/install.ps1 | iex

# Image pinned by digest (override: ATTESTO_LOCAL_VAULT_IMAGE):
# git.attesto.eu/attesto/local-vault@sha256:5799e7f0669c9b42a55a338f4233cfa5afb5aa6a2627c2c50f7545a41bff1551

Op macOS en Windows draaien de vault en zijn Linux-only provider sandbox in de Linux-VM van Docker Desktop; de isolatieclaims gelden binnen die VM. Een native macOS- of Windows-proces zou ze niet dragen, en precies daarom zijn de installers container-wrappers. Verwijderen: haal de wrapper weg, verwijder het image met docker rmi en verwijder, alleen als het bewijs niet langer nodig is, de state-directory — install.sh --help toont de exacte commando's.

Op macOS en Linux installeert dezelfde container-wrapper ook via Homebrew. De formula-hashes worden letterlijk overgenomen uit het cosign-gesigneerde kanaalmanifest en Homebrew dwingt ze bij elke installatie af; de caveats herhalen de Docker-vereiste en de honesty note hierboven:

brew tap attesto/attesto https://git.attesto.eu/attesto/homebrew-attesto.git
brew trust attesto/attesto
brew install attesto-local-vault

Op Debian/Ubuntu- en Fedora/RHEL-hosts installeren native packages dezelfde wrapper als /usr/bin/attesto-local-vault, draaiend op hetzelfde op digest gepinde image. De deb heeft een harde dependency op een Docker-compatibele engine (docker-ce | docker.io | podman-docker); rpm kan die alternatie niet over repositories heen uitdrukken en beveelt daarom alleen docker aan — de engine blijft vereist tijdens runtime. Verifieer het gesigneerde manifest, controleer de package-hash en installeer daarna:

curl -fsSLO https://get.attesto.eu/local-vault/2.0.1/SHA256SUMS
curl -fsSLO https://get.attesto.eu/local-vault/2.0.1/SHA256SUMS.sig
cosign verify-blob --key https://get.attesto.eu/cosign.pub --insecure-ignore-tlog --signature SHA256SUMS.sig SHA256SUMS

# Debian / Ubuntu (run the install as root)
curl -fsSLO https://get.attesto.eu/local-vault/2.0.1/attesto-local-vault_2.0.1-1_all.deb
sha256sum -c --ignore-missing SHA256SUMS
apt install ./attesto-local-vault_2.0.1-1_all.deb

# Fedora / RHEL (run the install as root)
curl -fsSLO https://get.attesto.eu/local-vault/2.0.1/attesto-local-vault-2.0.1-1.noarch.rpm
sha256sum -c --ignore-missing SHA256SUMS
dnf install ./attesto-local-vault-2.0.1-1.noarch.rpm

Het Python-wheelkanaal blijft beschikbaar voor hosts die de vault native op Linux draaien:

pipx install attesto-local-vault

export ATTESTO_LOCAL_VAULT_SPOOL_DB=/var/lib/attesto/local-vault.sqlite3
export ATTESTO_LOCAL_VAULT_INSTALLATION_ID="$ATTESTO_LOCAL_VAULT_INSTALLATION_ID"
export ATTESTO_LOCAL_VAULT_RELAY_URL="https://verify.attesto.eu/v2/local-vault/installations/$ATTESTO_LOCAL_VAULT_INSTALLATION_ID/events"
export ATTESTO_LOCAL_VAULT_KEY_ID="$ATTESTO_LOCAL_VAULT_KEY_ID"

attesto-local-vault drain-loop

Health check

Draai attesto-local-vault doctor na bootstrap en tijdens operator troubleshooting. De doctor controleert config, lokale secrets, secrets.env-permissies, encrypted spool readback, relay URL HTTPS regels, backend bereikbaarheid, server clock skew, invalid server Date headers en dead-letter depth. Failures geven een non-zero exit code. Warnings houden de spool bruikbaar maar moeten door de operator worden beoordeeld.

attesto-local-vault doctor

Enrollment

Een tenant owner of admin maakt een kortlevend enrollment token met POST /v2/tenant/local-vault/enrollment-tokens. De edge host wisselt dat token om via POST /v2/local-vault/enroll en ontvangt installation metadata plus de credential voor outbound relay. Enrollment tokens zijn single-use; Attesto slaat na creatie alleen hun hash op.

Delivery acknowledgement

Local Vault markeert een item alleen als delivered wanneer Attesto een 2xx JSON receipt teruggeeft met matchende localVaultAck.envelopeHash, streambinding en canonical event id. Een proxy 2xx, malformed body, mismatched receipt of revoked installation blijft een mislukte delivery en valt onder retry of dead-letter policy.

Outbound relay flow

De customer source maakt een attestation event.
Local Vault ondertekent en bewaart het event in de encrypted spool.
Local Vault relayt het event naar POST /v2/local-vault/installations/{installation_id}/events op https://verify.attesto.eu.
Attesto retourneert de Proofstream receipt.
Local Vault registreert receipt state en bewaart retry metadata totdat delivery compleet is.

{
  "source_ref": "local-source-2026-0001",
  "event_type": "source.attestation",
  "payload_hash": "sha256-hex",
  "local_signature": {
    "alg": "Ed25519",
    "kid": "local-vault-key-epoch",
    "signature": "hex-encoded-signature"
  }
}

Encrypted spool

De spool bewaart events tijdens network outages. Replay is geordend en idempotent: dezelfde source reference en body kunnen worden retried, maar changed content voor dezelfde source reference wordt geweigerd.

State	Betekenis
`queued`	Lokaal opgeslagen en wachtend op relay.
`relaying`	Outbound request is bezig.
`receipted`	Attesto retourneerde een Proofstream receipt.
`conflict`	Source reference replayed met andere canonical content.

Security model

Geen inbound internet route is vereist voor relay mode.
Connector credentials blijven encrypted aan de customer edge.
Relay endpoints verwerpen replay conflicts en tampered envelopes.
Revocation faalt gesloten: een revoked installation kan niet blijven relaying accepted events.

Customer witness mode

Wanneer ingeschakeld kan Local Vault monotonic checkpoints voor zijn tenant streams ondertekenen. Een 2-of-3 policy kan Attesto-operated, customer-operated en assurance witness statements combineren zodat geen enkele service als enige source of history wordt behandeld.

In witness mode ondertekent Local Vault checkpoint statements alleen wanneer ze de last accepted checkpoint voor de tenant stream uitbreiden. Een conflict maakt fork visibility aan de klantzijde.

Witness checkpoint statements worden ingediend bij POST /v2/local-vault/installations/{installation_id}/witness/checkpoints en worden alleen geaccepteerd wanneer de installation enabled is, aan de tenant is scoped en monotonic is voor de stream.

Witness command

Gebruik de operator command om een monotonic checkpoint statement te signeren of fork evidence terug te geven voor een conflicterend checkpoint. Het commando print alleen publiek receipt/fork-materiaal; het print nooit de private signing key.

attesto-local-vault --witness-db /var/lib/attesto/local-vault-witness.sqlite3 \
  witness-checkpoint \
  --tenant-id ten_... \
  --stream-id str_... \
  --checkpoint-id chk_... \
  --checkpoint-seq-no 42 \
  --checkpoint-hash "$CHECKPOINT_HASH" \
  --previous-checkpoint-hash "$PREVIOUS_CHECKPOINT_HASH"

Provenance mode (Attesto 3)

Local Vault 2.x draait in een van drie modes, gewisseld met attesto-local-vault mode --set legacy-relay|provenance|shadow. legacy-relay is de relay-flow hierboven. In provenance mode bouwt de vault per asset een capsule met zijn gepinde Rust edge core, draait hij de ingeschakelde providers in de provider sandbox (AttestoMark Image, Audio en Video, C2PA) of als gemeten daemons (de inference gateway die AttestoMark Text draagt), evalueert hij de multi-signal policy, bewaart hij de capsule in de versleutelde lokale capsule store en relayt hij een ATTESTO-PROVENANCE-001-envelope die alleen commitments draagt: de subject commitment, de capsule root, de claims-, evidence- en policy-results-roots, het key id van de installatie, haar ondertekende assurance level en, op L1/L2, een attestation reference. Ruwe content, prompts, bestandsnamen en provider-output verlaten de host nooit; het platform kan geen capsule teruggeven omdat het er nooit een bewaart. shadow draait beide lanes voor een migratie die wordt aangestuurd met attesto-local-vault migration status|advance|roll-back|cutover-evidence; er is bewust geen --force.

attesto-local-vault mode --set provenance
attesto-local-vault provenance self-test
attesto-local-vault provenance relay-loop

De vault relayt naar POST /v2/local-vault/installations/{installation_id}/provenance-events, het pad dat het installatie-object adverteert als provenanceEndpointPath; de Ed25519-handtekening van de envelope is de credential. Het platform antwoordt met de Proofstream receipt plus een provenanceAck. De stream moet een provenance stream zijn, aangemaakt met POST /v2/provenance/streams onder een witness policy die eerst is gedeclareerd met PUT /v2/tenant/witness/policies/{policy_id}; de API-gids somt elke route op.

Assurance levels en hardware custody

Level	Vereist	Wat het platform verifieert
`L0`	Een software-sleutel (de standaard).	De Ed25519-handtekening.
`L1`	Dezelfde Ed25519-sleutel in een PKCS#11-token, niet-extraheerbaar.	Een `pkcs11-key-custody` attestation record, ondertekend door de sleutel.
`L2`	L1 plus een TPM 2.0-quote over de meting van de vault: vault-versie, edge-core-checksum, provider manifests en signing key.	De handtekening van de quote, de binding aan de measurement digest en de attestation key.
`L3`	Wordt nooit door een vault ondertekend.	Door de verifier afgeleid uit `L2` plus een behaald witness quorum op de omvattende checkpoint; anchoring verhoogt nooit een niveau.

Het handtekeningalgoritme verandert niet tussen de niveaus. Een attestation record (ATTESTO-VAULT-ATTESTATION-001) wordt geregistreerd op POST /v2/local-vault/installations/{installation_id}/attestations; het platform verifieert het en weigert een L1/L2-envelope die het niet kan onderbouwen. L2 betekent niet dat de host niet gecompromitteerd kan worden: het betekent dat een TPM een verklaring heeft ondertekend over wat de vault bij het starten heeft gemeten. De PKCS#11- en TPM 2.0-providers worden in continuous integration getest tegen SoftHSM2 en swtpm, software-doubles van die interfaces; nog geen enkele productie-installatie heeft met hardware ondertekend, en de first-party rollout-installatie ondertekent met een software-sleutel op L0.

Key lifecycle en revocation

Het intrekken van een installatie (DELETE /v2/tenant/local-vault/installations/{installation_id}) legt de platformklok vast als revocation-moment en publiceert dat op GET /v2/local-vault/installations/{installation_id}/key-status, dat bewust publiek is zodat een verifier die geen gebruiker van de tenant is bewijs offline kan controleren. Revocation wordt beoordeeld tegen de platform receipt time van elk event, nooit tegen het door de vault geclaimde occurred_at, met een inclusieve grens; een claim die aan de intrekking voorafgaat terwijl de receipt dat niet doet krijgt de vlag suspect_backdated. Een verifier bundle over een provenance stream draagt de key lifecycle zoals bij het bouwen van de bundle, dus een latere intrekking zit niet in de bundle.

Rollout-status

De provenance lane staat aan in productie. Fase A van de gecontroleerde rollout draaide op 2026-08-23 op productie met een first-party tenant: 15 receipts, 0 privacy-canary-treffers over de HTTP-bodies, de backend-logs en 92 databasetabellen, de stream gecheckpoint en gewitnessed. De lane-based rollback, die nieuwe events terug naar de legacy lane stuurt en niets herschrijft, is tegen productie geoefend. De fasen B tot en met D, inclusief design-partner-migraties en de standaardkeuze voor provenance bij nieuwe setups, zijn niet gestart.

Offline en online modes

Online relay: events worden snel signed, spooled, relayed en receipted.
Temporary offline relay: events blijven encrypted in de local spool totdat outbound network terugkeert.
Witness online: checkpoint statements worden volgens policy geverifieerd en ondertekend.
Witness unavailable: quorum kan vertraagd zijn; receipts blijven onafhankelijk van witness availability.