Security boundaries

DataQI evaluates source and tool access using the connection owner for the current execution. Personal interactions use the signed-in user’s access, while workflows use the DataQI system identity’s access. DataQI does not combine these scopes.

Personal interaction boundaries

Personal chat and agent operations use the signed-in user’s active connections and the source records derived for that user. One user’s connection state and data visibility are not available to another user.

File system connection boundaries

Personal enterprise file system routes use User Identity Delegation (UID). DataQI does not promote personal file access through a global service account. An agent’s visibility is limited to the authenticated user’s permissions in the source system.

If User A can access a file but User B cannot, User A’s connection state or data visibility is not available to User B and does not influence User B’s responses.

Workflows do not borrow the initiator’s delegated file access. They use only file system connections authorised for the DataQI system identity and the permissions of the external account associated with those connections.

Workflow boundaries

Workflows execute as the DataQI system identity. They use only connections authorised for DataQI and cannot fall back to an initiating user’s connection. The initiating user or application remains attributable, but it is not the workflow’s source-data authority.

Workflow outputs may contain derived text, safe metadata or a source URL. Viewing that output does not grant direct access to DataQI-owned source records, datasets or file downloads. The external source still applies its own access checks when a viewer follows a URL.

See Connection authentication before selecting an external account for shared workflow use.

MCP tool boundaries

DataQI connection definitions for Model Context Protocol (MCP) servers are configured at environment level. Authentication and source visibility remain scoped to the connection owner. An agent can use an MCP tool only when its definition permits the server URL and the current execution identity has an active matching connection.

The MCP provider applies the permissions of the external account authorised for that connection. For a workflow, this is the account associated with the DataQI system identity’s connection rather than the initiating user’s personal account.

Relational database query boundaries

The SQL query capability uses the credentials configured for the selected relational database connection. DataQI applies application-level query precautions, but the database account’s permissions define the capability’s maximum reach.

Database permissions remain authoritative

Database administrators must provide dedicated, least-privileged credentials with read access limited to the required schemas, tables and views. Application-level SQL validation and transaction rollback do not replace database-level authorisation.

Trust partitioning

When agents process a request, they combine the natural-language query, system instructions and relevant context, such as retrieved documents.

DataQI uses trust partitioning to reduce the risk of prompt injection, where instructions embedded in untrusted content attempt to override the agent’s intended behaviour. User-supplied and retrieved context is tagged, escaped and wrapped separately from core system instructions before it is sent to the AI model.

Trust partitioning reduces this risk but does not replace least-privilege connection configuration or provider-side authorisation.