The short version
Hosted by Access. The frontend, backend, database and blob storage are all Access-run, in the same regions as the rest of Evo.
Per-org isolation. Data is partitioned by org at the database level. One org can't see another's projects, uploads, chats, or artifacts.
Per-project access inside an org. Within an org, only collaborators on a project see its content.
LLM providers see the message and the relevant context. They don't see your whole project. They don't train on your data (terms governed centrally by Access).
Identity comes from Evo via OIDC. Researcher doesn't have its own login.
Regionalised. UK data stays in UK infrastructure; EU in EU; US in US; AU in AU.
The rest of the page expands on each of these.
Where your data lives
Data | Stored in | Hosted by |
Project metadata, chat messages, instructions, collaborators | PostgreSQL | Access |
Upload chunks and vector embeddings | PostgreSQL ( | Access |
Upload files | Azure Blob Storage | Access |
Artifacts | Azure Blob Storage (binary) + PostgreSQL (metadata) | Access |
AI keys (LLM provider credentials) | PostgreSQL, encrypted | Access |
Connector data | Not stored — fetched live | Source system (other Evo products, third-party SaaS) |
Everything that Researcher persists sits inside Access's infrastructure. There's no Researcher database hosted by a vendor.
Tenant isolation
Researcher is multi-tenant. Many orgs share the same database and the same blob storage account, partitioned at the row level by organisation_id.
Every Researcher API request resolves the caller's
(userId, organisationId)from their JWT before any data access happens. That pair scopes every query.The platform enforces this in NestJS guards — the
AccessGuardruns before a controller can read or write anything, and it attaches the resolvedorganisationIdto the request context. Downstream services use that context to filter queries.Cross-tenant queries are not possible through the API. The only way to see two orgs' data is to be a super admin, a role held by a small number of Access staff for operational work.
If you're explaining this to a customer: Researcher uses the same tenant-isolation model as the rest of Evo — orgs are isolated at the data layer, not just by application logic.
Access inside an org
Within a single org, access is gated by project:
Only collaborators on a project see its chats, uploads, instructions, artifacts, and connector configurations.
Adding a collaborator gives them full visibility into the project's content.
Removing a collaborator removes their access on the next request.
Two roles exist:
User — can create and use projects, collaborate, upload files, chat.
Admin — everything a user can do, plus manage templates, members, org settings, and AI keys.
Both roles are assigned in the Evo platform — there's no separate Researcher role management. See Access & Setup for how they're assigned.
What the LLM provider sees
When you send a message in Researcher, the backend builds a request and sends it to the LLM. The request contains:
Your message
The project's instructions (the standing brief)
A curated slice of the project's context — relevant chunks of uploads, recent chat history, available tools
The list of tools the AI may call (search, upload retrieval, connectors, artifact creation)
The provider receives that payload, generates a response, and streams it back. It then sees any tool calls the AI makes and the results those tools return.
What the provider does not see:
Your whole project. Uploads are searched per message; only the chunks relevant to the question go into the request.
Other orgs' data. Each request is scoped to one org and one project.
Your raw blob storage. The provider sees text snippets, not binary files.
Training, retention, and the terms
The terms governing what LLM providers (Anthropic, OpenAI, Google, Azure OpenAI, AWS Bedrock) can do with traffic they see are negotiated centrally by Access. They aren't Researcher-specific.
In the configurations Researcher uses today:
No training on customer data. Providers don't use Researcher traffic to train their base models.
Retention policies vary by provider. Most retain inputs/outputs only for abuse monitoring, then delete. Specifics are in Access's central LLM provider documentation.
TODO
Link to the canonical Access AI Platform page describing the LLM provider terms once the location is confirmed.
How traffic gets to the provider
Most Researcher traffic routes through LiteLLM, an Access-managed proxy. LiteLLM gives Access central control over which models can be called, key rotation, usage tracking, and rate limits. From the provider's perspective the traffic looks the same; from Access's perspective it's traceable and rotatable without touching application code.
Some configurations route around LiteLLM and call Azure OpenAI or AWS Bedrock directly.
Identity and authentication
Researcher uses OIDC via the Evo platform. There is no separate Researcher login.
When you open Researcher from the Evo nav, the Evo shell passes your identity over via signed JWT claims and HTTP headers.
Researcher trusts Evo to say who you are; it verifies the JWT signature on each request.
Your session is the Evo session. Logging out of Evo logs you out of Researcher.
Encryption
In transit — all traffic is HTTPS/TLS.
At rest — PostgreSQL and Azure Blob Storage are encrypted at rest using Azure-managed keys.
Secrets (AI keys, MCP server credentials, third-party connector tokens) — stored encrypted in the database. The application encrypts on write and decrypts on read; the raw values never sit in plain text.
Regional data residency
Researcher runs four parallel deployments, one per region. Each has its own backend, database, and blob storage.
Region | Backend |
UK |
|
EU |
|
US |
|
AU |
|
An org belongs to one region, set when the org is provisioned. All its data — every project, upload, artifact, chat — lives in that region's infrastructure. Cross-region access happens at the LLM provider level only, and only when the provider's regional endpoint matches the org's region (the AI Platform team handles routing).
Third-party SaaS dependencies
A small number of vendors see Researcher traffic in the course of operation:
Vendor | What they see | Used for |
Anthropic, OpenAI, Google, Azure OpenAI, AWS Bedrock | Per-message LLM traffic (scoped to the request) | The LLM responses |
E2B | Short-lived isolated environments for AI-run code | Generating charts, running scripts the AI writes |
Exa | Web search queries (not your data) | The AI's web-search tool |
Langfuse, OpenTelemetry collectors | Traces and metadata about requests | Observability and debugging |
The contracts governing these vendors are managed centrally by Access. They aren't Researcher-specific and they don't permit training on Access customer data.
Connector data
Connectors don't store anything in Researcher. When the AI calls a connector tool, the request goes out to the source system (another Evo product, OneDrive, an MCP server), the response comes back, and Researcher uses it for that turn.
The connector configuration (URL, allowed operations, headers) is stored on the project, encrypted where secret.
The user's credentials for third-party connectors (e.g. OneDrive OAuth refresh tokens) are stored encrypted, per user.
The data the connector returns is not stored. It appears in the chat as a tool result and is included in chat history (which is stored). It isn't snapshot, vectorised, or persisted as a separate object.
See Connectors for the connector model.
Audit and observability
Telemetry. Every request, every tool call, every LLM call is traced via OpenTelemetry. Traces flow into Langfuse (for AI-specific observability) and into Application Insights (for everything else).
Logs. Backend Pino logs are correlated to a request ID and an
operation_Id, viewable in Application Insights for stitched end-to-end transaction views.Telemetry contains metadata, not content. Spans capture which connector was called, how long it took, whether it succeeded — not the body of the response.
What changes between internal Access use and customer deployments
Researcher is in early access. Today:
Internal Access teams — the AI key is configured centrally against the Access org. You use Researcher with no setup.
Pre-production testing — teams obtain their own test key via the AI Gateway self-service tooling.
Customer deployments (future) — the provisioning team will configure an LLM key on the customer's org before enabling Researcher.
The data, isolation, and provider terms above apply equally in all three. What differs is who owns the AI key and who pays for the LLM tokens.