The direct answer
For a supporting browser, a __Host- cookie plan requires HTTPS, Secure, Path=/ and no Domain attribute. Review those conditions together rather than trusting the name alone. Host scope does not validate a server-side session, isolate applications by path or authorize an AI action; those require their own evidence.
Choose a host boundary before choosing a cookie name
A fictional AI console runs on a dedicated application-owned HTTPS host H-A. Its server-side session backend is separately reviewed. An operator proposes a host-prefixed cookie name C-A, then a middleware change adds a parent Domain or narrows Path to the console area. The question is whether the resulting plan still has the intended browser-enforced scope.
This worksheet concerns one supported browser profile and one controlled host, not a new login or session algorithm. C-A is a symbolic name association; no cookie value, session identifier, header or browser state is created. Every receipt and eight cards are PROPOSED_UNRUN.
The session-transition guide still controls retained anonymous workflow state. The CSRF guide still controls browser action admission. Neither contract is replaced by a prefix.
Review the complete prefix prerequisite set
MDN’s Set-Cookie reference requires __Host- cookies to use Secure, originate from HTTPS, omit Domain and explicitly use Path=/. The less restrictive __Secure- prefix requires Secure and HTTPS without those additional scope restrictions. These assurances depend on browser prefix support.
For H-A/C-A, the application policy records all required conditions in one review entry. A proposal cannot keep the same friendly cookie name while silently changing its scope. If the effective response is unknown, hold the scope claim rather than infer it from framework settings or a deployment intention.
HttpOnly and SameSite are separate choices in this selected plan. Their intended values and actual behavior need independent review; __Host- is not shorthand for them. Retain the existing backend, request-admission and exact-action checks even after the scope entry is complete.
Distinguish host scope from a directory-shaped trust boundary
The same reference distinguishes host-only scope from Domain-expanded subdomain scope. Path controls sending, not protection against reading from another path.
Therefore moving an unrelated application into another directory on H-A is not evidence that the console’s session namespace is isolated from it. Our proposed host-control gate requires a complete account of the applications, publishers and relevant scripts served there. Unknown control blocks this assurance.
This is a host-scoped plan, not a universal claim about every property of an origin or every program on a machine. It supplies no shared-host isolation scheme. A team requiring a different trust boundary must review that design separately instead of treating a narrower Path as the missing control.
Keep intention, effective delivery and session acceptance separate
| Boundary | Independent evidence required |
|---|---|
| Host ownership | Intended console host and complete relevant application/publisher control. |
| Cookie scope plan | Exact C-A prefix, declared attribute set and supported client profile. |
| Effective response | Actual framework, middleware and delivery path preserve the admitted plan. |
| Backend session | Supported validation, lifecycle, duplicate-input handling and current user association. |
| Action admission | Current CSRF, object, workflow and exact-approval requirements. |
The useful positive makes the fixed host-scope plan conditionally eligible only when every actual prerequisite is independently established. It does not report that a cookie was accepted, a user authenticated or an action approved.
Actual browser support, effective headers, host control, server adapter, backend validation, duplicate-input handling and present permissions are unimplemented or unknown here. Missing evidence holds the positive. A configuration label or screenshot of a cookie name cannot fill the other receipt rows.
Define the unsupported-client and changed-plan response
MDN warns that browsers without prefix support accept prefixed cookies without those additional assurances. This application therefore does not claim enforced host-prefix scope for an unknown client profile.
A caller supplying a familiar name is not independent evidence that the declared browser path occurred. The receiving application must still validate the actual session through its trusted backend and apply the selected request contract. This worksheet invents no browser-attestation or cookie-provenance mechanism.
When a required condition is missing, report the affected compatibility or scope gate. Do not strip the prefix, broaden the domain, weaken the backend or transfer an old anonymous proposal into authenticated authority to restore convenience. Those would be changed plans requiring separate review.
Walk eight inert scope decisions
| Condition | Proposed disposition |
|---|---|
| 1. Complete supported H-A/C-A plan and every independent prerequisite hold | Conditionally admit only that scope plan. |
| 2. Domain is added to the selected host-prefix plan | Reject the changed prefix-acceptance plan. |
| 3. Path is narrowed from the required root | Reject this plan; do not promote the directory to an isolation control. |
| 4. The required transport/security conditions are absent | Reject the selected supporting-browser plan. |
| 5. Only the secure prefix is offered | Do not infer the additional host-prefix restrictions. |
| 6. Client support or the declared client path is unknown | Make no browser-enforced scope or provenance claim. |
| 7. Scope fits but backend, CSRF or current object rights fail | Withhold session or action admission independently. |
| 8. Another application on the host is outside the trust inventory | Hold the host-control assurance; a path label is insufficient. |
State the evidence and product limits
The maintained MDN body was modified on 1 September 2026. No browser, cookie jar, session backend, effective response or host configuration was inspected. No cookie, header, request, login, authentication, API, model or runtime fixture operation occurred. Ordinary editorial file handling is separate.
This worksheet establishes no resistance to every script compromise, protection of all retained credentials, session revocation outcome or universal browser compatibility. Boundary remains prelaunch with planned request-path checks, not a shipped session manager or cookie-scope verifier. Its existing synthetic policy evidence addresses different behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.