Before the Agent Acts: Internet Identity Makes MCP Identity Selection Explicit

The important change is not another login button

Internet Identity’s release-2026-07-31 prepares the service for MCP general availability and adds URL transport support for app sign-in. More importantly for builders, the release makes the identity behind an MCP connection visible in the sign-in flow. Its changelog also records AI access being enabled at registration, migration control through the upgrade argument, and a fix to use the current sign-in picker on /mcp and /cli.

That combination changes the security question. An agent connection is no longer just “authenticated or unauthenticated.” The user must be able to understand which Internet Identity account the connection will act as before the connection is authorized.

Why identity selection matters on ICP

Internet Identity normally gives an application an origin-specific identity. The official specification says a user has a separate identity for each client application frontend, and that delegations allow a session key to act for that identity for a limited period. The same specification also describes the prepare_delegation flow as returning the user identity before the less-secure query step, helping prevent a client from tricking a user into using the wrong identity.

MCP makes that distinction operational. A tool call may read data, submit an update, or trigger an action in a canister. If a user has several accounts or application identities, selecting the wrong one is not a cosmetic mistake: it can change the principal seen by the canister and therefore the authorization result.

The release’s “show which identity an MCP connection will act as” change is best understood as a confirmation boundary. It gives the interface a chance to expose the principal context before an agent receives delegated authority.

The protocol is changing underneath the authentication flow

The timing is significant because MCP’s 2026-07-28 specification moves the protocol toward a stateless request/response core. The MCP maintainers say the new revision retires the initialize/initialized exchange and the Mcp-Session-Id header. Requests can be routed through ordinary round-robin infrastructure, while method and tool names are available in HTTP headers for gateways and authorization layers.

For ICP builders, this reduces the value of treating an MCP connection as one long-lived browser session. A safer integration should model authorization as explicit, short-lived authority attached to a known identity and a known action path. Transport scalability does not remove the need to show the human which principal is being delegated.

The MCP release also hardens authorization by requiring issuer validation, binding credentials to the issuer that minted them, and moving toward Client ID Metadata Documents instead of Dynamic Client Registration. These are protocol-level changes, while Internet Identity’s release supplies the user-facing identity boundary around an ICP-oriented sign-in flow.

What builders should audit

First, make the selected identity visible before issuing or accepting an MCP delegation. Do not rely on the last-used identity as an implicit authorization decision.

Second, treat URL transport as a transport change, not as proof that the caller is safe. Validate the redirect and callback origin, preserve the existing delegation checks, and keep the authorization lifetime as narrow as the application allows.

Third, test account switching and migration paths. The release explicitly includes migration control for AI access and a change that enables AI access at registration. Existing users and newly registered users may therefore enter the flow through different states.

Fourth, update assumptions about MCP sessions. If an application needs state across calls, the MCP specification recommends carrying an explicit handle through tool arguments rather than hiding state in the transport session. That handle must be authorized against the selected ICP principal.

The July 31 release does not make agent authority automatic or risk-free. It makes one of the most important decisions—the identity an MCP connection will use—more visible. On a canister platform where the caller principal is part of the authorization model, that is a small interface change with a large security consequence.

Editorial caveat: The July 31 Internet Identity release says it prepares MCP for general availability; the source does not by itself prove universal production rollout. This article therefore describes a verified release-level capability, not adoption across every deployment.