Private inference.
A boundary you can verify.
Your client verifies the inference environment and encrypts the request before it leaves your application. Krava routes the sealed bytes. The relay has no key to read them.
Encryption reaches the compute.
Ordinary transport encryption ends at the server receiving the request. Krava Core seals the inference body to the verified TEE (Trusted Execution Environment), across the relay.
Seals prompt and parameters
Decrypts the response
Reserves prepaid balance
Forwards sealed bytes
Runs the requested model
Seals the response
Check before sharing
The SDK verifies attestation on the caller’s machine and binds the enclave’s encryption key to that evidence. Your chosen pin policy determines which signed releases you accept.
Keep the relay outside
The client seals the request body using EHBP. The relay rejects unsealed inference bodies, checks attestation again, and forwards ciphertext through the TEE provider adapter.
Fail closed
The requested model is served or the request is refused. A failed privacy check is an error, not permission to fall back to a plaintext provider or a different model.
A small, deliberate core.
Krava Core replaces the earlier Vercel-based service with a dedicated relay and account console. The current sandbox runs on AWS with inference in a verified TEE. The service is focused on five capabilities:
- Passkey sign-in: WebAuthn authentication, account recovery, and API-key management.
- Prepaid billing: Stripe top-ups, balance reservations, usage settlement, and a ledger.
- Sealed TEE inference: client verification, encrypted requests, and streaming responses.
- Technical logging: operational records with an explicit retention inventory.
- An account console: access to accounts, keys, balance, and usage.
Core is an inference service. The legacy site’s encrypted-memory product and multi-provider routing promises do not describe this version.
Meter usage without storing the conversation.
Prepaid funds
Route the sealed request
Record billing metadata
| Data | Boundary |
|---|---|
| Prompts & completions | Sealed across the relay; Core does not persist their content. |
| Account & authentication state | Stored to operate passkeys, sessions, recovery, and API keys. |
| Usage, payments & operational records | Retained under field-specific policies. Some records can be linked to an account. |
| Your application & user device | Outside the relay’s privacy boundary. Your own logs, analytics, storage, and endpoint security still matter. |
Verify first.
Then send.
Use the Core client SDK or CLI, configure the sandbox endpoint, authenticate, and choose the enclave pin policy before sending private content.
npm install @krava-io/core-client@beta
# Or use the terminal client
npm install -g @krava-io/cli@betaFor a browser integration, run the SDK in the browser if you want encryption to begin on the user’s device. Running it on your backend puts your backend inside the plaintext boundary. Never embed a shared server API key in a public app.
A signed-release floor accepts eligible signed builds at or above that floor. An exact pin narrows the accepted build. Choose deliberately; attestation still depends on the verifier, the accepted software, and the confidential-computing hardware.
Bring a precise privacy claim to your product.
Say what is protected, where it is decrypted, and what is retained. That is a stronger foundation than an unqualified “zero logs” badge.
Read the business case