OAuth Tools
Transparency is central to us at Intric. For certain tools to work (e.g. retrieving documents from SharePoint), the user needs to connect a personal integration. Here we describe step by step how the data flow works when an assistant uses an integration tool.
The process from your message to a finished response occurs in an interplay between Intric’s platform, the language model selected for the assistant, and the provider’s API (e.g. Microsoft Graph). Intric always acts as the intermediary — the language model never contacts the provider directly.
Step-by-step: How your data is handled
All transfers between Intric and external providers occur over secure, encrypted connections.
Step 1 — User interacts with Intric in the browser
The user writes a message to an assistant that has one or more OAuth integration tools configured (e.g. SharePoint).
Data sent to Intric’s server:
- The user’s message
- Chat history
- Any attached files
Example: “Summarize the document ‘Q1 Report’ from our SharePoint.”
Step 2 — Intric calls the assistant’s selected language model
In this step, relevant content from Intric’s servers is sent to the assistant’s selected language model.
What happens at the language model: The model determines that a tool should be used.
Reasoning (example): “The user wants a summary of a document stored in SharePoint; I need to retrieve it first.”
Response: The model sends a request to Intric to use the sharepoint_search tool, with the required parameters (e.g. file name or search query).
Step 3 — Intric checks access and manages the token
Intric’s server receives the response from the language model with a request to call the tool. Intric verifies that the called tool (e.g. SharePoint) has access to the integration and that the current user has an active connection.
If access exists, Intric retrieves and decrypts the user’s access token. If the access token has expired, Intric uses the stored refresh token to obtain a brand new access token from the provider. The new token is encrypted and stored.
Step 4 — Intric calls the provider’s API
Once Intric has a valid access token, a call is made to the provider’s API (e.g. graph.microsoft.com). The valid access token is included in the call’s header to authenticate the request.
Data sent from Intric’s server:
- The action and parameters specified by the language model (e.g. file name or search query)
- Access token (in the call’s header)
The LLM never contacts the provider’s API directly; all communication goes through Intric’s backend.
Step 5 — Response to Intric from the provider
The provider’s API returns a response or confirmation to Intric.
Data sent from the provider’s API to Intric:
- The requested content (e.g. the document’s text or metadata)
Step 6 — Intric processes the response with the language model
Intric sends the tool result and the required context to the assistant’s selected language model so the model can formulate a response to the user.
Data sent from Intric’s server to the LLM (second call):
- The original prompt and conversation history
- The tool result
What happens at the language model: The model processes the result and sends a response back to Intric.
Both the call to the language model and the response back to Intric are shown in the same step in the diagram.
Step 7 — User sees the response in the browser
The response is displayed to the user in Intric in the browser.
Data stored on Intric’s servers:
- The generated response and the history from the user’s interaction with the assistant (according to the assistant’s deletion settings)
- Metadata about tool calls and results in the conversation history
Data sharing and privacy
Intric applies the principle of data minimization. With OAuth integrations there are two separate privacy considerations — data is sent to both the language model and the provider’s API. Below you can see exactly what data is shared at each step.
Intric ↔ Language Model (LLM)
| Sent to the LLM | Not sent to the LLM |
|---|---|
|
|
Intric ↔ Provider API
| Sent to the provider | Not sent to the provider |
|---|---|
|
|
Authentication and access control via OAuth
Intric uses OAuth 2.0 to connect users to third-party services. Each user authenticates directly with the provider and approves the required permissions — Intric never sees or handles the user’s password.
Token management at the individual level
When a user has approved the connection, Intric stores an access token and a refresh token per user and integration. Tokens are encrypted with Fernet encryption (AES-128-CBC) before being written to the database and are decrypted only in memory at the moment they are needed for an API call. No token is stored in plain text and each token is tied to a single user — there are no shared or organization-wide tokens.
If an access token expires, Intric automatically uses the stored refresh token to request a new access token from the provider. The new token is encrypted and replaces the old one. The entire process occurs without the user needing to log in again.
Permission control based on the user
Each access token is linked to the individual user’s account with the provider and carries exactly the permissions the user has in the external service. This means that when Intric calls the provider’s API with this token, the provider returns only the content that the specific user is authorized to access. If a user only has read access to certain SharePoint pages, for example, Intric cannot retrieve content from pages the user does not have permission to access. Permission control is handled entirely on the provider’s side — Intric’s integration has no technical ability to change, extend, or otherwise affect the user’s permissions or access.
Data storage and deletion
Tokens are stored encrypted on Intric’s servers in Sweden for as long as the integration is active. When a user disconnects an integration, all tokens are deleted immediately.
Conversation history where integration tools have been used follows the same deletion rules as other assistants.
Administrators can monitor how the service is used via the audit log where enabled.