Internet Identity’s MCP Turn Adds a Redirect—and Makes Agent Authorization Visible

Internet Identity’s latest MCP release changes a small but important part of the agent sign-in experience: the connection can now use a URL-based redirect transport instead of relying only on an embedded or application-specific flow.

The July 31, 2026 release is labeled “MCP general availability” and says it prepares Internet Identity for MCP general availability. Its most concrete protocol-facing change is support for ICRC-167 URL transport as a signer transport. In practical terms, an MCP connection can send the user through a browser redirect, where Internet Identity handles authentication and returns the authorization result to the requesting application.

That matters because MCP clients are increasingly becoming a second interface to applications. A user may authenticate in a browser, then allow an agent to call tools on that user’s behalf. Redirect-based transport gives that handoff a familiar browser boundary: the client initiates the connection, Internet Identity authenticates the user, and the application receives the resulting delegation through the defined transport.

The release also adds a visible identity choice to the MCP connection screen. Internet Identity says the interface now shows which identity the connection will act as. This is more than a usability improvement. Users can maintain multiple Internet Computer identities, and an agent that operates under the wrong principal can read or change the wrong application state. Making the selected identity explicit gives the user a checkpoint before delegation.

The same release includes a cross-domain SSO-takeover regression test and threat-model documentation. It also changes the registration path so AI access is enabled during registration and migrates existing anchors to AI access on the official connector. These changes indicate that the security boundary is not only the signature itself; it also includes which identity was selected, which domain initiated the flow, and how the connector is registered.

ICP developers should treat the update as an authorization-integration change, not as a reason to make agents broadly trusted. The Internet Identity developer guide still describes the core model: a user authenticates with a passkey or OpenID provider, Internet Identity creates a temporary delegation identity, and the canister sees the resulting principal as the caller. Delegations expire, and each frontend origin normally receives a different principal to prevent cross-app tracking.

For an MCP-enabled ICP application, the practical checklist is straightforward:

• Display the selected principal or identity context before granting access.
• Scope tools and permissions to the minimum actions the agent needs.
• Preserve origin and redirect validation when implementing the callback flow.
• Test expired delegations, cancelled sign-ins, wrong-identity selection, and cross-domain behavior.
• Verify the Internet Identity signer and delegation data on the backend rather than treating a valid signature as sufficient proof of issuer identity.

One factual limit remains: the release note says it prepares Internet Identity for MCP general availability, but it does not independently prove that every production connector has already adopted the new transport. Builders should therefore verify the deployment and connector version they actually target.

The larger shift is architectural. MCP authorization is becoming a first-class Internet Identity flow with a browser redirect, an explicit principal-selection step, and a security model that can be reviewed at the boundary between user, agent, connector, and canister.