Security

Built so one organization can never see another.

Vama Enterprise enforces tenancy where the data lives, keeps credentials out of the browser, and writes down everything an administrator does.

Talk to our teamSee plans

Fail closed

When the service that answers "is this person a member?" can't answer, the request is refused. Availability problems never become disclosure problems.

Refuse with "not found"

A request for something outside your organization is answered as if it didn't exist. Nobody learns what other tenants have by probing.

Least authority

Every credential is scoped to one boundary and checked in constant time. Acting on a saved account uses a grant that lives for seconds, not a shared key.

Tenant isolation

How a request is checked.

Three independent gates, each of which would refuse a cross-tenant request on its own.

01

At the gateway

The sign-in token is verified at the edge. Organization context is derived from the token — never from headers the client sends. A request that names an organization its token doesn't grant is rejected before it reaches a service.

02

At the service

Every request is typed: organization, consumer or service. A write that would change who belongs where — creating a channel, adding a member, starting a call — re-checks membership with the account service before the first write.

03

In the data layer

Reads and writes are filtered by organization per row, and search filters in the query and re-verifies every hit. There is no code path that reads another tenant's rows and filters them afterwards.

Why per-row and not just at the edge. An edge check protects the front door. A per-row check protects every query a service will ever run — including the ones written next year. Vama does both, and the data-layer gate is the one that must hold.
Identity & sessions

Credentials that stay where they belong.

No secrets in page JavaScript

Signing in leaves one HttpOnly, host-only credential in the browser. Access tokens live in memory only; no refresh token is ever readable by scripts on the page.

Sessions bound to device and window

Each browser window holds its own session per identity. Two windows can use different accounts — personal in one, work in another — without signing each other out.

Session policy you set

Owners and admins can require members to sign in again after a number of days (1–365). It governs browser sign-ins and reaches existing sessions at their next refresh.

Your identity provider, your rules

With single sign-on connected, organization accounts open through your OpenID Connect provider. Turning SSO off is one click for an owner or admin, on any plan.

Short-lived signed grants

Reading a saved account's picture or replying from the Switchboard uses an HMAC grant bound to that account, that window and that request, valid for seconds and refusing caller-supplied identity.

Sign-out that stays signed out

Signing out of a work identity ends its sessions on that device and removes its saved sign-in from the browser. A personal identity saved alongside it is untouched.

Files & data

Your organization's data is your organization's.

Organization-scoped files

Anything uploaded inside an organization is stored under that organization and served only to active members with a live session. There are no expiring links to leak and nothing to re-sign.

Offline data kept per account

On-device caches are keyed by the exact account and organization, so returning to one workspace never hydrates another's data. Removing the last saved identity clears the browser's local footprint.

Removal keeps history, not access

Removing a member — by hand or through SCIM — ends their access immediately and keeps what they contributed, so channels stay whole and nothing is destroyed by accident.

Deletion with a window

Owners schedule an organization's deletion; it can be restored until the window closes. Scheduling and restoring are both recorded in the audit log.

Administration

Power that leaves a trail.

Audit log

Every administrative action is written with its actor, target and time, and the log is read-only. Invitations, roles, SSO, domains, SCIM tokens, session policy and moderation all appear.

Roles with guard rails

Owner, Admin, Member. The last active owner can never be demoted or removed. SCIM can create and remove members but can never grant Owner.

Separate keys for separate boundaries

Service credentials must differ per boundary, are compared in constant time, and are refused on surfaces where they don't belong — a key for one hop opens nothing else.

Vama operations, also on the record

Organizations are provisioned and supported by a platform team whose access is granted and revoked explicitly and whose actions are audited — including in your organization's own log.

Have a security questionnaire? Send it over.

We'll answer it with the people who built the system, and walk your security team through the architecture on a call.

Talk to our team