From 91303fdc6ce4c93d881774c803fbb7d274c14990 Mon Sep 17 00:00:00 2001 From: Ilya Grigorik Date: Wed, 24 Sep 2025 12:33:52 -0700 Subject: [PATCH] [WIP] Proposal: `Sec-Fetch-Agent` HTTP request header MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Some browsers are now offering built-in agents that operate within user's authenticated browser context and can automate browser tasks: interacting with a page, navigating across pages, operating across tabs. These workflows can operate in a foreground or background tab. Because the agent is operating with user's context and can share the session with the user — back and forth hand-off workflows — they become ~indistinguishable from humans interacting with the content. Proposal:`Sec-Fetch-Agent` as sibling to `Sec-Fetch-User` that agents can use to self-identify actions that are performed by an agent from user's context. This provides transparency to site operators, and provides signals that a site can use to facilitate the agent (e.g. additional content, potentially exposing WebMCP tools, etc), and/or allows the site to signal to the agent that user review or input is required to proceed. ### Example flow - Buyer navigates to product page - Sec-Fetch-User: ?1 - Buyer asks agent to compare and build a cart - Agent takes over - Sec-Fetch-Agent: ?1 (while performing the task) - Agent navigates to checkout, may fill some details - Sec-Fetch-Agent: ?1 - Agent requests user to review checkout - Buyer reviews and finalizes (taps "Pay") transaction — Sec-Fetch-User: ?1 - Buyer is navigated to order confirmation page ### Additional considerations - The header only indicates agent presence, not agent capabilities or identity - Headers only sent to potentially trustworthy URLs - Agent signal should be propagated to nested context - Agent-initiated iframe loads should inherit the agent flag - Subresources in agent-loaded iframe are also marked --- index.bs | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/index.bs b/index.bs index 96ef235..e057fa4 100644 --- a/index.bs +++ b/index.bs @@ -275,6 +275,40 @@ To set the `Sec-Fetch-User` header for a [= +The `Sec-Fetch-Agent` HTTP Request Header {#sec-fetch-agent-header} +------------------------------------------------------------------ + +The `Sec-Fetch-Agent` HTTP request header exposes whether or not a +request was initiated by an automated agent operating within the user's browsing context. It is a +[=Structured Field=] whose value is a [=structured field/boolean=]. [[!RFC9651]] Its ABNF is: + +
+Sec-Fetch-Agent = sf-boolean
+
+ +Note: The header is delivered only when its value is true. Unlike `Sec-Fetch-User`, this header +should be delivered for all request types when its value is `true`. The header indicates that +while the request originates from the user's authenticated browsing context, it is being triggered +by an automated agent. + +
+To set the `Sec-Fetch-Agent` header for a [=request=] |r|: + +
    + 1. Assert: |r|'s [=request/url=] is a [=potentially trustworthy URL=]. + + 2. If |r|'s [=request/agent-initiated=] is `false`, return. + + 3. Let |header| be a [=Structured Field=] whose value is a [=structured field/boolean=]. + + 4. Set |header|'s value to `true`. + + 5. [=header list/Set a structured field value=] + ``Sec-Fetch-Agent``/|header| in |r|'s [=request/header list=]. +
+
+ + Integration with Fetch and HTML {#fetch-integration} =========================================== @@ -297,6 +331,8 @@ To append the Fetch metadata headers for a request 4. Set the `Sec-Fetch-Site` header for |r|. 5. Set the `Sec-Fetch-User` header for |r|. + + 6. Set the `Sec-Fetch-Agent` header for |r|.