TL;DR; this is a set of proposals to extend FedCM to provide a structured tool to agentic browsers to allow users to login to websites using their federated accounts
The web, along with computing, is going through one of the biggest foundational changes with the advent of machine learning and large language models.
While there is still much to be seen (e.g. user demand, ecosystem demand, form factors and novel security challenges to overcome), the trend in agentic browser experimentation points to more and more user journeys depending on the user being logged in to websites.
For example, for an agentic browser to assist the user with a request to “Plan a trip to Hawaii” it requires orchestrating across multiple websites (say, your usual airline, hotels and reservations), and, often, logging in to them.
As a broad approximation, users on the web today login to websites in one of two ways: passwords or federated login, roughly in equal parts.
Passwords rely on annotated <form> elements and filling them is already largely managed by browsers and password managers, so it was easier to connect them with agentic browsers.
Here is an example of how they work today in agentic browsers:
Screen.Recording.2026-03-19.at.4.52.57.PM.mov
Federation, however, is largely implemented with OAuth and SAML in userland on top of the browser using low level primitives (such as top level navigations and third party cookies), so it requires the agentic browser to use what we’ve been calling “UI actuation”: computer vision over the DOM to understand what’s going on.
The problem with “actuation” is that it is an unstructured tool that is by definition statistical, so works within a range of precision and recall.
For federated login, specifically, we struggled to tolerate that range because it would lead to a known percentage of accidental security incidents.
For example, one security concern that occurred to us early on was that, without a structured tool, there was a risk of the agentic browser accidentally creating accounts on websites without the user’s control. Signing-in to their existing accounts is a fundamentally safer action than entirely sharing your private information and creating a new account.
The main hypothesis that we formed was that when federated login is done inside of the browser with the high-level identity-specific FedCM API (rather than on top of it, with general-purpose primitives, such as top level redirects), the browser would be able to use it as a structured and deterministic tool rather than an unstructured and opaque one.
That’s yet to be seen if this is going to be a good idea, but it is the same architectural principle that is leading to the development of MCP (and WebMCP, by extension) which is to complement the statistical large language model with access to non-statistical tool execution.
Thankfully, we have been working for years now moving federation away from low-level primitives into high-level primitives.
For example, around 3% of chrome page loads call into FedCM to help millions of users login to hundreds of thousands of websites with their federated accounts.
Under that circumstance, the agentic browser can be given a tool to log the user in with the confidence that it needs, for example, semantically knowing the critical distinction between logging in and creating accounts.
At the core of this proposal is to use the current deployment of FedCM to offer federated accounts while the user is using the agentic browser: when the agentic browser needs to log a user in to a website, the agent can ask the browser if there is a pending FedCM request on the page, and if so, offer that option to the user.
Because of the market penetration of FedCM being used by hundreds of thousands of websites, we think we can cover a lot of ground without requiring any changes from anyone.
While that is a great foundation to offer to the agentic browser, there is still a meaningful amount of websites that haven’t migrated to FedCM yet that would require UI actuation.
To avoid actuation, how are we going to handle the websites that haven’t migrated to FedCM yet?
In terms of coverage, the biggest challenge to overcome is what’s called server-to-server flows.
These flows are called server-to-server because they rely on top level server-to-server navigations and account to the vast majority of how federation is used.
Because these rely on top level navigations, there are no JS SDKs running on the websites that allows us to deploy FedCM at scale without asking every website to redeploy.
Because we have no IdP-controlled JS SDK running on the page, we can’t initiate a FedCM request without changing the website. Because there are hundreds of thousands of websites, it is really hard to change all of them.
One proposal that we are actively exploring to turn server-to-serve flows into a FedCM flow just by redeploying the Identity Provider (of which there are few, in comparison to relying parties) is a mechanism that we’ve been calling IdP-Initiated FedCM (I2P and TAG Review).
The IdP-Initiated FedCM explainer goes over the mechanism in detail, but what’s important to know is that this proposal allows us to deploy FedCM by redeploying IdPs but without requiring us to redeploy RPs.
We think this proposal can be useful for agentic browsing mode and non-agentic browsing mode.
The second proposal, called the potentially_approved_sites, complements the first one to give the agentic browser a signal from the identity provider whether the user has an account on a website or not.
Unfortunately, this is a weak signal with false positives and false negatives, so there is an alternative under consideration described below with a different set of trade-offs.
With these two proposals to extend FedCM, along with its existing deployment, we think we can turn it into a structured tool that can be used safely by agentic browsers to log users to websites with their federated accounts.
The potentially_approved_sites has the unfortunate property that it might contain false positives and false negatives, so we’ve been exploring introducing a <login> element (I2P) to give the agentic browser a deterministic signal (rather than an approximate one).
We think this proposal can be useful for agentic browsing mode and non-agentic browsing mode. We are still investigating how to deploy.
There are many alternatives that we considered.
Some of the easy ones that we dismissed quickly were:
- Ignore agentic browsing and assume it is going to fade away
- Ignore federation as a critical option to login to websites in agentic browsers
- Ignore server-to-server flows
- Require every website to redeploy before we can make federation useful in agentic browsers
Some of the harder ones were:
In this variation, we would use actuation to have the agent click on the federated login buttons, so that the browser could discover whether the user has an account on the website or not.