Enterprise Edge

Local Vault

Local Vault es un componente customer edge outbound-only para connector secret storage, source attestation signing, offline spooling, event relay, optional customer-side witness operation y, en Local Vault 2.x, el provenance mode de Attesto 3, donde las capsules permanecen en el host edge y solo los commitments llegan a la plataforma. No es HashiCorp Vault.

Responsibilities

Encrypt connector credentials localmente.
Firmar source attestations antes de relay.
Spool events durante network outages.
Replay spooled events en orden con idempotency.
Operar como customer-side witness cuando tenant policy lo habilita.

La provenance local de imágenes usa el provider aislado y el registro keyed cifrado de la guía AttestoMark Image.

Instalar y ejecutar

Instale Local Vault en el host edge controlado por el cliente. Las coordenadas runtime pueden venir de flags o variables de entorno, pero signing keys, spool encryption keys y connector credentials deben venir del secret manager local de despliegue. No las ponga en shell history, configuración frontend ni docs de Attesto.

La instalación recomendada es el canal de contenedor firmado: un installer de un solo comando descarga la imagen del vault fijada por digest, crea los directorios de state y config e instala un wrapper attesto-local-vault para que cada comando CLI se ejecute de forma transparente en el contenedor. Requiere Docker (Docker Desktop en macOS y 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

En macOS y Windows el vault y su provider sandbox exclusiva de Linux se ejecutan dentro de la VM Linux de Docker Desktop; las garantías de aislamiento aplican dentro de esa VM. Un proceso nativo de macOS o Windows no las tendría — exactamente por eso los installers son wrappers de contenedor. Desinstalación: elimine el wrapper, elimine la imagen con docker rmi y, solo si la evidencia ya no se necesita, borre el directorio de state — install.sh --help imprime los comandos exactos.

En macOS y Linux, el mismo wrapper de contenedor también se instala mediante Homebrew. Los hashes de la formula se copian literalmente del manifest del canal firmado con cosign y Homebrew los exige en cada instalación; los caveats repiten el requisito de Docker y la nota de honestidad anterior:

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

En hosts Debian/Ubuntu y Fedora/RHEL, los paquetes nativos instalan el mismo wrapper como /usr/bin/attesto-local-vault, ejecutando la misma imagen fijada por digest. El deb depende de un engine compatible con Docker (docker-ce | docker.io | podman-docker); rpm no puede expresar esa alternancia entre repositorios, así que solo recomienda docker — el engine sigue siendo obligatorio en runtime. Verifique el manifest firmado, compruebe el hash del paquete y luego instale:

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

El canal de wheel de Python sigue disponible para hosts que ejecutan el vault de forma nativa en Linux:

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

Comprobación de salud

Ejecute attesto-local-vault doctor después del bootstrap y durante operator troubleshooting. El doctor comprueba config, secrets locales, permisos de secrets.env, encrypted spool readback, reglas HTTPS de relay URL, disponibilidad del backend, server clock skew, cabeceras de servidor Date inválidas y dead-letter depth. Los failures devuelven un código distinto de cero. Los warnings mantienen el spool utilizable, pero el operador debe revisarlos.

attesto-local-vault doctor

Enrollment

Un tenant owner o admin crea un enrollment token corto con POST /v2/tenant/local-vault/enrollment-tokens. El edge host intercambia ese token en POST /v2/local-vault/enroll y recibe installation metadata más la credential necesaria para outbound relay. Los enrollment tokens son single-use; Attesto almacena solo su hash después de la creación.

Acknowledgement de entrega

Local Vault marca un ítem como delivered solo cuando Attesto devuelve un receipt JSON 2xx con localVaultAck.envelopeHash, stream binding y canonical event id coincidentes. Un proxy 2xx, malformed body, mismatched receipt o revoked installation sigue siendo una entrega fallida sujeta a retry o dead-letter policy.

Outbound relay flow

La customer source crea un attestation event.
Local Vault firma y almacena el event en el encrypted spool.
Local Vault relay el event a POST /v2/local-vault/installations/{installation_id}/events en https://verify.attesto.eu.
Attesto devuelve el Proofstream receipt.
Local Vault registra receipt state y conserva retry metadata hasta completar delivery.

{
  "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

El spool preserva events durante network outages. Replay es ordenado e idempotente: la misma source reference y body pueden reintentarse, pero changed content para la misma source reference es rechazado.

State	Significado
`queued`	Almacenado localmente y esperando relay.
`relaying`	Outbound request en progreso.
`receipted`	Attesto devolvió un Proofstream receipt.
`conflict`	Source reference reproducida con canonical content diferente.

Security model

No se requiere inbound internet route para relay mode.
Connector credentials permanecen encrypted en el customer edge.
Relay endpoints rechazan replay conflicts y tampered envelopes.
Revocation fails closed: una revoked installation no puede seguir relaying accepted events.

Customer witness mode

Cuando está habilitado, Local Vault puede firmar monotonic checkpoints para sus tenant streams. Una policy 2-of-3 puede combinar statements Attesto-operated, customer-operated y assurance witness para que ningún servicio único sea tratado como la única source of history.

En witness mode, Local Vault firma checkpoint statements solo cuando extienden el last accepted checkpoint del tenant stream. Un conflict crea fork visibility para el lado del cliente.

Los witness checkpoint statements se envían a POST /v2/local-vault/installations/{installation_id}/witness/checkpoints y se aceptan solo cuando la installation está enabled, scoped al tenant y es monotonic para el stream.

Comando witness

Use el comando de operador para firmar un monotonic checkpoint statement o devolver fork evidence para un checkpoint conflictivo. El comando imprime solo material público receipt/fork; nunca imprime la 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 funciona en uno de tres modos, conmutados con attesto-local-vault mode --set legacy-relay|provenance|shadow. legacy-relay es el flujo de relay descrito arriba. En modo provenance el vault construye una capsule por asset con su Rust edge core fijado, ejecuta los providers habilitados dentro de la provider sandbox (AttestoMark Image, Audio y Video, C2PA) o como daemons medidos (el inference gateway que transporta AttestoMark Text), evalúa la policy multiseñal, conserva la capsule en el capsule store local cifrado y retransmite una envelope ATTESTO-PROVENANCE-001 que solo lleva commitments: el subject commitment, la capsule root, las roots de claims, evidence y policy-results, el key id de la instalación, su nivel de assurance firmado y, en L1/L2, una attestation reference. El contenido en bruto, los prompts, los nombres de archivo y la salida de los providers nunca salen del host; la plataforma no puede devolver una capsule porque nunca la conserva. shadow ejecuta ambas lanes para una migración dirigida con attesto-local-vault migration status|advance|roll-back|cutover-evidence; no existe --force, por diseño.

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

El vault retransmite a POST /v2/local-vault/installations/{installation_id}/provenance-events, la ruta que el objeto de instalación anuncia como provenanceEndpointPath; la firma Ed25519 de la envelope es la credencial. La plataforma responde con el receipt de Proofstream más un provenanceAck. El stream debe ser un provenance stream creado con POST /v2/provenance/streams bajo una witness policy declarada antes con PUT /v2/tenant/witness/policies/{policy_id}; la guía de API enumera todas las rutas.

Niveles de assurance y hardware custody

Nivel	Requiere	Qué verifica la plataforma
`L0`	Una clave de software (por defecto).	La firma Ed25519.
`L1`	La misma clave Ed25519 guardada en un token PKCS#11, no extraíble.	Un attestation record `pkcs11-key-custody` firmado por la clave.
`L2`	L1 más un quote TPM 2.0 sobre la medición del vault: versión del vault, checksum del edge core, provider manifests y signing key.	La firma del quote, su vínculo con el measurement digest y la attestation key.
`L3`	Nunca lo firma un vault.	Lo deriva el verificador de `L2` más un witness quorum alcanzado en el checkpoint que lo contiene; el anchoring nunca promueve un nivel.

El algoritmo de firma no cambia entre niveles. Un attestation record (ATTESTO-VAULT-ATTESTATION-001) se registra en POST /v2/local-vault/installations/{installation_id}/attestations; la plataforma lo verifica y rechaza una envelope L1/L2 que no puede sustentar. L2 no significa que el host no pueda verse comprometido: significa que un TPM firmó una declaración sobre lo que el vault midió al arrancar. Los providers PKCS#11 y TPM 2.0 se ejercitan en integración continua contra SoftHSM2 y swtpm, dobles de software de esas interfaces; ninguna instalación de producción ha firmado todavía con hardware, y la instalación del rollout first-party firma con una clave de software en L0.

Key lifecycle y revocación

Revocar una instalación (DELETE /v2/tenant/local-vault/installations/{installation_id}) registra el reloj de la plataforma como instante de revocación y lo publica en GET /v2/local-vault/installations/{installation_id}/key-status, que es público a propósito para que un verificador que no es usuario del tenant pueda comprobar evidencia offline. La revocación se evalúa contra el platform receipt time de cada evento, nunca contra el occurred_at reclamado por el vault, con un límite inclusivo; una reclamación anterior a la revocación cuyo receipt no lo es recibe la marca suspect_backdated. Un verifier bundle sobre un provenance stream lleva el key lifecycle del momento de su construcción, así que una revocación posterior no está en el bundle.

Estado del despliegue

La provenance lane está activa en producción. La fase A del rollout controlado se ejecutó en producción el 2026-08-23 con un tenant first-party: 15 receipts, 0 detecciones de privacy canary sobre los bodies HTTP, los logs del backend y 92 tablas de base de datos, el stream con checkpoint y witness. El rollback por lane, que devuelve los eventos nuevos a la legacy lane y no reescribe nada, se ensayó contra producción. Las fases B a D, incluidas las migraciones de design partners y el paso por defecto de las nuevas configuraciones a provenance, no han comenzado.

Offline y online modes

Online relay: events se signed, spooled, relayed y receipted rápidamente.
Temporary offline relay: events permanecen encrypted en el local spool hasta que vuelve outbound network.
Witness online: checkpoint statements se verifican y firman según policy.
Witness unavailable: quorum puede retrasarse; receipts permanecen independientes de witness availability.