The four things that matter most
OAuth only
Connections are OAuth 2.0 authorization-code flows. There is no code path that accepts a password, personal access token, or API key.
Each user's own permissions
We call your systems with the individual user’s delegated token, so your existing ACLs apply unchanged. There is no shared service account.
Used for reads only
Connector code issues search and fetch calls only. That is not the same as every OAuth scope being read-only: Salesforce’s
api scope can authorize writes the connecting user’s profile already allows, even though we never call those operations.No sync, no index
We do not crawl, mirror, or index your content. Nothing is copied into a search index or vector store. Reads happen live, in response to a user’s question.
Connecting: the OAuth handshake
Your OAuth app issues a token scoped to one user. We store that token encrypted and never see the user’s credentials. A few details worth noting:- The one-time authorization code is bound to a CSRF state value that expires after 10 minutes.
- Tokens are stored per (user, organization, connector) — one row per person, never pooled.
- Access and refresh tokens are encrypted with AWS KMS before they are written to the database, and decrypted only in memory for the duration of an API call.
- Refresh happens lazily when a token is close to expiry. Users do not have to reconnect on a schedule.
Answering a question: the read path
Nothing is fetched on a timer. A connector is only touched when a user’s question requires it. Because the call carries the asking user’s own token, the provider decides what comes back. If a user cannot see a Slack channel or a Confluence space, neither can Voltai when answering for that user.What is stored, and what is not
Voltai does not crawl or index your corpus. It does persist connector evidence on the chat conversation that used it. Search hits store a truncated snippet. A
fetch_* tool stores the complete fetched document body (Slack thread, Confluence page, Jira ticket, Salesforce record, and similar) on that conversation — not only the quoted excerpt shown in the UI.
So the precise version of “nothing is stored” is: no bulk copy, no index, no background sync. What survives a request is the conversation record: cited search snippets, and — when a fetch tool ran — the entire fetched document body in that source’s
content field. Deleting the conversation deletes those too.
Deployment and network boundaries
- All inbound traffic terminates at an AWS Application Load Balancer fronted by AWS WAF, over TLS. Application containers run in private subnets with no public ingress.
- Calls to your systems are made server-side from our backend, outbound over HTTPS. Your users’ browsers never talk to your provider APIs on our behalf, and tokens never reach the browser.
- Every request carries a 30-second timeout, so a slow or unavailable provider degrades one answer rather than the platform.
Revoking access
You have two independent levers, and either one is enough to stop reads:1
A user disconnects in Voltai
We immediately erase that user’s stored access and refresh tokens, clear token expiry and last error, and mark the connection revoked. Subsequent questions cannot reach your system. The connection row remains, including external account ID, account label, granted scopes, provider metadata, and last used.
2
You revoke on your side
Deleting or disabling the OAuth app in Slack, Atlassian, Entra ID, Salesforce, or Assembla invalidates every token issued through it at once, for all users.
Scopes we request, per connector
offline_access and refresh_token exist only so we can refresh an expiring token without asking the user to reconnect. They grant no additional read access.
Two scopes deserve a comment in a security review. SharePoint’s
Sites.Read.All and Files.Read.All read broadly by name, but they are delegated permissions — they never exceed what the signed-in user can already open in Microsoft 365. Salesforce’s api scope is not a read-only grant: it authorizes REST and SOAP API operations the connecting user’s profile and sharing rules already permit, which can include create, update, and delete. Voltai only performs reads with that token.Questions a reviewer usually asks next
Can Voltai write to our systems?
Can Voltai write to our systems?
Connector code paths issue read and search calls only. For Slack, Jira, Confluence, SharePoint, and Assembla, the requested scopes are themselves read (or delegated read). Salesforce is the exception:
api authorizes whatever the user’s profile allows, including writes. We do not exercise those operations, but a reviewer should treat the granted Salesforce token as not read-only.Does one user's connection expose data to their colleagues?
Does one user's connection expose data to their colleagues?
No. Tokens are stored per user and a question is always answered with the asking user’s token. Two people asking the same question can legitimately get different answers, because your ACLs differ between them.
Is our content used to train models?
Is our content used to train models?
No. Retrieved content is passed to the model as context for that single answer. It is not added to a training corpus.
Where does the client secret live?
Where does the client secret live?
In your organization’s connector configuration inside our database, used only to perform the OAuth code exchange and token refresh. Rotate it whenever you like and send us the new value — no user has to reconnect.
What happens if a token leaks?
What happens if a token leaks?
Tokens are KMS-encrypted at rest and never leave the backend. If you suspect exposure, revoke the OAuth app on your side; that invalidates every token derived from it immediately.