Privacy & data boundary

Your agents' context never leaves your environment.

OpenViking runs as a private deployment inside your own infrastructure. All agent context — memories, resources, files, embeddings, and queries — stays there. The only things that cross the boundary to the official side are a minimal, allow-listed license refresh and optional operational telemetry. Never context content.

The boundary, stated plainly

Everything sensitive stays inside your private deployment. What reaches the official side is only a short license-validity refresh and, if you opt in, minimal operational telemetry — signed, allow-listed, and free of any context data.

Stays private

Inside your environment — we never receive it.

  • Agent context & memoryConversations, memories, and derived context your agents read and write.
  • Resources & filesDocuments, code, and knowledge you import into ov.
  • Embeddings & indexesVectors and search indexes built from your own content.
  • Queries & resultsWhat your agents ask, and what ov returns to them.
  • The deployment keyYour P-256 signing / verification material is generated and held on your side.

Leaves (minimal)

Crosses to the official side — allow-listed, no context content.

  • License validity refreshYour deployment presents its key and receives a fresh short-lived signed lease. The request carries the key and identifiers only.
  • Operational telemetry (optional)Heartbeat, version, and coarse counters — gated by an org preference, operational only, never a billing or context source.
  • Stable identifiersLicense, deployment, and lease ids for support and entitlement checks — not content.

Signed & verifiable

An ES256 signed lease, verified on your side

Authorization is a cryptographic lease, not a phone-home for data. On activation your deployment presents its key; the official API returns a short-lived lease (JWS, ES256 / P-256) plus a signed key manifest. Your deployment verifies the signature locally against a trust anchor it fetches once, then runs — refreshing the lease before it expires. The short lease is the grace window; revocation takes effect at the next refresh.

Real ES256 signatures

Leases and the key manifest are signed by a dedicated license signer, separate from any access token.

Local verification

Your runtime checks typ, audience, subject, key id, and expiry against the published signer JWK.

Short TTL, clear revocation

~7-day leases with a small clock-skew leeway; revoke and suspend land at the next refresh.

What we never store or log

Enforced by an allow-list and a CI redaction scan.

  • Raw customer or agent content of any kind
  • Full signed leases, access tokens, or client assertions
  • Private keys, cookies, session ids, or authorization headers
  • Anything outside the log allow-list of stable ids, key metadata, and hashes

Telemetry is optional and preference-gated

Operational telemetry is checked against an organization preference before anything is exported. Turn it off and your deployment keeps activating and refreshing normally — the license path is independent of telemetry, and billing is never derived from it.

Operational only · never billing · never context

Read the details, then run it yourself

The boundary above is what the software actually enforces. Issue a trial key, deploy privately, and verify it for yourself.

Based on the OpenViking threat model & licensing architecture.