MCP: revoke backend access when a trusted server is removed/disabled

[aterga]

Context

Follow-up from PR #4052 (per-user trusted MCP server, synced config) and a Copilot review note.

The gap

Removing the trusted MCP server, or turning off the master toggle, in Settings → Trusted MCP server only updates the per-identity config (now stored as synced identity_metadata). It does not revoke the backend authorization established at connect time by mcp_set_access(origin, account, true).

Consequence: a previously-connected MCP server keeps its principal -> anchor binding in the reverse index, so as long as it still holds a valid standing delegation (the user-chosen TTL, up to 30 days) it can keep calling mcp_prepare_account_delegation / mcp_get_account_delegation to mint per-app delegations — even after the user "removes" the server or disables MCP in Settings.

This is pre-existing behaviour (the earlier device-local/localStorage version didn't revoke either); the trusted-server config has always been a pre-gate for new connects, not a kill switch for existing access. PR #4052 keeps that semantics and defers the kill-switch to this issue.

Proposed work

• On remove (and on disabling the master toggle), revoke the backend binding(s): enumerate the identity's accounts at that origin (get_accounts) plus the default, and call mcp_set_access(origin, account, false) for each, so mcp_prepare/get_account_delegation calls from that server start failing immediately.
• Consider a dedicated "connected MCP servers / active access" management surface so users can see and revoke active connections independently of the trusted-server allowlist.

Notes

• Even without explicit revocation, access ends when the standing delegation expires (≤ 30 days).
• The account number used at connect isn't currently tracked in the trusted-server config, hence the get_accounts enumeration in the proposed FE fix.

🤖 Generated with Claude Code

[alexeychirkov]

I think there may be an additional implication here.

The issue body says:

Even without explicit revocation, access ends when the standing delegation expires (<= 30 days).

Is that actually guaranteed?

If an MCP server still has a valid reverse-index binding, can it call:

mcp_prepare_account_delegation(
  target_origin = its own MCP origin,
  account_number = null,
  session_key = its own key,
  max_ttl = 5 minutes
)

and then use the resulting short-lived delegation as the same MCP-origin principal to call mcp_prepare_account_delegation again?

If yes, then the old server's access would not necessarily end when the original standing delegation expires. It could keep refreshing a 5-minute delegation for its own MCP origin and continue using the principal -> anchor binding indefinitely, until mcp_set_access(origin, false) is called.

So the revocation gap may be stronger than:

old access remains until the original TTL expires

It may instead be:

old access remains indefinitely if the server keeps refreshing itself

Could you clarify whether MCP servers are intentionally allowed to mint delegations for their own MCP origin?

If not, maybe mcp_prepare_account_delegation should reject calls where target_origin is the same as the MCP server's bound origin. Alternatively, the reverse index may need to track the bound MCP origin alongside the anchor so this can be enforced.

[aterga]

Hi @alexeychirkov,

I agree with the observation, MCP servers can currently mint delegations indefinitely. Even un-toggling the switch doesn't currently remove the trusted MCP principal from the lookup index. This is a bug; we will fix this. (Note that the feature is in preview and not recommended for any real use cases apart from demos, as stated in the respective settings).

Could you clarify whether MCP servers are intentionally allowed to mint delegations for their own MCP origin?

The current implementation seems to have suffered from a mixture of two competing designs. One design is to enforce limited-time access of an MCP server's key pair via delegations (then we would need it to mint long-standing delegations via the same API as the in-app delegations). Another option is to register the keypairs that are useful only with the mcp_ API and are checked on expiry explicitly (as a precondition). I have to check which on these designs we want to keep, then do some cleanup.

We'll update this thread when we know more.

[alexeychirkov]

Thanks for confirming and for looking into it.

I'll keep an eye on this issue for updates. If there is a follow-up PR, release note, or a design decision about which model you decide to keep, could you please link it here as well? That would make it easier to track when the fix is available.

[aterga]

Update on this. The MCP connector has been reimplemented with a v2 API, now revocations are properly supported.

Please see the attached design doc.

iimcpconnectorsdesign.pdf

The 18 PRs, grouped as in the doc (all merged to dfinity/internet-identity):

Trusted server, connect flow, and delegations
• #4026— add the/mcpdelegation flow.
• #4052— per-user trusted MCP server, synced, account-bound delegations.
• #4066— drop connect-time account selection; agent lists app accounts.
• #4086— replace standing delegation with session-key registration.

Access level (read-only / permissions)
• #4016·#4087·#4089·#4100·#4090.

Connect-handshake hardening
• #4091(callback allow-list) ·#4092(registration delegation, backend) ·#4093(frontend + e2e) ·#4098(get-scoping) ·#4110(index bounding).

Connect experience
• #4106(screen design) ·#4111(auto-advance untrusted screen) ·#4069(responsive toggles).

Observability
• #4099(analytics init order).