Connection authentication

DataQI keeps personal connections separate from connections used by automated workflows. In both cases, the external provider decides what the authorised account may access.

Connection definitions, including MCP server and relational database configuration, are managed at environment level. Authentication and derived source visibility remain scoped to the user or system identity which owns the connection instance.

User-scoped connections

Personal enterprise file system connections use User Identity Delegation (UID). When an agent searches a Windows file share on your behalf, it delegates your identity rather than using a global administrative account.

Your source permissions define DataQI’s reach

If you cannot naturally see a file or folder in Windows Explorer, DataQI cannot see it through your personal connection either. DataQI does not promote personal data beyond the permissions granted to you in the source system.

One user’s connection state and source visibility are not available to another user or to a workflow.

Authentication vs authorisation

DataQI differentiates between proving who you are and permitting access:

1. Authentication (identity): Your organisation’s Single Sign-On (SSO) proves your identity when you sign in to DataQI.
2. Authorisation (consent): You explicitly permit DataQI to use a connection to access a specific data route on your behalf.

Deferring authentication

When you sign in, DataQI may prompt you to authenticate newly available data sources. You may choose Auth Later or dismiss the prompt.

Deferring authentication does not block the rest of DataQI. Features which need the deferred connection remain unavailable until you authenticate it. You can connect, reconnect or disconnect personal connections from your profile.

DataQI workflow connections

An administrator with user-management permission can authorise connections for the DataQI system identity. Workflows run with this identity and can use only its active connections and the source records derived from them. The user or application which starts a workflow is recorded for attribution but does not lend personal connections or source access to the run.

Three identities can therefore be involved:

Identity	Purpose
Administrator	Selects and authorises the external account.
DataQI system identity	Owns the connection and supplies the workflow’s DataQI access scope. It is not an external-provider login.
Authorised external account	Supplies the permissions which the provider applies and records in its audit history.

The connection page shows the external account label when the provider reports one. Account not reported by provider means that DataQI cannot display provider attribution; it does not mean that the connection is anonymous.

Shared access

A workflow author or initiator may exercise every permission available through a DataQI workflow connection by changing a workflow definition, prompt or input. Do not authorise a personal, administrative or broadly privileged account unless that shared access is intentional.

Select and maintain the external account

• Prefer a dedicated organisational or functional account with only the permissions required by the workflows which use the connection.
• Check that the provider permits the account and authentication method. Some providers require specific licences, consent or service-account configuration.
• Keep provider consent and conditional-access rules aligned with the intended unattended use.
• Rotate credentials according to your organisation’s policy, and reconnect DataQI after provider-side credential or consent changes when required.
• Disconnect the DataQI connection and revoke provider-side access when the integration or account is retired. Offboarding the administrator who originally authorised it does not automatically revoke the external account.
• Reconcile DataQI administration records with the external provider’s audit records. Provider-side records identify the external account, while DataQI records identify the administrator, DataQI system identity and connection operation.

Relational database credentials

The SQL query capability uses the credentials configured for the selected relational connection. The database account’s permissions are the primary security boundary.

A database administrator must provide a dedicated, least-privileged account with read access limited to the required schemas, tables and views. Do not grant owner, administrative, superuser or data-modification permissions.

See Security boundaries for how these identities affect agent and workflow access.