Language: English
An AI assistant connected to ActivityInfo does not have permissions of its own. It acts as the user who authorised it. Every request the assistant makes goes through the same permission checks as a request made in the browser or through the REST API, so the assistant can read and change exactly what that user can read and change, and nothing else.
This has a direct consequence: if your role lets you view sensitive data, an assistant you authorise can view that data too. Connecting an assistant does not create a new, more limited kind of access. It hands your own access to a program that acts on your behalf.
Two gates on every request
Before an assistant can work with a database, two separate conditions have to be met.
- The database allows the MCP server. The setting is off by default, and someone with permission to change the database settings has to turn it on for that database. See Enabling the MCP server for a database.
- Your role in that database allows the operation. The assistant is subject to the grants of the role you hold, exactly as you are.
Both conditions apply to every request. Turning on the MCP server grants nobody any access to data. It only means that the users who already have access may reach it through an assistant. If either condition is not met, the tool call fails and the assistant reports the reason.
What your role controls
Your role in a database is a set of grants, and each grant applies to a resource and lists the operations you may perform. The same grants apply when an assistant makes the request. They determine:
- which folders and forms the assistant can see at all,
- which operations it can perform, such as viewing records, adding records, editing records, or changing a form's design,
- which records it can see, where a grant uses a condition to limit a role to part of a form, and
- which fields it can see or edit, where a grant restricts individual fields.
A few examples of how this plays out:
| Your role | What an assistant you authorise can do |
|---|---|
| Administrator of the database | Read every form and record, and change the design of any form |
| Add and edit records in one folder | Read and change records in that folder only. Other folders are not visible |
| A role with a condition limiting it to one province | Read only the records for that province |
| A role that cannot view a field | Not read that field, in records or in analyses |
| Read-only on the whole database | Read everything in it, including free text and personal data |
The last row is the one to think about hardest. A read-only role is not a safe role for this purpose. It stops the assistant from changing anything, but it still lets the assistant read every record it covers.
Scope narrows access, it never widens it
When you authorise an assistant, ActivityInfo asks whether to grant read access only, or also the ability to make changes. This choice is described in Authenticate.
The scope you choose can only take permissions away:
- Choose read access only, and the write tools refuse to run, even where your role would allow the change.
- Choose to allow changes, and the assistant still cannot do anything your role does not allow. It gains nothing beyond your own permissions.
So the effective permissions of an assistant are your permissions, minus anything the scope excludes, minus anything the database's MCP setting excludes.
The same question gives different answers to different people
Because an assistant inherits the permissions of whoever connected it, two colleagues can ask an assistant the same question about the same database and get different answers. A database administrator gets a figure that covers every record. A colleague whose role is limited to two provinces gets a figure that covers those two provinces, with nothing to indicate that the rest exists.
Neither answer is wrong, but neither is labelled. Before you rely on a number an assistant reports, consider what the account you connected can actually see.
Changes are recorded against your account
When an assistant adds a record, edits a record or changes a form, ActivityInfo records the change against your user account, in the same way as a change you make in the browser. The record history and the audit trail show you as the author.
Review what an assistant proposes before you accept it, particularly when it changes a form's design or edits records in bulk. Deleting a field also deletes the data entered in it.
Removing access
Three separate controls remove access, and they differ in reach:
| Action | Effect |
|---|---|
| Revoke the authorisation in your account settings | One assistant loses access on behalf of one user. See Reviewing and revoking connected assistants |
| Change or remove the user's role in the database | That user, and any assistant acting for them, loses the access the role granted |
| Turn off the MCP server for the database | Every assistant loses access to that database, for every user |
Turn off the setting for the database when you want to stop all assistant access to it, and revoke an authorisation when one connection is no longer needed.