Vibier — Security & data handling

Vibier is a Slack-native AI marketing assistant for B2B marketing teams. It connects to a team's existing tools, learns their brand voice, and drafts and plans marketing work inside Slack.

This document summarizes how Vibier handles and protects customer data.

Where data lives

Vibier runs on three managed infrastructure providers, each with its own security posture.

Anthropic

AI agent state

Customer-specific agent memory, vault credentials, and session history are held by Anthropic's managed infrastructure, encrypted in transit and at rest. SOC 2 report and DPA available via Anthropic's Trust Center.

Supabase

App & database

Customer records, connector status, session metadata, and encrypted credentials. All data encrypted at rest with AES-256 and in transit via TLS. SOC 2 report available on request.

Railway

Compute

Hosts Vibier's services — request routing and onboarding.

Model training: Vibier uses Anthropic's commercial API. Anthropic does not train its models on data submitted through the commercial API. Customer data is never sold and is never used to train third-party models.

How credentials are protected

Credentials Vibier stores in its own database are encrypted with AES-256-GCM (authenticated encryption), using a unique random nonce per record. The encryption key is held only as a managed environment secret — never in source control.

Stored encrypted at the application layer: the customer's Slack bot token, the customer's Anthropic API key (where they bring their own), and the customer's X app credentials and OAuth tokens.

Other connectors (Google Workspace, HubSpot, Notion, LinkedIn) have their OAuth tokens written directly into Anthropic's managed vault. Vibier's database holds only an opaque pointer — the plaintext token never reaches it.

A database integrity constraint makes it impossible to enable a credential-backed feature without the encrypted credential actually being stored; the toggle and the ciphertext cannot drift apart.

Tenant isolation

Vibier is multi-tenant, and isolation between customers is enforced in code, not by convention. The isolation model was independently audited before partner onboarding; all findings were closed and verified. The enforced rules:

Every database read is filtered by the authenticated tenant; a request cannot read another customer's rows.
Customer-specific URLs are cryptographically signed (HMAC) and return not found — never unauthorized — on a bad or missing token, so tenant identifiers cannot be enumerated.
Any resource identifier supplied by the AI agent is verified against the authenticated tenant before it is acted on.
The tenant boundary is derived from the authenticated session, never from a value the agent or caller can supply.

Access & permissions

Slack

Vibier installs as a standard Slack app via the workspace admin's OAuth approval. It requests 22 bot-token scopes — no user-token scopes and no admin scopes. The bot can only act as itself (it can never impersonate a human user) and only sees channels it has been explicitly added to. The admin sees the exact scope list at install time. Vibier can be removed at any time via Manage apps → Vibier → Remove App, which revokes the bot token immediately.

All 22 Slack bot scopes

app_mentions:read channels:history channels:read channels:join chat:write chat:write.public commands files:read files:write groups:history groups:read im:history im:read im:write links:read links:write mpim:history reactions:read reactions:write users:read users:read.email team:read

Third-party connectors

All third-party access (Google, HubSpot, X, Notion) goes through each provider's standard OAuth 2.0 flow, initiated by the customer clicking a signed link from inside Slack — the agent cannot begin a connection on its own. Each connector requests the narrowest scope that supports its job:

Google Drive — read files the user shares; write only files Vibier itself creates (cannot edit or delete pre-existing team files).
Gmail — read and send; no permission to modify, label, or delete existing mail.
Google Calendar — read/write events only; no calendar-sharing or ACL changes.
X (Twitter) — uses the customer's own X app via OAuth 2.0 with PKCE; Vibier never sees the customer's password.

The customer approves these scopes on each provider's own consent screen. Vibier never sees or stores customer passwords. Access can be revoked at any time from the provider's own settings, which immediately cuts off Vibier.

Encryption in transit

All connections use TLS 1.2+ — between Slack and Vibier, between Vibier and the Anthropic API, between the agent and its connected tools, and on all customer-facing endpoints.

Audit & access controls

An append-only audit log records actions with the actor type — human, AI agent, or system.
Row-Level Security is enabled on customer-scoped database tables as defense in depth.

Compliance posture

Vibier is an early-stage product and is pre-SOC 2 — we have not yet completed a formal SOC 2 or ISO 27001 certification for Vibier itself. We operate against documented internal security practices, and we inherit the certified security posture of our infrastructure providers (Supabase, Anthropic, Railway), whose SOC 2 reports and DPAs are available on request. Formal certification is planned as we scale.

Data handling

Deletion. A customer's data — database records and the associated AI agent, memory stores, and vault credentials — can be fully removed on request.
Retention. Audit logs are retained for operational and security purposes.
Product usage. Vibier reviews how the product is used — aggregate usage patterns, and for design partners, conversations with the assistant — to improve the product. Customer data is never sold, and is never used to train third-party models.

Questions, or need our providers' SOC 2 reports and DPAs? Email leon@vibier.io.