Built for teams that take their data seriously.

Every tenant is a closed boundary.

Virideon is architected so that one tenant cannot see, query, or reach another tenant's data. Each tenant has its own search index (Elasticsearch), its own vector store (Qdrant), its own knowledge graph (Neo4j), its own job queue (Redis), and its own filesystem volume. There is no shared database, no shared schema, no row-level pretense — the boundary is the deployment itself.

• Per-tenant data volumes mounted at isolated paths.
• Per-tenant container set; no shared application instances across tenants.
• X-Tenant-ID header enforced at the gateway and re-checked at every service.
• API keys are tenant-scoped; cross-tenant calls are rejected at the auth layer.

Your data resides where your tenant is deployed.

For Virideon API deployments into customer infrastructure, your data stays in your infrastructure — your cloud, your network, your jurisdiction. For hosted Hub deployments, your tenant runs in an isolated environment co-located with your account. There is no central Virideon corpus that aggregates customer data.

• Virideon API (customer-deployed): data lives wherever you provision the tenant. You control the region, the cloud provider, the network topology.
• Hub (hosted): tenant runs in an isolated environment. No data flows into shared storage, shared models, or shared analytics.
• No data egress to third-party SaaS for the memory itself — only the connectors you choose to enable (e.g., Gmail OAuth, your chosen LLM provider).
• Air-gap and offline deployment supported for sovereign environments where no outbound network access is permitted.

Multi-layered. Tenant-scoped. Step-up where it matters.

User authentication uses JWTs with a session-version check that allows immediate token revocation when needed. WebAuthn passkeys are supported as a phishing-resistant primary auth path. Machine-to-machine access uses scoped API keys — every key is bound to a single tenant and a specific permission scope.

• User auth: JWT with session versioning + WebAuthn passkey support.
• Machine auth: tenant-scoped API keys in the format amb_{tenant}_{random}.
• Permission scopes: read / write / admin / service.
• Step-up auth: write paths and admin operations require a fresh re-authentication token via the x-reauth-token header — even for the holder of a write-scoped key.
• Role-based access control enforced in middleware on every privileged endpoint.

Every tenant has its own audit log.

Audit isn't an afterthought in Virideon — it's foundational. Every tenant has its own audit log and activity log capturing privileged actions, authentication events, and API access. The memory layer additionally maintains an immutable, bi-temporal Episodes journal that records every fact with the source it was learned from, when it was learned, and when it was true.

• Per-tenant audit log: authentication events, privileged operations, API calls.
• Per-tenant activity log: human-facing record of what happened, when, and at whose request.
• Bi-temporal Episodes journal: immutable record of every fact Virideon ingests, with valid_from / valid_to and as_of_recorded_at for point-in-time replay.
• Replay-safe chain verification for AI Search sessions — you can reconstruct what the agent saw, what it did, and why, after the fact.

Your data is not used to train shared models.

Virideon is opinionated about model traffic: model providers are configurable per tenant, and Virideon itself never routes your data through a provider that uses it for training. You bring the LLM — whether that's an on-prem model, Anthropic via your own API key, OpenAI via yours, or an OpenRouter routing through your chosen models.

• Configurable model provider per tenant — bring your own keys.
• No training on customer data. Virideon does not have a shared model that learns from your work.
• Embedding and reranking run on local infrastructure by default (Qwen3 family). Remote routing is opt-in.
• Vision processing off by default; opt-in via configuration.

Settings · Models

Real model picker. Real provider control. Your keys, your choice.

In transit at the perimeter. At rest via the platform.

TLS terminates at the perimeter gateway for all external traffic. Service-to-service communication inside the tenant's private network is over a controlled bridge network. At-rest encryption uses the underlying platform's native disk encryption (AES-256 on managed cloud disks — AWS EBS, Azure-managed disks, GCP Persistent Disks). Credential material for connectors (e.g., IMAP passwords) is encrypted at the application layer with a tenant-specific key.

• In transit: TLS termination at the gateway; perimeter encryption for all external requests.
• At rest: platform-native disk encryption (AES-256 by default on major clouds).
• Credential material: application-layer symmetric encryption for connector credentials.
• Roadmap: KMS-backed key management and BYOK for organizations with explicit key-control requirements.

Honest about where we are.

Virideon is at a stage where the architecture meets the substance of what serious compliance frameworks ask for, but the formal certifications are still ahead of us. We'd rather be honest about that than fake a badge wall. Here's where each piece actually stands today:

Have specific compliance requirements? Talk to us. We'll tell you honestly where we stand against your framework and what the path looks like.

If you find something, tell us.

We take security reports seriously. Disclose responsibly by emailing security@virideon.ai. We acknowledge within 24 hours and will work with you to remediate before any public disclosure. We don't pursue legal action against researchers who report in good faith and follow responsible disclosure.