Skip to main content
AI coworkers and apps need credentials to reach your tools: API keys, OAuth sign-ins, database passwords and SSH keys. Vybe stores them encrypted, uses them only on its own servers, and never shows them again after you save them. Not to coworkers, not to app code, and not to other people in your organization.

​
How Vybe stores credentials

Vybe’s databases are encrypted at rest. On top of that, Vybe encrypts the credentials below with AES-256-GCM before it saves them. For SSH tunnels, Vybe generates the key pair for you. You copy the public key to your server’s authorized_keys. The private key never leaves Vybe. See Databases.

​
After you save a secret

Vybe never sends a saved credential back to your browser, so nobody can view it again, including the person who added it. Where it helps you recognize a key, such as your Models Gateway key, Vybe shows a masked version. External database URLs are shown with the password hidden. To change a credential, you replace it. For example, when you edit a custom API: “Leave all credential fields blank to keep the current values, or fill them all in to replace them.” See Change or rotate a credential.

​
How credentials are used

Vybe adds credentials to requests on its own servers, at the moment a coworker or app makes a call:
  • Integrations and MCP servers. Vybe runs the action against the service with the stored sign-in.
  • Custom APIs. Vybe adds your key or token to the request. Calls that carry credentials must use HTTPS, and Vybe blocks requests to internal or private network addresses. It won’t save a custom API whose domain is one (“Domain resolves to an internal or blocked host”). Error responses are scrubbed of secrets before they come back.
  • External databases. Vybe connects with the stored URL. With Enforce Read Only on, “each query will be executed in a read only transaction”.

​
What coworkers and app code can see

​
AI coworkers

  • No raw credentials. A coworker’s sandbox can only reach Vybe. When it uses a connection, Vybe makes the call and adds the credential. The coworker sees the results, never the key.
  • Only what you grant. A coworker can’t use any integration, MCP server, custom API or external database until someone grants it access. For integrations and MCP servers you can grant Full access, Read only or Custom (specific actions). Custom APIs are on or off. Coworkers only see custom APIs scoped to Organization (all apps). See Connections.
  • Artifacts stay read-only. Artifacts a coworker publishes can only run read-only integration actions, and can only query databases that have Enforce Read Only on. See Artifacts.
  • Chats are shared. Everyone who can access a coworker can read its chats. Don’t paste secrets into a chat. Add them as a connection instead.

​
App code

  • No environment variables to manage. There’s no place in Vybe to add your own secrets or environment variables to an app. App code calls integrations and custom APIs through Vybe, and Vybe adds the credentials. See Custom APIs.
  • Its own database is set up for you. Vybe connects each app to its own database. You don’t handle that connection string.
  • Code is visible to editors. Anyone who can edit an app can read its code and its earlier versions. Never write a key or password into app code.

​
Change or rotate a credential

If you think a key has leaked, revoke it at the service that issued it first, then replace it in Vybe.

​
Best practices

New integration and MCP accounts are Private (“Only you can use this connection.”). The account’s settings dialog calls this Restricted. Switch a connection to Organization only for shared team accounts, like the company CRM. Keep personal accounts, like your own inbox, private. See Integrations.
Grant Read only when a coworker only needs to look things up, and Custom when it needs just a few write actions. Give Full access only when the coworker really needs to create, change or delete things.
Leave Enforce Read Only on for PostgreSQL and MySQL. Better still, connect with a database user that only has read permissions, so a mistake can’t change data even if the setting is turned off. Redshift has no read-only setting, so its user’s permissions are your only safeguard.
If only one app needs an API, set its Scope to Specific Apps. Coworkers can’t use it then, because they only see custom APIs scoped to Organization (all apps). Where the service allows it, create a key with only the permissions Vybe needs.
Replace API keys and database passwords on a schedule, and right away when someone with access leaves or a key may have been exposed.
Chats, instructions, knowledge and app code can all be read by other people who have access to them. Store credentials only as connections, where Vybe encrypts them.
Connect through a bastion host with a Vybe-generated SSH key instead of opening your database to the internet. See Databases.