Define the CSRF boundary for cookie-authenticated AI actions

Put browser admission before the approval transition

A fictional console lets a Cedar reviewer approve stored action A-17. The user has already signed in, and the browser can attach its session cookie to a request. Before changing approval state, the service needs a separate answer: does this request meet the console's browser admission rules?

This is different from deciding whether Cedar may approve A-17 or whether its contents still match the reviewed snapshot. Those checks remain necessary after admission. An AI-generated button label, model message or action identifier provides none of these assurances.

The following design is PROPOSED_UNRUN. No browser attack, application request, cookie/session operation, account change or action execution occurred. Origin labels and case IDs are inert fictional metadata, not instructions to contact a service.

Choose one narrow browser profile

Call the trusted origin O-A: https://console.example.test. The protected route accepts only POST approval requests with parsed media type application/json, permitting only a UTF-8 charset parameter if present. Reject other parameters, malformed JSON, form encodings and text/plain; never retry parsing them as JSON. GET, HEAD and OPTIONS do not change action state.

The application keeps a secret, unpredictable synchronizer token in the authenticated server session. Its authenticated same-origin review page supplies that token to the intended client, which returns it in a custom CSRF header. Validate it against the current session before the transition; absence or another session's value fails. Do not use the session cookie itself as this proof.

OWASP's CSRF guidance supports synchronizer-token validation and recommends maintained framework defenses before custom implementations. The profile here is an application design, not a new token algorithm. Session replacement must invalidate the old binding. Do not place the proof in URLs, logs or model context, and do not describe it as transaction approval or one-time execution authority.

Compare an origin rather than a familiar domain suffix

MDN defines Origin using scheme, hostname and port, and documents missing or null values in some contexts. For this route, require exactly one valid serialized origin matching trusted O-A after proper origin parsing. Reject malformed, multiple, missing and null values. A prefix or suffix string match is insufficient.

Keep O-A in trusted deployment configuration; do not derive the accepted origin from arbitrary Host or forwarded headers. This strict profile deliberately has no Referer fallback. A legitimate client lacking Origin must receive a compatibility failure rather than an automatic exemption.

MDN's cookie documentation describes SameSite as a site-level restriction, including scheme. A sibling such as https://notes.example.test can be same-site while being a different origin from O-A. Explicit Secure, HttpOnly and SameSite attributes support a reviewed session policy; they do not make a sibling origin trusted or establish the user's intent to approve A-17. This example creates no cookie.

Declare the metadata and compatibility branch

The W3C Fetch Metadata Working Draft dated 21 September 2026 distinguishes same-origin, same-site, cross-site and none contexts. It also documents a fetch destination of empty and request modes. These are context signals, not identities or object permissions.

The chosen console client deliberately uses same-origin fetch mode. This route requires recognized Sec-Fetch-Site: same-origin, Sec-Fetch-Mode: same-origin and Sec-Fetch-Dest: empty, alongside the origin and token checks. Navigation, none, same-site and cross-site contexts are outside this profile. Ignore unrecognized metadata as evidence, then treat that required signal as unknown.

Absent or unknown required metadata blocks this sensitive transition. That is a deliberate compatibility cost, not a claim all browsers emit these headers. Show a concise unsupported-client notice without weakening the gate. Any future fallback needs its own reviewed contract; do not silently classify missing metadata as same-origin.

Review eight inert admission cases

Each row assumes an authenticated session unless stated otherwise. Eligible means only that browser admission may continue to current action checks. No row is an observed result.

A future offline recorder could evaluate these labels and record whether the transition function was reached. It would establish only its own logic, not browser behavior or deployed middleware coverage. Authentication failure also stops processing; a CSRF token cannot resurrect an expired session.

Keep CORS and service clients in their proper scope

MDN's CORS guide explains that some form-like requests do not require preflight, while response sharing with scripts requires permission. Therefore a CORS error or unreadable response is not proof that no side effect occurred. Retain server admission checks, and do not broaden credentialed cross-origin access to make a failing client work.

Machine clients need a separately specified non-cookie authentication and authorization route. Do not grant an exemption merely because a caller says it is a service or supplies browser-looking headers: non-browser clients can construct them. This browser profile does not define that separate service credential system.

Same-origin script compromise or client-side request construction driven by untrusted input can defeat these assumptions; anti-CSRF is not an XSS defense. Boundary's prelaunch request-router plans do not provide a shipped browser approval service. Its eight mock policy checks are separate evidence and do not validate this contract.