Skip to content

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).

WhereSettings → Connected apps
Authorised viaOAuth
Access bounded byTool Policy · your roles
RevokeImmediate

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

  1. Open Settings → Connected apps (or the equivalent entry in your account menu).
  2. Review each row: app name, purpose (if the admin or flow provided one), scope summary, and when access was granted.
  3. 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

  1. On Connected apps, find the application.
  2. Choose Revoke access.
  3. 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.

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

  • MCP governance


    The administrator view: every OAuth client, the Tool Policies that bound them, and the audit trail.

  • Connection governance


    How Datahub governs the data connections behind the tools an app can call.

  • Microsoft Copilot integration


    A worked example of authorising an external app through the same OAuth flow.