Skip to main content
Vybe gives AI coworkers access to your team’s tools and data, so access control is built in at every level. This page explains, in plain terms, who can sign in, who can see what, how credentials are protected, and where coworkers and apps run. For certifications, penetration testing and subprocessors, see the Vybe security page.

​
Signing in

Everyone signs in to Vybe with one of these:
  • Continue with Slack or Continue with Google.
  • Continue with invitation: a sign-in link and a one-time code sent to your email.
  • Continue with SSO: your company’s identity provider, over OIDC or SAML.
People only join your organization when one of these happens:
  • An Owner or Admin invites them.
  • They sign in through your organization’s SSO.
  • They’re a full member of your connected Slack workspace and Auto-join from Slack is on.
  • An app creator shares an app page with them externally, which makes them a Guest. This is only available if Vybe has enabled it for your organization.
Owners and Admins can set up single sign-on and require it for everyone with your email domain. See Organizations and Single sign-on. Published apps aren’t public. Everyone who opens one signs in to Vybe first, and only people with access to that app get in.

​
Roles and access

Access is layered:
  1. Organization. Each organization is separate. Members of one organization can’t see another organization’s coworkers, apps, connections or data.
  2. Role. Each member is an Owner, Admin, Editor, Viewer or Guest. The role decides what they can do across the organization. Guests only get apps and coworkers explicitly shared with them. See Members and roles.
  3. Each coworker and app. Every AI coworker and every app has its own access setting: open to the organization, limited to specific people, or private to its creator. See Coworker sharing and access and App access and sharing.
  4. Each connection. New integration and MCP accounts are Private (“Only you can use this connection.”) until you share them with the organization. A coworker can’t use an integration, MCP server, custom API or external database until someone grants it access, and the grant can be Read only. See Connections.

​
Encryption

  • In transit. Traffic to Vybe and to published apps uses HTTPS. Session cookies are HttpOnly and Secure.
  • At rest. Vybe’s databases are encrypted at rest. On top of that, Vybe encrypts the credentials you give it, such as API keys, custom API tokens, database connection strings, SSH private keys and Slack tokens, with AES-256-GCM before it saves them.
  • OAuth sign-ins to third-party tools. Many integrations connect through Vybe’s integration partner. For those, the partner holds the OAuth tokens, and Vybe keeps only a reference to the connected account.
Vybe never shows a saved secret again. See Secrets and encryption.

​
Isolated sandboxes

AI coworkers. When a coworker runs code or works with files, it does so in its own isolated, short-lived sandbox. Each coworker has its own file storage, shown in its Knowledge → Files. The sandbox can only reach Vybe itself. When a coworker needs data from a connection or a database, the request goes through Vybe, which checks the access you granted and adds the credentials. The coworker never sees the raw credentials. Apps. Each app’s development preview runs in its own sandbox. Only signed-in people with access to the app can open the preview.

​
Databases

  • Dedicated databases. Each app gets its own database. So does each AI coworker, and each organization database you create. They’re kept separate from each other.
  • External databases you connect (PostgreSQL, MySQL, Amazon Redshift) have Enforce Read Only on by default for PostgreSQL and MySQL, so each query runs in a read-only transaction. Vybe tests the connection with a read-only query before it saves it.
  • SSH tunnels. For databases behind a firewall, you can connect through an SSH bastion host. Vybe generates the SSH key pair. You install the public key on your server, and Vybe keeps the private key encrypted.
See Databases.

​
Slack data

Vybe connects one Slack workspace to one organization. A coworker only sees Slack conversations it’s part of: its direct messages and the channels it has been added to. In each channel it has either Read or Read and write access. When someone adds it to a channel, it gets the organization’s Default access, which Owners and Admins set under Slack channel access in Settings → Organization → General. The default is Read. Read and write only applies when the person who adds the coworker can change its permissions. Each coworker’s Sharing tab controls who can message it in Slack. With Slack memory, coworkers can learn from conversations without being mentioned:
  • They only learn from public channels they belong to, including thread replies.
  • They never learn from private channels, direct messages or Slack Connect channels.
  • They never learn from messages posted by Slack guests.
Owners and Admins can turn Slack memory off for the organization in Settings → Organization → General → Slack memory. You can also turn off Learn from Slack for a single coworker in its Knowledge section. See Slack and Knowledge.

​
Compliance

For Vybe’s certifications, reports and subprocessor list, see vybe.build/security.

​
Report a security issue

If you find a vulnerability or suspect a security problem, email security@vybe.build. For anything else, contact support@vybe.build.