Connected apps¶
See every third-party app you have authorised to act in Datahub on your behalf, review exactly what each one can reach, and cut off its access the moment you stop trusting it.
Audience: End users (anyone who signs in to Datahub).
Connected apps are external applications you allowed to access Datahub on your behalf through Datahub's OAuth flow — for example an MCP desktop client that calls tools with your permissions. They are not the same as workspace integrations (Microsoft 365, Databricks, and so on) configured by administrators.
What you can do here¶
-
See what you authorised
Every app that holds a standing grant you personally approved, in one list.
-
Review each app's reach
Read the scope summary — the grouped set of tools an app may call as you.
-
Revoke access
Cut off an app you no longer use. Its tokens are invalidated immediately.
-
:material-eye-alert-outline:{ .lg .middle } Catch unexpected activity
Spot an app you don't recognise and shut it down before it does more.
When this isn't the surface you want
- Workspace integrations (Microsoft 365, Databricks, …) that your administrators set up are not listed here — they live in Administration, not under your account.
- Governing which tools any client may call, org-wide is the administrator's job on the MCP governance page. Connected apps only ever shows grants you approved.
The life of a connected app¶
You authorise an app once through the OAuth consent screen; from then on it holds a standing grant and can act as you within its scope — until you revoke it.
flowchart LR
AUTH["You authorise an app<br/>OAuth consent · allow once / always"] --> GRANT[("Grant recorded<br/>app name · purpose · scope")]
GRANT --> ACT["App acts on your behalf<br/>within its scope + your roles"]
ACT --> CHECK{"Still trust it?"}
CHECK -->|keep| ACT
CHECK -->|Revoke access| STOP(["Tokens invalidated<br/>app must sign you in again"])
classDef accent fill:#ff8400,stroke:#e67700,color:#ffffff,font-weight:600;
class STOP accent
Figure 1 — The life of a connected app. Consent creates the grant; the app then acts as you until you revoke, at which point its active tokens are invalidated and it must ask you to sign in again.
Connecting a new AI agent¶
From anywhere in Datahub, open your user menu. Under Connect an AI agent a dropdown shows the provider you are currently connected to (or a placeholder if none). Pick another provider to connect it — if you already have one connected, confirm the switch first. You get the Datahub MCP server URL and a short walk-through, without leaving the page you are on. After you approve access, a confirmation appears and the header shows an AI connected pill that links back here. Switching does not revoke the previous grant; use Revoke access on this page when you want to cut an agent off.
flowchart LR
MENU["User menu:<br/>AI agent dropdown"] --> PICK{"Already connected?"}
PICK -->|no| MODAL["Guided modal:<br/>copy MCP server URL"]
PICK -->|yes| CONFIRM["Confirm switch"]
CONFIRM -->|confirm| MODAL
MODAL --> APP["Paste URL into<br/>AI app's connector settings"]
APP --> OAUTH["AI app starts OAuth/PKCE"]
OAUTH --> CONSENT["Datahub consent screen"]
CONSENT --> GRANT["Grant created"]
GRANT --> PILL["Header shows<br/>Connected pill"]
classDef accent fill:#ff8400,stroke:#e67700,color:#ffffff,font-weight:600;
class GRANT accent
Figure 2 — Connecting an AI agent. The user-menu dropdown shows the current provider. Picking another one asks you to confirm the switch, then you copy the MCP server URL from the guided modal, paste it into the AI app, and approve Datahub's consent screen. The grant is the same one you manage on this page.
Same grants as this page
The header entry point and Connected apps manage the same grants. Use Revoke access below when you want to cut an agent off — the header pill updates as soon as you do.
Why review this regularly
Every app you approved with Don't ask again ticked is a standing grant that keeps working until you remove it — even ones you forgot about. A quick scan of this list, and a revoke on anything you no longer use, keeps your footprint small.
What each row shows¶
| Column | What it tells you |
|---|---|
| App name | Which application you granted access to. |
| Purpose | Why it asked for access, if the admin or flow provided one. |
| Scope summary | A grouped, readable summary of the tools the app may call. |
| Granted | When you approved the access. |
What an app can reach¶
An app never gets a blank cheque. Its reach is the overlap of two limits: the tools the Tool Policy bound to that client allows, and what your own identity and roles already let you see. It receives scope-limited OAuth tokens for API access — never your password.
flowchart LR
APP["Connected app"] -->|OAuth token, not your password| GATE{"Access is the overlap of…"}
POL["Tool Policy on the client<br/>which MCP tools are allowed"] --> GATE
ME["Your identity + roles<br/>what you may see"] --> GATE
GATE --> REACH["What the app can actually<br/>do on your behalf"]
classDef accent fill:#ff8400,stroke:#e67700,color:#ffffff,font-weight:600;
class GATE accent
Figure 3 — What bounds an app. An app can only call a tool if the Tool Policy on its client allows it and your own roles permit it. The exact set depends on the policy your organisation assigned to the client.
| Apps can | Apps cannot |
|---|---|
| Call the MCP tools allowed by their Tool Policy. | See your password. |
| Act only within your own identity and roles. | Exceed the granted scope or policy. |
| Receive scope-limited OAuth tokens for API access. | Reach anything the policy denies. |
What the consent screen shows
The consent screen lists a summary of tools (grouped and capped for readability), not every low-level field. Exact behaviour depends on the policy your organisation assigned to the client.
Connecting as your role¶
Some connections are role-scoped: instead of exposing one fixed toolset to everyone, they scope each person to their own role (Data Steward, Viewer, and so on). On these, the consent screen and the Connected-apps row show "Connecting as {your role} — N tools", where N is what you can actually reach — the overlap of the app's policy and your role. A colleague on the same app may see a different count.
If your role has no tools configured for that connection, you will see a "No policy for your role" notice and the connection will grant you nothing until an administrator binds a policy to your role. You can still complete consent, but the app will not be able to act until then. If you expect access and see this notice, ask your administrator to bind a policy to your Organizational Role.
Reviewing your connected apps¶
- Open Settings → Connected apps (or the equivalent entry in your account menu).
- Review each row: app name, purpose (if the admin or flow provided one), scope summary, and when access was granted.
- If you no longer use an app, use Revoke access and confirm. This invalidates its tokens; the app must ask you to sign in again.
Revoking access¶
- On Connected apps, find the application.
- Choose Revoke access.
- Confirm in the dialog.
Revocation is immediate
Revocation takes effect immediately for active tokens. To use the app again, sign in through it to create a fresh grant.
The consent screen¶
When an app first asks for access, the consent screen shows who is connecting, the account it will act as, and what it will be able to do:
| Section | What it tells you |
|---|---|
| Make changes | The areas of Datahub where the app can create, edit, run or archive things as you. When no tool can change anything, the screen says Cannot make changes instead. |
| View | The areas the app can read. |
| All tools | The exact tool names, grouped per area, with every tool that can change data flagged. |
Then you decide:
| Choice | What it means |
|---|---|
| Allow access | Approve this request without keeping a standing grant. |
| Allow access with Don't ask again ticked | Record a standing grant so the app can keep acting as you until you revoke it. |
| Cancel | Refuse; the app gets nothing. |
Allow access stays unavailable until the screen has loaded what the app will be able to do. If it cannot load that, only Cancel is offered; start the connection again from the app.
When you're not sure
If you are unsure whether to approve consent, ask your data or security team before choosing Allow access.
Who controls what¶
Your Connected apps view and the administrator's MCP governance console act on the same clients from two angles.
| You — in Connected apps | Your administrator — in MCP governance |
|---|---|
| See the apps you personally authorised. | See all OAuth clients org-wide. |
| Revoke a grant you approved. | Revoke tokens or archive a client. |
| — | Define the Tool Policy that bounds each client. |
Privacy & security¶
- Revoke access if you lose a device, stop using an app, or notice unexpected activity — then contact your administrator if needed.
- Organisations can audit tool usage (allow / deny, purpose, client) from MCP governance; details depend on your org's retention settings.
- Apps only ever hold OAuth tokens scoped to what you granted — they cannot read your password or step outside the policy bound to their client.
Troubleshooting¶
| Symptom | Likely cause | What to do |
|---|---|---|
| I don't recognise an app in the list | You approved it and forgot, or it was granted in error | Revoke access and tell your data or security team. |
| An app I use isn't listed | Only grants you personally approved appear here | Admin-configured workspace integrations (Microsoft 365, Databricks) live in Administration, not on this page. |
| I revoked but want the app back | Revocation is final for those tokens | Sign in through the app again to create a fresh grant. |
| I don't see Connect an AI agent in my user menu | Your administrator has not made any integrations connectable | Ask an administrator to register an AI-agent client on MCP governance. The dropdown lists every connectable agent and shows which one you are connected to. |
| I'm unsure whether to approve a new app | — | Ask your data or security team before choosing Allow access. |
See also¶
-
The administrator view: every OAuth client, the Tool Policies that bound them, and the audit trail.
-
How Datahub governs the data connections behind the tools an app can call.
-
A worked example of authorising an external app through the same OAuth flow.