Platform · Trust
Security: isolation first, honesty throughout
VegaDūta isolates every tenant in its own Postgres schema — your data lives in a separate schema, not in shared tables filtered by a tenant column. Identity runs on Keycloak with OpenID Connect SSO, provider and channel credentials are encrypted at rest, and every agent action passes through guardrails, optional human approval gates, and audit logging.
We are equally direct about what we are not: the platform is self-hosted and single-region today, and holds no SOC 2 or ISO 27001 certification yet. If your procurement process requires those, you should know before a sales call, not after.
Tenant isolation by schema
Each tenant gets a dedicated Postgres schema, which makes cross-tenant reads a structural impossibility rather than a query-filter discipline. It also makes tenant data-erasure tractable: the platform ships tooling to erase a tenant's data cleanly when they leave.
Identity and secrets
Authentication is Keycloak with OpenID Connect, giving you standard SSO semantics rather than a homegrown login system. The API keys, LLM provider credentials, and channel secrets you store are encrypted at rest, and inbound channel webhooks are signature-validated before processing.
Agents kept on a leash
Autonomous agents get layered controls: guardrails screen for PII, toxicity, and jailbreak attempts; human approval gates pause risky actions until someone says yes; per-user daily budgets cap spend; and audit logs record what happened. MCP tool connections run sandboxed with SSRF guards and command allowlists, so a malicious or buggy tool server cannot reach into your network.
- PII, toxicity, and jailbreak guardrails on agent traffic
- Human approval gates before risky actions
- Per-user daily budgets and audit logging
- MCP sandboxing, SSRF guards, command allowlists
Where we stand on compliance — honestly
VegaDūta is self-hosted and runs in a single region today, and we have not yet completed SOC 2 or ISO 27001 certification. The controls above are real and in the code, but we will not dress them up as a certificate we do not hold. This page will change when that status does.
Frequently asked questions
How does VegaDūta isolate one customer's data from another's?
Every tenant gets its own Postgres schema — separate tables, not shared tables filtered by a tenant ID. That makes cross-tenant access structurally impossible at the query layer, and it is paired with tenant data-erasure tooling for clean offboarding.
Is VegaDūta SOC 2 or ISO 27001 certified?
Not yet. The platform is self-hosted and single-region today, and no SOC 2 or ISO 27001 certification has been completed. The underlying controls — schema isolation, encryption at rest, audit logging, guardrails — exist in the product, but we state the certification status plainly.
How are my LLM provider keys and channel credentials stored?
Encrypted at rest. Provider keys, channel secrets, and similar credentials are never stored in plaintext, and webhook trigger tokens are hashed. Authentication for users runs on Keycloak with OpenID Connect SSO.
What stops an AI agent from doing something dangerous?
Several independent layers: guardrails screen inputs and outputs for PII, toxicity, and jailbreaks; human approval gates pause risky actions until a person approves; per-user daily budgets cap spend; and MCP tools run sandboxed with SSRF guards and command allowlists. Agents are also designed to ask before risky actions rather than act silently.
See it working in two minutes
The sandbox provisions a real tenant — describe an agent in one sentence and test it, no account, no card. Or browse ~90 industry workflow recipes to see what teams build.