You only ever see your own clusters.
VantraOps handles cluster credentials, metrics history, and — if you enable it — AI provider keys for every tenant on the platform. Here's exactly how that data is isolated, encrypted, and scoped, not just described in general terms.
tenant_id is enforced on every row — not applied as a UI filter.
Hard tenant boundaries, not soft filters
Most SaaS platforms enforce multi-tenancy in the application layer — a query filter that's easy to get right in the common case and easy to miss in a new endpoint. VantraOps enforces tenant scope at the data-access layer itself, so every query, on every endpoint, is bound to the caller's tenant before it can return a row. There's no code path that skips it.
How data is protected, end to end
Tenant-scoped access, enforced server-side
Every account is a hard tenant boundary. Role-based membership per account controls who can see what, but the boundary itself is enforced on every request server-side — never just filtered out of a UI response.
Per-cluster credential encryption
Agent credentials are encrypted with a per-cluster data key, itself protected by a KMS master key. Nothing is ever stored in plaintext, including in backups.
Short-lived, single-use enrollment tokens
Enrollment tokens are single-use with a 15-minute TTL — dead the moment the agent boots or the window closes, whichever comes first. There is no standing credential exposed during setup.
Instant revocation
Revoke a cluster's access instantly from the portal, no need to touch the cluster itself. The agent's credential is invalidated server-side on the next heartbeat attempt.
Read-only by default
The agent's ServiceAccount is scoped to get, list, and watch — no write, patch, or delete permissions against your cluster, ever, unless you explicitly opt into a feature that requires it.
Isolated AI provider keys
If you connect an AI provider for root cause analysis, that key is encrypted with its own data key — the same isolation model used for cluster credentials, not a shared secret store.
Security questions
No. tenant_id is enforced on every database row and every query path server-side — it is not a UI-level filter that could be bypassed by calling an API directly. Cross-tenant access would require a defect in that server-side enforcement, not a missing frontend check.
Metrics, resource specs, and Kubernetes events needed for health checks, cost mapping, and (if enabled) AI analysis. It does not collect application logs, secrets, or request/response payloads from your workloads.
No — only anonymized signal (events, metric deltas, resource specs) is sent to the AI provider you connect, and it goes directly using your own contract with that provider. Full logs and secrets are never included, and nothing routes through a VantraOps-held model or key.
Read-only by default: get, list, and watch verbs against the resources it monitors. It cannot create, modify, or delete anything in your cluster, and there is no inbound network access from VantraOps to your cluster at any point.
Email security@vantraops.com with details. We aim to acknowledge reports within one business day.
Read how this looks in practice.
See the full six-pillar platform, including how AI root cause analysis uses this same isolation model.