Access Evo Researcher is hosted and run by Access, and each organisation's data is kept separate from every other organisation's. This article answers the questions you're most likely to ask: where your data lives, who can see it, what the AI provider receives, and how it's kept apart from other organisations.
At a glance
Hosted by Access. The frontend, backend, database and file storage all run on Access infrastructure, in the same regions as the rest of Evo.
Separated by organisation. Data is partitioned by organisation in the database. One organisation can't see another's projects, uploads, chats or artifacts.
Limited by project. Within an organisation, only collaborators on a project can see its content.
Limited AI context. AI providers receive your message and the context relevant to it. They don't receive your whole project, and they don't use Access Evo Researcher traffic to train their base models.
Signed in through Evo. Access Evo Researcher uses your Evo sign-in, so there's no separate login.
Regional. Your data stays in the region your organisation belongs to: UK, EU, US or AU.
Where your data is stored
Data | Where it's stored | Who hosts it |
Project details, chat messages, instructions and collaborators | PostgreSQL database | Access |
Upload content split into sections, and vector embeddings | PostgreSQL database | Access |
Uploaded files | Azure Blob Storage | Access |
Artifacts | Azure Blob Storage (files) and PostgreSQL database (details) | Access |
AI keys | PostgreSQL database, encrypted | Access |
Connector data | Not stored. Fetched live from the source system | The source system, such as another Evo product or a third-party service |
Everything Access Evo Researcher stores stays within Access infrastructure. No database is hosted by a third-party vendor.
How your organisation's data is kept separate
Many organisations use the same Access Evo Researcher service, but each organisation's data is kept separate. This follows the same data separation model as the rest of Evo.
Every request is checked against the signed-in user's identity and organisation before any data is read or written. The organisation is then used to limit what the request can reach.
Customers can't access another organisation's data through the product. The only exception is a restricted administrative role held by a small number of Access staff, used for operational work.
Who can see your data inside an organisation
Within an organisation, access is controlled project by project.
Only collaborators on a project can 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 their next request.
Access Evo Researcher has two roles. Admins assign both roles in the Evo platform. There's no separate role management in Access Evo Researcher.
Role | What it allows |
User | Create and use projects, collaborate, upload files and chat |
Admin | Everything a User can do, plus manage templates, members, organisation settings and AI keys |
What the AI provider sees
When you send a message, Access Evo Researcher builds a request and sends it to the AI provider. The request contains:
Your message
The project's instructions
The relevant parts of the project's context, such as the upload sections that match your question and recent chat history
The list of tools the AI can use, such as search, upload retrieval, connectors and artifact creation
The provider generates a response and streams it back. If the AI uses a tool, the provider also sees the tool call and the result it returns.
The provider doesn't see:
Your whole project. Uploads are searched for each message, and only the sections relevant to the question are sent.
Data from other organisations. Each request is limited to one organisation and one project.
Your raw file storage. The provider receives text, not binary files.
Training and retention
Access negotiates the terms with each AI provider. In the configurations Access Evo Researcher uses today:
Providers don't use Access Evo Researcher traffic to train their base models.
Retention varies by provider. Most keep inputs and outputs only for abuse monitoring, and then delete them.
How requests are routed
Most requests go through a proxy managed by Access. The proxy lets Access control which models can be used, rotate keys, track usage and set rate limits. From the provider's side, the traffic looks the same.
Some configurations connect directly to Azure OpenAI or AWS Bedrock instead.
Third-party services
These services can handle Access Evo Researcher traffic as part of normal operation.
Service | What it sees | What it's used for |
Anthropic, OpenAI, Google, Azure OpenAI, AWS Bedrock | AI traffic for each message, limited to that request | Generating AI responses |
E2B | Short-lived isolated environments for code the AI writes | Generating charts and running scripts |
Exa | Web search queries made by the AI's search tool | Web search |
Langfuse and OpenTelemetry collectors | Traces and metadata about requests | Monitoring and troubleshooting |
Access manages these contracts centrally, and they don't permit training on customer data.
Connector data
Access Evo Researcher doesn't store data from connectors. When the AI calls a connector, the request goes to the source system, the response comes back, and Access Evo Researcher uses it for that turn.
Connector configuration, such as the URL, allowed operations and headers, is stored on the project. Secret values are encrypted.
Your sign-in credentials for third-party connectors, such as OneDrive, are stored encrypted for each user.
Connector responses aren't saved as snapshots, converted into searchable embeddings or stored as separate objects. They appear in the chat as tool results, and the chat history that includes them is stored.
What happens to your data when access is removed
When a user's access is set to No Access in Evo, or an organisation's subscription is deprovisioned, Access Evo Researcher hides the account rather than deleting it straight away.
The account is blocked from signing in and removed from collaborator search.
The user's projects are hidden from their collaborators. They aren't deleted.
A removed user who was only a collaborator on a project, rather than its owner, appears as removed on that project.
Content stays in place underneath the account.
If the user or organisation is provisioned again, the same account is restored with its projects and collaborator access.
Access can permanently erase a removed user or organisation on request, for example to meet a data erasure request. Removed accounts and their data stay in place until then.
⚠️ Important: The protection for removed accounts started on the evening of 4 September 2026 (UK time). If an account is removed and later restored, only projects, chats and artifacts created from that point onwards come back. Projects, chats and artifacts created before 4 September 2026 can't be recovered, even if the account is restored.
Encryption
In transit: All traffic uses HTTPS and TLS.
At rest: The database and file storage are encrypted at rest using Azure-managed keys.
Secrets: AI keys, MCP server credentials and third-party connector tokens are encrypted in the database. Values are encrypted when saved and decrypted only when they're used.
Sign-in and identity
Access Evo Researcher uses your Evo sign-in. When you open Access Evo Researcher from Evo, Evo confirms your identity, and Access Evo Researcher checks that confirmation on each request. Logging out of Evo also logs you out of Access Evo Researcher.
Regional data residency
Access Evo Researcher runs in four regions: UK, EU, US and AU. Each region has its own backend, database and file storage.
Your organisation belongs to one region, which is set when the organisation is set up. Its projects, uploads, artifacts and chats are stored in that region. The one exception is AI provider traffic, which is routed to a regional endpoint only where that endpoint matches your organisation's region.
Telemetry and logs
Access monitors Access Evo Researcher to keep it running reliably. Each request, tool call and AI call is traced, and logs are linked to a request ID so Access can follow an interaction from start to finish.
Telemetry records metadata rather than content. For example, it shows which connector was called, how long the call took and whether it succeeded. It doesn't include the body of the response.
If you have questions about where your data is stored, you can find more details in the Evo pillars product factsheet. To find out more, contact your account manager or an Evo product manager.