Skip to main content

Hardware attestation

When a buyer dispatches a request to a marketplace provider, they need to trust three things:

  1. The device is real hardware, not a VM impersonating one.
  2. The runtime is actually loading the weights for the canonical model the buyer asked for, not substituting a cheaper model.
  3. The buyer's bytes — prompt, completion, audio, image — don't leak outside the process they're meant to live in.

Perfect attestation of all three is an unsolved problem on consumer hardware. This page is about what Lovelace verifies today, what we're building toward, and where we've chosen trust-but-verify over cryptographic guarantee. No magic.

What's cryptographically verified today

Device identity. Every provider daemon generates a did:lovelace:device:<uuid> with an associated mTLS certificate at enrollment. The gateway authenticates the daemon's tunnel with that cert on every connection. A buyer routed to provider-did-abc is guaranteed that the daemon at the other end of the tunnel controls that keypair. See lovelace-device-identity for the keypair derivation.

Token authorization. Workspace-direct handoffs carry an ES256 JWT signed by auth.uselovelace.com that binds the buyer's account, the provider DID, the task class, and the canonical model. The daemon rejects any token that doesn't match its DID, is more than 60 seconds old, or names a task/model combination the daemon didn't advertise. Buyers can verify the JWKS themselves at auth.uselovelace.com/.well-known/jwks.json — Lovelace cannot mint a token a daemon accepts without the same signing key.

Runtime fingerprint. On tunnel establishment, the daemon reports the hash of each loaded model file, the runtime kind (Ollama, MLX, llama.cpp, cloud bridge), and the canonical IDs those hashes map to in the catalog. Hashes that don't match any catalog entry are rejected before the provider is routed any marketplace traffic.

What's behaviorally verified — not cryptographically

Completion quality. The reputation system (see Reputation) tracks structured buyer feedback and mid-stream disconnect rates. A provider silently substituting a smaller model for a larger one would show up as a quality drop on the model-specific score, not in the cryptographic attestation. This is a behavioral signal — good for nudging bad actors out of higher tiers, not a substitute for mathematical certainty.

Scheduling and resource budget. Providers declare allowed windows and resource caps in Provider Controls. The daemon enforces them locally. The gateway trusts the daemon's self-reporting here because there's no way for the gateway to verify a provider's CPU utilization from the outside. A provider that silently serves outside its declared windows is cheating a policy, not a cryptographic guarantee.

Data-plane isolation. Workspace-pool traffic flows directly between the buyer's app and the daemon's local HTTP server after the handoff; the gateway sees the mint, not the bytes. This is a structural guarantee about Lovelace's infrastructure, not the provider's. A compromised daemon could still log traffic locally. Buyers who need stronger isolation should pin requests to their own workspace pool via lattice:compute:workspace_only and avoid the marketplace entirely.

What we're building toward

TEE-backed attestation for supported hardware. Apple Silicon's Secure Enclave and NVIDIA Confidential Computing on H100-class cards can produce signed attestation reports of the running process. For providers opting in to a "verified" tier, the daemon would bundle an attestation report in its tunnel handshake and the gateway would route only to providers whose attestation chain validates. This is a post-v0 project tracked as a follow-on slice. It requires buyer willingness to accept a narrower pool of compatible hardware; the trade-off makes sense for compliance-sensitive workloads.

Verifiable inference via zero-knowledge proofs. Approaches like zkML can prove that a published commitment of a specific model was loaded and produced the given output for a given input, without revealing weights. They're currently too slow and expensive for real-time traffic and only cover small models. We track the research but don't expect it to be economical for general-purpose serving this decade.

What a buyer should actually do

  1. Start with your own workspace pool. Requests routed to devices you own — same workspace, same Lovelace account — carry the same workspace-direct handoff, and the data plane never transits Lovelace. This is the strongest isolation story we offer today, and it's free on all plans.

  2. Require a minimum reputation tier for marketplace traffic. options.min_tier: "gold" excludes Bronze providers from routing. Gold providers have at least 14 days of ≥85/100 score on the specific (task, model) pair you're dispatching.

  3. Use lattice:compute:workspace_only for end-user OAuth tokens. This scope tells the gateway never to fall back to marketplace providers for that user's requests, even if their workspace pool is empty. The request will fail with no_workspace_provider instead of silently routing to an unfamiliar peer.

  4. Sample structured feedback. Send POST /v1/feedback after a request with a quality judgment when you can. It feeds the reputation pipeline and pressures underperforming providers off the top tiers.

What Lovelace guarantees — and doesn't — in short

We guarantee:

  • The daemon at the end of a tunnel is the one whose DID we routed to.
  • The handoff JWT can only be minted by accounts-service, and only for a (buyer, provider, task, model) tuple the gateway approved.
  • A provider claiming to serve a canonical model has a runtime-local model whose file hash matches the catalog entry at probe time.

We do not guarantee:

  • The model loaded at request time is still the one fingerprinted at probe time.
  • The daemon isn't logging traffic it shouldn't.
  • The provider's declared resource budget matches what they actually consume.

If your workload needs stronger guarantees than this, stay in your own workspace pool, or wait for the verified-hardware tier. Don't deploy to the marketplace assuming cryptographic proof of inference — we don't have it yet, and we're not going to pretend we do.