Security overview
This page is for the people who review VirtuAI before their company uses it. It describes what the service does today. Each section links to the page where an administrator configures it.
Hosting
Section titled “Hosting”VirtuAI runs on Google Cloud in the us-central1 region (Iowa, United States).
| Component | Google Cloud service |
|---|---|
| Application | Google Kubernetes Engine (GKE), with at least two replicas |
| Database | Cloud SQL for PostgreSQL, reachable only on a private network |
| Uploaded files (knowledge base documents, avatars) | Cloud Storage |
The admin console, web chat and every API are served over HTTPS from app.imvirtuai.com, with a certificate managed by Google. The database has no public IP address and accepts only encrypted connections.
See Architecture and data flow for a diagram and a table of where each kind of data lives.
Encryption
Section titled “Encryption”In transit. Browsers, channels and API clients reach VirtuAI over HTTPS. The application reaches the database over an encrypted connection.
At rest. Google Cloud encrypts the database and Cloud Storage at rest by default.
Secrets. On top of that, VirtuAI encrypts these values itself before storing them:
- Every setting marked as a secret in Settings: model provider keys, the Twilio auth token, service account JSON files, OAuth client secrets
- The client secret of your identity provider
- OAuth tokens for the MCP servers your agents connect to
- The credentials in an agent’s Telegram and Slack configuration: bot tokens, the Slack signing secret and the Telegram webhook secret
Secrets are write-only. Once saved, Settings shows Configured (not viewable), an agent’s channel configuration shows Configured, and no API returns the value. The Telegram webhook secret is generated by VirtuAI and never shown at all.
Hashed, never stored. Passwords are hashed with bcrypt. Integration keys and invitation links are stored as keyed hashes, so VirtuAI can check them but can’t show them again. The full value appears once, when it’s created.
Custom tool headers. Header values are returned only to people who can edit tools (tools.edit). Everyone else, including viewers and people who see an agent’s tools, gets the header names with the values masked.
Signing in
Section titled “Signing in”People sign in to VirtuAI in one of these ways:
- Email and password. Accounts are created by invitation only; there is no self-service sign-up. Passwords must be at least 8 characters. There is no self-service password reset: a workspace admin sets a new password from Users.
- Single sign-on (OIDC). Each workspace can connect its own identity provider, such as Keycloak or any OpenID Connect provider. VirtuAI uses the authorization code flow with PKCE, accepts only the email domains you list, and maps your identity provider’s groups to workspace roles. See Single sign-on.
- Google Cloud Identity-Aware Proxy (IAP). For an employee web chat published behind IAP, VirtuAI can accept the identity IAP asserts instead of asking for a password. This is a deployment option, not the default. Ask support if you need it.
Sessions last at most 24 hours. With SSO, a session also ends when the identity provider’s token expires. Signing out ends the session on the server, not only in the browser, and VirtuAI accepts back-channel logout from your identity provider, so ending someone’s session there also ends it in VirtuAI.
Password sign-in can be turned off for a deployment so that SSO is the only way in. Ask support.
Workspace isolation
Section titled “Workspace isolation”Everything in VirtuAI belongs to a workspace: agents, tools, knowledge bases, conversations, settings, provider keys, budgets and roles. Your company’s workspaces are separate from every other customer’s.
On every request, the server checks that the signed-in person is an active member of the workspace the request names, and it filters the underlying data by that workspace. This isn’t enforced only by hiding things in the interface. Deactivating someone’s membership stops their access to that workspace on their next request.
See Workspaces.
Access control
Section titled “Access control”Inside a workspace, what a person can do comes from their role. A role is a set of permissions such as agents.publish or conversations.pii_reveal. Every workspace starts with admin, user and viewer, and you can create custom roles.
Some rights are split on purpose so they can be granted separately:
- Listing conversations (
conversations.view) is separate from reading someone else’s transcript (conversations.audit), and both are separate from unmasking sensitive values (conversations.pii_reveal). - Editing an agent (
agents.edit) is separate from publishing it to every channel (agents.publish). - Editing evaluation datasets (
evaluations.manage) is separate from running them, which spends model budget (evaluations.run).
Platform administrators are the people who operate the VirtuAI service. They create workspaces, and in a workspace they belong to they pass every permission check. They are also the only people who can see the service’s application logs. Workspace admins can’t grant this access, and SSO group mappings can’t either.
Our policy on when VirtuAI staff may access a customer workspace, and how that access is approved and recorded, is available on request at admin@imvirtuai.com.
See Users and roles and the Permissions reference.
Channel authentication
Section titled “Channel authentication”Every channel that reaches VirtuAI from outside is verified with the mechanism its platform provides, and requests that fail the check are rejected:
| Channel | Check |
|---|---|
Twilio’s X-Twilio-Signature, computed with your Twilio auth token over the webhook URL |
|
| Google Chat | Google’s signed token, checked against your Google Cloud project number |
| Slack | The Slack app’s signing secret, with requests older than five minutes refused |
| Telegram | A secret VirtuAI generates when the webhook is registered. The bot also answers only people who joined with an invite. |
| Web chat | A signed-in workspace member |
| Voice | An integration key in the X-API-Key header or api_key parameter, when enforcement is on |
| A2A | OAuth client credentials you create and revoke |
Integration keys belong to one workspace, can be revoked at any time, and are stored hashed.
See Integration keys and each channel’s setup page.
Your model keys
Section titled “Your model keys”Each workspace can add its own keys for the providers its agents use: Google Gemini, OpenAI or Anthropic, directly or through Vertex AI with your own Google Cloud service account. When a workspace has its own key, prompts and replies go from VirtuAI to that provider under your account, so that provider’s terms and data controls apply. If a workspace has no key for a provider, VirtuAI may use the platform’s own key for it; add your keys in Settings if you need every call to run under your account.
You can cap token use and estimated cost per provider or model with Budgets.
Sensitive data and audit
Section titled “Sensitive data and audit”As messages are stored, VirtuAI scans them for credit card numbers, API keys, private keys, passwords and bank accounts. It can also scan for national ID numbers, phone numbers, email addresses and IP addresses if you turn those on. Values are masked on the server before they reach the screen or an export. Unmasking requires its own permission, and every transcript view, reveal, export and re-scan is written to an access log.
Detection only affects what people see in the Conversations screen and in exports. The agent, the model provider and the person in the chat still see the original text.
See Sensitive data and Conversations.
Data retention
Section titled “Data retention”| Data | How long it’s kept |
|---|---|
| Conversation history in Conversations | 365 days by default. A workspace admin can set 1 to 3,650 days with conversations.retention_days. |
| Web chat history shown to the person chatting | The last 10 messages the person sent, with the agent’s replies |
| Token and cost usage records | 90 days |
Retention of other data (WhatsApp, Google Chat and voice message records, agent memory, knowledge base files), data deletion when a subscription ends, and backups are described on request at admin@imvirtuai.com.
Other services involved
Section titled “Other services involved”Besides the model provider you choose, some features send data to other services:
- Channel providers you connect, such as Twilio for WhatsApp, Google Chat, Slack and Telegram, receive the messages sent on their channel.
- Voice can use ElevenLabs for speech and Google Cloud Speech-to-Text to transcribe voice messages.
- Knowledge bases send document text to the embedding provider set in
EMBEDDING_PROVIDER(Google, Vertex AI or OpenAI) to build the search index. - Optional integrations you configure, such as LangSmith tracing, the E2B code sandbox, MCP servers and custom tools, receive what the agent sends them.
- Product analytics. VirtuAI sends usage events to PostHog, hosted in the United States. They include the model, token counts, cost, latency, and the prompt and response text of model calls.
The current list of subprocessors is available on request at admin@imvirtuai.com.
Security reports and incidents
Section titled “Security reports and incidents”To report a vulnerability or a suspected incident, contact support.
Information about our incident response process and any third-party assessments is available on request at admin@imvirtuai.com.