· Paul Crossland
One Browser Session, Two Principals: Audit the Agent Handoff
Human-to-agent handoffs can preserve browser state without preserving authority. Segment the journey before trusting extracted data.
A browser session can remain technically continuous while the actor, authority, and meaning of its evidence change underneath it. A person browses a shop, opens an account portal, or configures a search. Then an agent takes over to compare options, collect results, or complete an approved task. The same cookies, storage, tabs, and network connections may survive the handoff. The fetch contract should not.
Fresh Cloudflare work describes both sides of this boundary. On August 7, Cloudflare reported that its session-level bot signals observe behavior shifting from human to agentic and back within a journey, and argued that risk and trust should be evaluated continuously rather than through one point-in-time check (Unveiling good and bad behaviors on the Agentic Internet). On August 5, Cloudflare's Agent Access Model proposed treating each task-scoped run as a distinct execution graph: credentials should be short-lived and bound, every action should be authorized against the task and accumulated state, and authority removed during a run should not silently return.
The practical thesis is: a human-to-agent handoff must create a new provenance and authorization segment even when it reuses an approved browser context, because session continuity preserves state but does not prove that the new principal may use every capability or that post-handoff data is comparable with pre-handoff evidence.
This is not guidance for imitating human behavior, carrying trust past a site's controls, or reusing credentials without permission. A challenge, login requirement, denial, payment boundary, or publisher policy remains a stop or review condition. The purpose of a handoff boundary is to reduce accidental authority and make permitted agent retrieval auditable.
The repeated angle to avoid
Recent Better Fetch posts already cover session evidence, auth-state boundaries, agent control points, comment-triggered runs, identity resolution, browser fidelity, and continuous bot-policy signals. The repeated article would say that sessions are stateful or that agent actions need logs.
The new surplus is the boundary between principals. Site-side systems can evaluate one continuous behavioral journey while operator-side systems should deliberately split that journey into human and agent segments. If a data pipeline uses the browser session as both transport state and proof of authority, it cannot explain which principal caused a response, which state was legitimately inherited, or whether a policy transition occurred after control changed hands.
Source map
Fresh primary evidence from the last seven days:
| Source | Date | Contribution |
|---|---|---|
| Unveiling good and bad behaviors on the Agentic Internet | 2026-08-07 | Reports session-level observations in which behavior changes from human to agentic and back, and frames trust as continuous rather than a one-time pass. |
| The Agent Access Model | 2026-08-05 | Defines task-scoped runs, short-lived bound credentials, per-action authorization, mediation outside the prompt, evidence logs, and one-way capability reduction. |
| Everything we launched during Agents Week | 2026-08-10 | Confirms the broader operating model: agent execution, observability, human approvals, secure access, and web interaction are being assembled as one production stack. |
Older background context includes browser cookie partitioning, consent state, session replay, WebAuthn, and MCP control surfaces. Those topics explain why state is contextual. The fresh synthesis is that a handoff can retain all that context while changing the principal allowed to act on it.
Session continuity and authority continuity are different
A browser context may contain useful, legitimate state:
- locale, timezone, region, viewport, and accessibility preferences;
- consent choices and first-party storage;
- an approved authenticated session;
- open tabs, history, caches, and service-worker state;
- application selections made by the person before delegation.
Keeping some of that state may be necessary for the assigned task. But the fact that state exists does not grant the agent every action the person could take. Nor does a successful page load prove that the site interpreted the post-handoff activity in the same way as the pre-handoff activity.
Two independent policy systems are in play. The operator decides which tools, domains, actions, accounts, and data the agent may use. The site evaluates the journey under its own policies. Preserve both outcomes. Neither a valid cookie nor a 200 proves that the agent was authorized or that the evidence is publishable.
A point-in-time login or challenge verdict describes one moment; later behavior may produce another outcome. Record that transition rather than smoothing it away.
Put a handoff marker in the evidence timeline
Treat each change of principal as a new segment within the same browser journey. The browser context identifier may stay constant, but the evidence record should not.
| Segment field | What it proves |
|---|---|
journey_id | Links the complete browser journey without pretending it had one actor. |
segment_id and parent_segment_id | Separates human, agent, tool, and resumed-human phases. |
principal_class | Records human, task agent, delegated tool, service, or unknown. |
handoff_reason | States the approved task rather than inferring purpose from later requests. |
capability_ceiling_hash | Identifies the immutable domain, action, account, and data limits applied at dispatch. |
browser_state_inherited | Names state classes inherited, reset, redacted, or unavailable without storing secrets. |
authorization_decision | Records the operator-side allow, deny, narrow, or approval-required result per action. |
site_policy_outcome | Separately records content, challenge, login, payment, rate limit, denial, or unknown. |
evidence_provenance | Ties each extracted field to the segment and representation that supplied it. |
At handoff time, snapshot metadata rather than secret values: cookie-name and domain-scope hashes, storage-generation identifiers, active origin, auth class, consent class, open-tab origin classes, service-worker registrations, and a bounded digest of relevant application state. Then mint a task-scoped run identity and intersect its requested actions with the human's authority, the customer contract, and source policy.
The resulting capability set should be a ceiling, not a starting suggestion. If the agent reaches a protected event such as an unexpected origin, sensitive data class, write operation, auth transition, or policy response, narrow or stop the run. Do not let a model prompt widen it, and do not restore removed capabilities merely because control later returns to the same browser.
Failure modes hidden by one session ID
A single session label collapses several materially different incidents:
- Authority laundering. The agent inherits an authenticated context and performs an action outside the delegated task because the cookie is treated as permission.
- Evidence mixing. Fields observed by the human, the agent, and a delegated tool are merged into one record without segment provenance.
- Policy lag. A request immediately after handoff succeeds, but a later step receives a challenge or reduced representation. The extractor publishes partial data because the journey's first verdict was cached.
- State contamination. Agent navigation changes locale, consent, cart, filters, or storage, so the resumed human and later crawls inherit an altered source view.
- Retry escalation. A post-handoff denial is classified as transport failure, causing new regions, sessions, or clients to be tried instead of stopping at the policy boundary.
- Unbounded delegation. A tool called by the agent receives the browser's authority but loses the original human, task, and capability context across the hop.
These are not solved by deleting every cookie. Fresh contexts improve isolation but can destroy the legitimate state required for an approved task. The trade-off is deliberate inheritance: retain only the state classes the task needs, keep authorization independent from that state, and record every mutation that could change later evidence.
A handoff test plan
Build the test on owned fixtures or partner-approved environments.
- Start a human segment that chooses locale, consent, filters, and an approved test account state.
- Hand control to a task agent with read-only access to one origin and one data class. Assert that the journey ID persists while the segment, principal, credential, and capability ceiling change.
- Attempt an undeclared write and an off-scope origin. Confirm that enforcement blocks them outside the prompt and records the decision before any request is sent.
- Change a permitted filter. Verify that the mutation is attributed to the agent segment and that dependent extracted fields point to post-handoff evidence.
- Return a challenge, login shell,
402,403, or429from the fixture after several allowed actions. Assert that the run stops or requests approval rather than changing identity or execution route. - Delegate one read to a child tool. Confirm that the original principal, task, capability ceiling, and current narrowed state remain attributable across the hop.
- Return control to the human. Show which state changed, require review for sensitive mutations, and create another segment rather than reviving the old human verdict.
- Replay the run from its structured envelope. The result should not depend on an agent transcript or on an unlabelled browser profile left on disk.
The operator decision rule
When control changes, ask three questions before the next fetch: which principal is acting, which exact capability was delegated, and which browser state is necessary for that capability? If any answer is unknown, pause the handoff. If inherited state exceeds the task, reset or redact it. If a later policy outcome narrows access, preserve that outcome and stop; do not rely on earlier trust in the journey.
For extracted data, compare records only when their policy-relevant segments match. A value observed before handoff, after handoff, and after control returns may share a URL and browser context while having different principals, authorization decisions, state generations, and representation classes. Provenance should make those differences visible.
Human-agent browsing will often work best as a continuous user experience. Production fetch evidence should be more precise. Keep the journey connected, split it at every principal transition, authorize actions against the task rather than the cookie jar, and let authority move only in the safe direction until a new run is explicitly approved.