Access & security
How Volt decides who can use channel bots and how credentials are protected.
Layers of access control
| Layer | What it controls |
|---|---|
| Volt admin (dashboard) | Installing or uninstalling a runtime requires chat module permission (all). |
| Project membership | Slack/Teams users must be ViksaAI project members (matched by email via auth-service). |
| Agent catalog | Only agents registered in builder-service for that project can be dispatched. |
| Platform RBAC | Org/project roles apply the same as the web app for sensitive operations. |
Project membership (channel users)
Before processing a message, the runtime resolves the Slack user's email and calls auth-service project-membership check for the install scope (account_id, org_id, project_id injected at deploy time).
To allow someone to use the bot, add them to the project in ViksaAI (not a separate Volt allowlist).
Credential storage
- Slack bot, app, and signing tokens are encrypted at rest in
runtime_credentials(MongoDB). - Kubernetes secrets mount tokens into the runtime pod; pods do not receive direct database credentials.
- Runtime pods receive
VOLT_ENGINE_INTERNAL_KEYto call engine APIs—not end-user JWTs.
Data persistence
Volt is designed so raw Slack message text is not persisted on the engine for compliance. Thread context is read from Slack APIs per turn. Operational state (audit, preferences, legacy RBAC collections) uses an allowlisted Mongo proxy through volt-engine-service.
Runtime isolation
Each project install gets its own Kubernetes deployment and secret. One workspace cannot access another project's agents or credentials through a shared pod.
Dangerous agents & approvals
Agents marked as high-risk in the Viksa Volt runtime can require explicit approval in-thread before execution (legacy behavior). Prefer reviewing agent definitions and RBAC in builder-service for production workspaces.