HX-Provenance on Google Cloud.

Runtime path

Client systems send authorized requests over HTTPS. The application service binds to loopback; nginx provides the customer-facing HTTPS boundary.

Customer application
  → HTTPS :443
  → nginx (TLS termination)
  → FastAPI on 127.0.0.1:8001
  → HX-Provenance signing / verification logic

Signing model

HX-Provenance signs receipts with ML-DSA-65. Each instance generates its own keypair at first boot; the secret key remains on the customer-controlled VM, and the public key is retrievable for verifier pinning. Receipts signed by one instance verify against that instance’s public key — for multiple instances, pin public keys per issuer or establish an issuer policy.

Storage model

HX-Provenance signs and returns receipts; customers retain receipts and evidence bundles in their own systems of record. The appliance stores runtime configuration, service material, logs, and per-instance keys in the customer environment.

Network posture & upgrades

• Restrict HTTPS :443 to authorized clients; administer the VM through approved Google Cloud access paths.
• Monitor /health and alert on service failures; retain firewall changes in change management.
• Pin the appliance public key before accepting receipts in production.
• Optional integrations (Cloud Storage, Cloud Logging, Cloud Monitoring, CI/CD) stay inside your environment unless you configure otherwise.
• Upgrades launch a newer immutable image and validate before shifting traffic; back up and restore per-instance keys if signer continuity is required.

Verification behavior: a valid receipt returns a successful verdict; a modified receipt fails; an unsupported schema returns a structured failure; a signer mismatch fails when the verifier enforces pinning.

What it checks

• Receipt schema support and ML-DSA-65 signature validity.
• Public-key fingerprint match and canonical receipt body.
• Signed-field integrity and artifact commitment consistency.
• Bundle manifest integrity, for evidence bundles.

Verify on an independent host

# copy the receipt + public-key material to an independent host
python -m products.hx_provenance.tools.verify_receipt --receipt receipt.json
# provide the expected public key / fingerprint to enforce signer pinning

Evidence-bundle contents

A bundle is designed for independent review and can include receipt.json, artifact and verification manifests, the signer public key, signature metadata, a MANIFEST.sha256, and bundle signature material. Extract it, verify manifest hashes, verify the manifest signature against the signer public key, verify the receipt, then confirm the result matches your acceptance policy.

For auditor handoff, provide the evidence bundle, the appliance public key or fingerprint, verification instructions, the release identifier, the export timestamp, and a contact for interpretation. Never send API keys, signing keys, private keys, or raw regulated data through ordinary support or email channels.

Key custody

• Each instance generates its own ML-DSA-65 signing keypair at first boot; the secret key stays on the appliance under customer-controlled permissions.
• Customer-held material: per-instance signing key, API keys, runtime configuration, retained receipts, evidence bundles, and public-key pinning policy.
• HolonomiX does not receive the appliance signing key during normal operation.
• Retain prior public keys for historical verification — receipts signed by a prior key remain verifiable with that key.

Network & authentication

• The application service binds to loopback; nginx terminates TLS on :443 and forwards to the local FastAPI service.
• Restrict :443 to authorized clients; use approved administrative access paths; monitor /health and hx-provenance.service.
• Receipt issuance and evidence-bundle export require an admin API key; verification and public-key retrieval are available without authentication by design.

Support-data handling

Sanitize support bundles before transmission. Exclude signing keys, API keys, private keys, secrets, customer corpus or query data, regulated records, confidential evidence artifacts, and unsanitized receipts. Report security issues to [email protected].

Service status & logs

sudo systemctl status hx-provenance.service
sudo systemctl status nginx
sudo journalctl -u hx-provenance.service --since "30 minutes ago"
curl -fsS https://<HOST>/health

Before contacting support

Collect: organization name, Google Cloud project ID, region/zone, VM name, HX-Provenance release version, Marketplace order reference, an issue summary with timestamps, relevant non-secret logs, /health output, service status, and reproduction steps.

General support: [email protected]. Security-sensitive issues: [email protected]. Send support materials only through a secure channel agreed with HolonomiX, and never include keys, secrets, or regulated data.

Release posture

• Single-tenant VM appliance on Ubuntu 24.04 LTS, CPU-only runtime, FastAPI behind nginx.
• ML-DSA-65 receipt signing; per-instance signing key generated at first boot.
• Online and offline receipt verification; evidence-bundle export.
• Support-bundle redaction guidance; immutable-image upgrade and rollback model.

Upgrade model

Upgrades launch a newer image version, validate it, and shift traffic per your operational process. If signer continuity is required, back up and restore per-instance signing keys and runtime configuration per your key-custody policy, and retain retired public keys for historical receipt verification.