Security that's structural, not bolted on
VERA's one architectural rule — isolated deployment per tenant, one codebase per layer, customization via config — is also its security model. Here's what that means for your data.
Isolation by deployment, not by query
Every tenant — including VERA itself — runs its own database, instance, and URL. Your data never shares a table with another customer. Isolation is enforced by the deployment boundary, which is the strongest kind.
A single governed door
No application layer ever calls a vendor SDK directly. CRM reads, writes, and model inference all flow through your VERA MCP instance, where authentication, RBAC, the write-gate, caching, and usage budgets live and are audited.
Least privilege, enforced at the database
Each user acts as their own OAuth identity through MCP, and portfolio scoping is enforced with Postgres row-level security — so a CSM physically cannot read accounts outside their book, even if the app layer had a bug.
Humans confirm every write
Write-backs are proposed with a preview and committed only on explicit confirmation, attributed to the real user and recorded in an audit log. Read-only and impersonating sessions can never write.
The full picture
Built for teams that can't hand-wave security
VERA's architecture makes the safe thing the default. Isolation, governance, and audit aren't add-ons — they're how the system is wired.
Isolated deployment per tenant
A separate database, instance, and URL per customer. Hard data isolation by deployment — not a shared multi-tenant table with a WHERE clause.
One governed data path
No layer ever touches a vendor SDK directly. All CRM data and all model inference route through your VERA MCP instance, where auth, RBAC, and the write-gate live.
Per-user identity, not a shared key
Each user’s reads and writes run as their own OAuth identity through MCP, enforced at the database with row-level security — so people see only their portfolio.
No scattered model keys
The LLM credential lives once, in the MCP portal — encrypted, budget-capped, usage-attributed. No provider key sprayed across service env vars.
Propose → confirm write-gate
Nothing is written to your CRM without an explicit confirmation step. Every write is attributed and audited; impersonating viewers are read-only.
Customization via config, never forks
One codebase per layer. Branding, field maps, roles, and schedules are configuration — so a fix ships to every tenant at once and nothing drifts.
Stop finding out about churn at the renewal.
See VERA running against your own CRM in a 30-minute walkthrough. We'll stand up an isolated tenant and show you your real accounts, ranked.