Privacy & security
A direct description of what OpenGrid, providers, and other network participants can see.
Trust boundary
TLS protects data in transit. The coordinator authenticates nodes and schedules only eligible capacity, but inference engines need plaintext input to run. A whole-model request is visible to its serving node. In a sharded pipeline, the pipeline head receives the prompt and later stages receive intermediate activations; outputs transit the pipeline.
Do not send passwords, private keys, regulated health information, payment-card data, or other secrets unless your organization has separately approved the risk and provider tier.
Data retention
OpenGrid does not persist prompt or output content by default. The control plane retains metadata required for operations and audit: request identifier, account and model identifiers, token counts, timestamps, route, latency, signed receipt hashes, points, errors, and abuse signals.
Opt-in conversation affinity stores only ownership, version, placement, expiry, and transcript hashes in the control plane. The application retains and resends the full history. A standalone llama.cpp node may retain prompt-derived KV state in an isolated volatile slot for up to 15 idle minutes; an idle reaper erases the slot at expiry and owner changes erase it before reassignment. Conversation affinity is disabled for the zero-retention private tier.
Providers must not log payload content. Node diagnostics redact prompts and generated text. A consumer may explicitly enable application-side history in its own system; that is outside OpenGrid’s default retention.
Curated private tier
The planned private tier will restrict requests to pinned artifacts and high-reputation providers that meet those additional requirements. This will reduce exposure; it will not make prompts cryptographically invisible to serving nodes.
Provider safety
Consumer input is data only. OpenGrid nodes never execute consumer-provided programs, shell commands, generated tool calls, or arbitrary model code. Tool execution belongs to the consumer application after it validates a model response.
Security controls
- TLS on every network hop and Ed25519 device identities for nodes.
- Nonced, signed usage receipts with consumer-edge countersignatures and replay protection.
- Short-lived enrollment tokens, hashed API keys, scoped access, quotas, and rate limits.
- Canary verification, throughput honesty checks, reputation penalties, and node bans.
- Append-only double-entry point ledger with daily Merkle-root snapshots.
Report a suspected vulnerability through the private contact documented in the repository’s SECURITY.md. Do not include live secrets or sensitive prompts in a report.