Token Security sells non-human identity and agent access control. On November 11, 2026 it published a contributed essay on The Hacker News describing Rehearsal—its own browser UI agent—as something that broke every rule Token preaches: distinct agent identity, task-scoped access, and audit trails separate from the human. Rehearsal answers questions on the Token platform by opening pages, setting filters, and typing into forms inside the user's authenticated browser tab. To the server, agent clicks look like user clicks because session cookies do not say who is driving. That gap is not theoretical for teams that pair SaaS browser automation with Claude Code or Codex on the same laptop. This post traces Token's mechanism, the mitigations that only work when you own both sides, and checks that still apply locally.
Token's October 2026 product post describes Rehearsal's UX goals; the November essay is the security post-mortem.
TL;DR
| Question | Answer |
|---|---|
| Am I affected? | Yes if anyone uses browser agents, agentic extensions, or autopilot walkthroughs inside SSO sessions that can change production data. |
| Is there a fix? | Partial. Token hardened its agent; the web still lacks a joined identity + delegation + scope signal. Use step-up auth, vendor audit clarity, and local agent logging meanwhile. |
| Is it exploited? | Token's piece is a deliberate design review, not an incident report. |
| Does data leave my machine? | Browser agents exfiltrate by action, not by a separate channel—every API call uses your session. |
| What do I do first? | Inventory session-borrowing agents and map them to owners; read Token's compromised-agent checklist. |
The agent Token would have flagged
Rehearsal (product introduction) accepts plain-language goals—"Which AI agents have no owner?"—plans a path through Token's UI, then executes that path in the user's tab. Token classifies it as a typical UI agent: useful because it reuses existing login state, risky for the same reason.
Three properties matter for authorization:
- Same session cookie — the backend authenticates the human's session, not an agent principal.
- Indistinguishable events — clicks and form posts lack an agent driver bit.
- Full user reach — whatever the human could do in that tab, the agent can attempt unless the application adds extra gates.
That is structurally similar to prompt injection through the browser described in when your browser becomes the attacker: same-origin policy and CSRF tokens do not block software acting as the user.
What closing the gap required inside Token
Token could fix Rehearsal only because it writes the agent and the app:
- UI lock and dimming while the agent drives, with visible who is in control.
- Session recording of every move, including blocked attempts (aligns with checklist items on denied-action rates in Token's rogue-agent guide).
- Read-only dashboards by default; no save without approval.
- No secret-field entry and no executing refused API calls.
- Accessibility labels as the agent's map of controls—still fragile for third-party CRMs.
The product blog states: "While any read operations are automated, Rehearsal doesn't save anything before asking. It never fills in a secret field, and never sends a blocked call."
Outside Token's tenant, a browser agent driving your CRM, cloud console, or internal admin has none of those hooks unless the vendor built them.
Standards lanes—and the missing join
Token's essay lists emerging pieces:
| Lane | What it knows | What it does not pass on |
|---|---|---|
| Browser (Chrome auto-browse, Microsoft agentic browsing) | Agent is driving; can pause before passwords/payments | How to tell the origin app with standard headers |
| WebMCP (W3C community draft) | Typed tools marked read-only vs consequential | Narrower scope than the user's session by itself |
| Web Bot Auth (IETF draft) | Which agent binary signed a request | Delegation—who authorized the agent for this task |
Token argues applications need three signals together: agent identity, a verifiable link to the delegating human, and scope below the human's grants. Without that join, faster agent lanes are faster privilege misuse.
That parallels organizational agents becoming authorization bypass paths: logs attribute actions to agent service principals, while browser UI agents still attribute to the human session—two blind spots.
What this means if you run AI coding agents
Most readers here run terminal agents, not Rehearsal—but the identity problem overlaps:
-
Same laptop, two drivers. Developers use Chrome agentic browsing or Copilot in the browser for ops tasks and Claude Code for repos. Compromise or misuse in either channel can touch the same cloud accounts linked in MCP configs—see humans missing agent command threats for how often people approve risky steps.
-
Inventory session-borrowing software. Token recommends discovering browser agents, extensions, and endpoint agents that act through authenticated sessions. Map owners the way you map MCP servers after GitBook-style credential incidents.
-
Step-up before irreversible actions. Until vendors expose agent-aware audit, require passkey or MFA step-up for deletes, privilege grants, and production deploy buttons—even when a "helpful" agent clicked there.
-
Ask vendors the audit question. Token's checklist: do logs show agent vs human, and can they store task-scoped delegation? If not, local observability on the CLI side (Beam, hooks, CI) is your backstop.
-
Do not conflate MCP tool calls with browser driving. MCP can expose typed, labeled tools—closer to WebMCP's model—while screen-scraping agents remain session-identical to the user. Prefer tool APIs over UI autopilot for high-value systems.
-
Always-on assistants. For Muse, Dots, and similar connectors, see keeping personal agents safe; browser session inheritance is the same class of bug at a different integration point.
What security teams can do this week (Token's list, expanded)
Token's essay closes with pre-standard controls. Below is the same list with coding-agent-specific interpretation.
Inventory session-borrowing agents. Include browser walkthrough products, Copilot in Edge, Chrome auto-browse experiments, and MCP bridges that drive a logged-in browser. Map each to a human owner and to which SSO roles the borrowed session carries.
Trace consumers. Token sells consumer-to-agent graphs for enterprises. Smaller teams can approximate with IdP sign-in logs plus local Beam exports: correlate spikes in Git pushes or cloud CLI use with browser agent enablement dates.
Review entitlements. An agent that can open every SaaS tab effectively holds the union of entitlements across tabs—not the intersection of what one task needs. Narrow browser profiles or separate browser instances for agents where vendors allow it.
Map attack paths. Red-team "ask the browser agent to export users" on staging. If audit logs attribute the export to the human, your SOC lacks agent attribution—exactly Token's gap.
Step-up authentication. Require passkey or hardware key for delete, share, billing, and role grant buttons when agentic browsing flags are on in Chrome or Edge.
Vendor questionnaires. Ask: Do audit records include an agent identifier? Can we scope OAuth tokens to a single agent task? Until yes, treat SaaS actions during agent sessions as high-risk approved manual work.
Token's intent-based agent security launch targets cloud and IdP-scale enforcement. Developer laptops still need local evidence when agents shell out.
How Beam handles this
Token focuses on cloud identity graphs, intent, and enterprise agent inventory. Beam overlaps on developer machines, not on SSO admin consoles. Beam is local-first observability for coding agents (Claude Code, Codex): it ingests tool and command events, scans skills and MCP configs with 11 heuristics, redacts known secret formats before storage, and can deny some PreToolUse actions under enforce policy on supported harnesses. That helps when a browser agent's last step is "clone repo and run setup script" in a terminal the collector watches, or when curl with your cookie jar lands in bash history.
Beam does not instrument in-browser DOM automation on arbitrary SaaS sites, verify Web Bot Auth signatures, or replace Token's NHI lifecycle features. Where teams run both a Token-style inventory and Beam on laptops, use Token for who may act in the cloud and Beam for what the coding agent actually executed locally after a browser session handed off work. Limits: hook-based deny (not a kernel sandbox), heuristic scanning, fail-open on missing cached policy, and no Cursor/Codex deny parity on every harness. Details live on how Beam works.
Rehearsal vs coding agents: shared failure mode
Rehearsal is UI navigation; Claude Code is tool APIs. Both inherit ambient authority:
- Rehearsal inherits browser cookies.
- Coding agents inherit API keys, SSH agents, and kubeconfigs on disk.
Token's lesson that the server cannot see the driver maps to agents when hooks are off or policies are advisory: the platform sees your user, not which prompt chain or which sub-agent acted. That is why F-Secure's harms taxonomy separates unintended harm from compromise—session ambiguity blurs both.
Until WebMCP, Web Bot Auth, and OAuth agent delegation (draft work tracked by PermDock) converge, assume any automated driver inside SSO is delegated admin access that must be logged, narrowed, and step-up gated.
None of that removes the need to watch local terminals where those sessions land.
Frequently asked questions
Answers in the front matter expand on Rehearsal behavior, Token mitigations, and interim controls.
Related reading
- Humans miss one in three agent command threats
- GitBook AI-agent attack: rotate tokens and MCP
- Keep Muse, Dots, Claude Duet, and Grok Bot safe
- F-Secure AI harms taxonomy for coding agents
- November 2026 attacks timeline
Primary sources: Token via The Hacker News (November 11, 2026), Token Rehearsal introduction (October 26, 2026), Token compromised-agent checklist.
Standards names and product behaviors reflect Token's essay and Token's October 2026 Rehearsal post as of November 11, 2026.