Agentic Federated Login

at a glance

why it exists

Standard FedCM is designed for user-initiated login: the user clicks a "Sign in with Google" button, the browser shows a prompt, the user picks an account. Agentic browsers — AI agents that browse the web autonomously on a user's behalf — cannot replicate this user gesture flow. Without a structured mechanism, an agentic browser would either be unable to log the user in at all, or would resort to filling login forms programmatically (bypassing privacy protections). Agentic Federated Login extends FedCM so that an embedder (the agentic context hosting the browsing session) can initiate a credential request on behalf of the user. The identity provider still controls the user experience and can prompt for explicit consent. Chrome monitors for false positives and false negatives, degrading gracefully by stopping the agent and handing control back to the user when issues are detected.

how it works

Agentic Federated Login introduces an embedder-initiated call path into FedCM. In normal FedCM, the RP (relying party web page) calls navigator.credentials.get({ identity: … }). In agentic contexts, the embedder can trigger an equivalent flow without a user gesture on the RP page, subject to IdP and user consent policies.

Key extensions

relationship to FedCM

Agentic Federated Login is built on top of the existing FedCM API. Relying parties and identity providers that already support FedCM require minimal changes; the new surface is primarily in how the browser initiates the flow (embedder-driven vs. page-script-driven). Identity providers that want to support agentic login explicitly can signal this in their FedCM configuration endpoints. For web developers building RPs, the API shape is the same navigator.credentials.get() call — you do not need to modify existing FedCM code to be compatible.

examples

The RP-side JavaScript call uses the standard FedCM navigator.credentials.get() shape; the embedder-initiated flow distinguished above composes the same credential request without RP navigation, so this example illustrates that shared request shape:

// RP FedCM request shape (the same one the embedder-initiated flow composes)
const credential = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: "https://idp.example/fedcm.json",
      clientId: "client-id-12345"
    }]
  }
});

Conceptual pseudo-code (every helper below is illustrative, not an exposed page API): when an autonomous browsing agent encounters a false-positive account signal or anomalous session context during embedder-initiated login, the graceful degradation mechanism halts agent execution and surfaces a manual user login prompt:

// Conceptual pseudo-code - graceful degradation: halt autonomous action, fall back to manual login
async function runAgenticLoginWithFallback(embedderLoginFn) {
  try {
    const credential = await embedderLoginFn();
    // Page-local pseudo-code: detectAnomalousContext stands for the engine's
    // false-positive / anomalous-context detection described in the mechanism section.
    if (!credential || detectAnomalousContext(credential)) {
      // Detected false positive or anomalous context: stop autonomous agent action
      stopAgentAndPromptManualLogin({ reason: 'anomalous_context' });
      return null;
    }
    return credential;
  } catch (error) {
    // Graceful degradation: halt autonomous agent action and prompt user for manual login
    console.warn('Embedder-initiated login failed; halting agent for manual user login:', error);
    stopAgentAndPromptManualLogin({ reason: 'login_failed' });
    return null;
  }
}

browser support

see also

• w3c-fedid/agentic-federated-login — GitHub explainer
• W3C FedCM specification
• FedCM documentation — Chrome for Developers
• chromestatus — Agentic Federated Login (5141084139290624)
• chrome-platform-showcase — live demo