Virbe Documentation

Security Practices

Guidance on protecting API credentials, managing Dashboard access, securing your deployment, and handling potential security incidents.

This page covers security practices for organisations using the Virbe platform. Following these practices reduces the risk of credential exposure, unauthorised access, and misuse of your virtual being deployment.


API credentials

Virbe integrations require API keys and credentials for third-party services – AI model providers (OpenAI, Azure, Anthropic), STT/TTS engines, and any external systems connected via webhooks. These credentials are sensitive.

Protect credentials at rest

  • Do not share API keys in emails, chat messages, documents, or code repositories
  • Rotate keys regularly and immediately if you suspect exposure
  • Use credentials with the minimum required permissions – create service-specific API keys where providers allow it

Protect credentials in Virbe

  • API keys entered in Configurations are obfuscated for Dashboard users;
  • Do not hard-code API keys or secrets in webhook URLs, request bodies, or System Instructions;
  • Use HTTPS endpoints only for all webhook and Custom Endpoint integrations.

If a key is compromised

  1. Revoke the key immediately in the provider's dashboard
  2. Generate a new key and update the configuration in Virbe
  3. Review recent conversation logs and webhook call logs for signs of misuse
  4. Notify your security team per your incident response policy

Dashboard access control

The Virbe Dashboard provides access to conversation logic, live conversation logs, API credentials, and deployment configuration depending on the role assigned to a particular user (read more in the "Users and Roles" chapter in Settings section). Treat access accordingly.

  • Grant Dashboard access only to team members who need it
  • Remove access promptly when team members leave or change roles
  • Use strong, unique passwords and enable MFA where supported
  • Review who has access periodically – a list of active users should be part of routine security hygiene

Profile ID and Profile Secret

Every Profile has a Profile ID (public) and Profile Secret (private). The Profile Secret is used to authenticate widget or kiosk connections to the Virbe runtime.

  • Keep the Profile Secret confidential – treat it like an API key;
  • Do not expose the Profile Secret in client-side code that is publicly readable.

Authorised domains

The Web Widget profile requires you to specify which domains are authorised to load the widget. This is a security boundary – a widget configured with your Profile credentials cannot be loaded from an unauthorised domain.

  • List only the specific domains where the widget should appear
  • Do not use wildcards unless necessary
  • Review the authorised domain list whenever you add or remove website properties

Data in conversations and system instructions

Be deliberate about what data enters the conversation pipeline:

  • Avoid injecting sensitive or personal data into System Instructions unless necessary – these are sent with every request to the AI model provider
  • Do not pass user-entered passwords, payment card data, or similar sensitive values through conversation flows
  • Use conversation variables for session-scoped data; understand that conversation logs are retained and may be viewable on the Conversations page

Webhook and integration security

When using Call Webhook or Custom Action nodes to connect external systems:

  • Authenticate requests from Virbe on your endpoint side (e.g., a shared secret in a header)
  • Validate and sanitize input before processing it in your backend
  • Return minimal data in webhook responses – only what the conversation flow needs
  • Use IP allowlisting for sensitive endpoints where your infrastructure supports it

Kiosk physical security

For kiosk deployments:

  • Enable auto-start with a dedicated local user account that has no administrative privileges
  • Use Windows Assigned Access or a similar kiosk-hardening mechanism to restrict physical access to the operating system
  • Ensure the physical device is in a location where it cannot be tampered with easily
  • For remote access (TeamViewer, AnyDesk), use strong passwords and restrict access to named administrators
  • Enable security PIN in kiosk profile settings that will be required to open settings on the kiosk device.

On this page