HTTP cookie
Enable an AI agent to recognise an HTTP cookie, assess its scope, lifecycle and exposure, and decide whether it may be accepted, sent, inspected, changed or removed.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
Researched by: Codex
Purpose and description
Enable an AI agent to recognise an HTTP cookie, assess its scope, lifecycle and exposure, and decide whether it may be accepted, sent, inspected, changed or removed.
It can be Inspect cookie metadata and compare values using an appropriately protected representation.; Evaluate whether a cookie should be accepted or sent in a specified browser and request context.; Set or replace a cookie through an authorised interface and verify the resulting stored state.; Delete the intended cookie using its effective scope and storage context, then verify removal.; Assess exposure and attribute changes against the application's intended behaviour.; Trace setting and transmission events to investigate unexpected persistence or dispatch..
Distinguishing features
It participates in the user agent's cookie mechanism: a cookie can be proposed through Set-Cookie or a supported client interface and selected for a Cookie request header.
Unlike local storage, its eligible contents can be attached to HTTP requests automatically by the user agent.
Unlike an arbitrary bearer token, its storage and dispatch are governed by cookie-specific scope and attribute rules; its value may nevertheless contain a bearer token.
A Set-Cookie response header proposes a cookie but does not prove that the user agent accepted or retained it.
A name-value pair observed in a Cookie request header does not expose the stored cookie's full attributes or uniquely identify its storage context.
Scope
+ Cookie name, value handling and identity within a cookie store
+ Creation through Set-Cookie or a supported client-side interface
+ Domain, path, transport, same-site and partition constraints
+ Expiration, replacement, eviction and deletion
+ Script accessibility, transmission exposure and browser enforcement
+ Evidence of purpose and authority to inspect or modify the cookie
- The authenticated session or account to which a cookie may refer
- The HTTP request, response or connection carrying cookie headers
- Local storage, session storage and other browser storage mechanisms
- The website's complete consent interface and policy
- Server-side token validation, authorisation and revocation systems
- The browser profile and its overall privacy configuration
Characteristics
- Observation form
- set-cookie proposal | stored cookie | request cookie pair | client-interface observation Determines which properties are directly observable and which require further evidence.
- Cookie name
- Exact observed name, including case and any prefix Supports identification and detection of naming conventions that may carry enforced restrictions.
- Value handling class
- unknown | non-sensitive | personal data | opaque identifier | potential credential Controls whether the value may be exposed, retained or compared without disclosing it.
- Storage context
- User agent, profile or container, and observed partition key where applicable Separates cookies that appear identical but belong to different stores or partitions.
- Host scope
- Observed domain and host-only flag, or unknown Determines which request hosts may receive the cookie.
- Path scope
- Observed effective cookie path, or unknown Constrains request selection without establishing an isolation boundary against hostile scripts.
- Access and dispatch attributes
- Observed Secure, HttpOnly, SameSite and Partitioned settings, preserving absent and unknown states Supports assessment of transport, script access, cross-site dispatch and partitioning constraints.
- Effective expiration
- UTC timestamp when established; otherwise session-scoped or unknown Supports time-based eligibility checks while keeping browser session behaviour distinct from fixed expiration.
- Storage lifecycle state
- proposed | rejected | stored | replaced | expired | evicted | deleted | unknown Prevents a proposed or previously observed cookie from being treated as currently available.
- Request eligibility
- eligible | ineligible | indeterminate, relative to a specified request context Cookie dispatch depends on the request and user agent policy, not solely on the cookie.
- Purpose evidence
- Links to application documentation, setter behaviour and observed consumers Distinguishes demonstrated function from guesses based on the cookie's name.
Also called
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 5 bundles · 10 layers · 10 findings · 23 questions.
Identity and observation Establish what was observed and which cookie instance that evidence identifies.
A header proposal, a stored cookie and a transmitted pair expose different evidence and must not be conflated.
Observation evidence
Locate the cookie observation within the HTTP or browser storage workflow.
Cookie observation form
Record whether evidence comes from a setter, the cookie store or an outgoing request, together with its time and context.
- Was this a Set-Cookie proposal, a stored cookie, a client-interface observation or a pair in a Cookie request header? definition
- Which response, script operation, storage inspection or outgoing request supplied the evidence, and when? provenance
Store identity
Resolve the cookie within a particular store without relying on its name alone.
Cookie instance resolution
Record the name, domain, path and relevant storage or partition context needed to distinguish candidates.
- Which name, domain, path, profile or container, and partition context identify the stored cookie? definition
- Could multiple stored cookies explain the observed request pair, and what evidence would distinguish them? boundary
Request scope and dispatch Explain when the user agent may attach the cookie to a request.
The practical reach of a cookie depends on host, path, transport and contextual browser rules.
Destination matching
Establish the effective destination scope rather than assuming it from the setter's URL.
Host, path and transport match
Record effective host-only or domain scope, path and Secure behaviour against a concrete destination.
- What effective domain, host-only status and path did the user agent store, including any defaults? measurement
- For the proposed request URL, which host, path or transport conditions allow or prevent selection? boundary
Contextual dispatch
Account for site relationships, partition context and user agent restrictions.
Same-site and partition eligibility
Assess SameSite and partition behaviour using the actual navigation or fetch context and browser policy.
- What top-level site, initiating context, request method and navigation or fetch mode govern this dispatch decision? boundary
- How do the effective SameSite setting, partition key, credentials mode and browser restrictions affect inclusion? measurement
- Was the cookie actually attached to the request, and what evidence explains any difference from predicted eligibility? provenance
Acceptance and lifecycle Track whether the cookie entered storage, remains there and can be removed.
Setting does not guarantee acceptance, expiration does not guarantee prior retention, and deletion must target the correct cookie.
Setting and replacement
Connect a setting attempt with its effective outcome.
Accepted cookie state
Distinguish the attributes requested by a setter from the state accepted by the user agent.
- Which response or client operation attempted to set the cookie, and what attributes did it supply? provenance
- Did the user agent reject, create or replace a cookie, and what stored-state evidence confirms the outcome? measurement
Retention and removal
Record effective lifetime and the evidence required to establish disappearance.
Effective lifetime and deletion
Assess Max-Age, Expires, session retention and observed removal without equating browser deletion with server-side revocation.
- What effective expiration follows from the accepted Max-Age or Expires settings, or is retention session-scoped? measurement
- Which authorised deletion operation targets this cookie's scope and storage context, and how will removal be verified? action
- If the cookie disappeared or returned, is there evidence of expiration, eviction, explicit clearing, session restoration or a new setting event? provenance
Exposure and integrity Assess who can read, transmit or influence the cookie and how its value must be handled.
Cookies may carry credentials or identifiers, while their attributes provide specific protections with limited scope.
Value exposure
Control access to the value according to its demonstrated or potential sensitivity.
Sensitive value handling
Record the value's evidence-supported role and permitted representation in agent observations.
- What evidence shows whether the value is a preference, identifier, personal datum or credential, and what remains unknown? provenance
- Can the task be completed using redaction, a protected comparison or metadata instead of exposing the raw value? action
Attribute protections
Evaluate effective protections and remaining avenues of access or interference.
Read and write boundaries
Assess HttpOnly, Secure, SameSite and any enforced name-prefix rules without treating them as complete session security.
- Which script-access, transport and setting restrictions are demonstrably enforced for this cookie in the target user agent? measurement
- Could another permitted setter replace the cookie or introduce a same-name cookie with a different scope? boundary
- Which attribute changes would reduce the identified exposure while preserving required application behaviour? action
Application role and action Connect the cookie's demonstrated function to permissible interventions and their consequences.
A technically possible cookie operation may disrupt application state or exceed the agent's authority.
Purpose and consumers
Establish which application behaviour depends on the cookie.
Demonstrated cookie role
Link the cookie to observed setters, consumers and functions while preserving uncertainty about opaque values.
- Which application component sets or consumes this cookie, and what evidence establishes its function? provenance
- Does the cookie hold application state directly or reference state owned by a session, account or other neighbouring model? boundary
Permitted interventions
Determine whether a proposed operation is authorised and whether its intended effect occurred.
Cookie operation authority and effect
Record task authority, relevant user choices and expected consequences of accepting, modifying or deleting the cookie.
- What task authority and applicable user choices permit the proposed inspection, setting, transmission or deletion? action
- What application effect is expected, and what observation will confirm it without assuming that cookie deletion revokes server-side state? action
What the second pass must settle
- Which browser families, versions and embedded clients must the model cover, and how do their defaults, prefix enforcement and third-party cookie policies differ?
- Which partition identifiers and storage-key details are observable through the intended inspection interfaces?
- How do the target user agents apply lifetime caps, eviction and session restoration, and which outcomes can be distinguished from available evidence?
- What application-specific evidence establishes this cookie's purpose, sensitivity and dependency on server-side state?
- Which applicable policies and recorded user choices constrain this cookie's use, and where is the authoritative evidence maintained?