Company profile · 2 min read
Switchfrog: detecting agents in customers’ real browsers
Switchfrog describes detection and authorization controls for AI agents acting through customers’ browsers.
Cofounder of Lazyweb (a16z Speedrun). Previously grew subscriptions and built native ads at Duolingo. Writes First1000 (90,000+ subscribers).
Published · Updated
Switchfrog helps SaaS teams classify browser sessions and apply action-specific controls when customers bring agents to their product.
What it does
The homepage presents session counts and agent detection across Claude in Chrome, Codex and other browser agents. The docs describe sending a browser session token to a backend, receiving a human/agent/unknown verdict and applying a policy.
Buyer and task
SaaS teams that need to distinguish human, agent and unknown sessions and enforce action-specific policy.
Workflow boundaries
The displayed session counts are company page data, not independent adoption evidence. The checked public pages do not establish SDK behavior or verdict quality.
What I would ask
Ask what signals produce a verdict, how false positives affect users, and which actions require a stronger check than a session label.
Why it fits
Switchfrog starts from a new product-security problem: a logged-in browser session can be controlled by an AI agent and still look like ordinary customer usage. The homepage says it identifies whether sessions are human, agent or unknown, shows where those accounts go and lets a team react in real time. The docs turn that observation into an integration contract: send a browser-session token to the backend, receive a verdict and apply an action-specific authorization policy while keeping browser and server credentials separate.
That makes the decision more precise than “block bots.” A SaaS team might allow an agent to read documentation but require a stronger check before exporting data, changing billing or taking an irreversible action. The verdict is a signal for a policy decision; it is not itself proof of intent or authorization. The session totals and percentages shown on the homepage are company-page observations, not independent adoption or classifier-accuracy evidence.
A useful pilot would label a small set of known human and agent sessions, measure false positives by action and test what happens when the signal is unknown. The buyer should also understand how the token is minted, retained and revoked. The public pages do not establish SDK behavior or API results.
Quick facts
| Field | Sourced detail |
|---|---|
| Buyer | SaaS teams managing agent access to customer products |
| Signal | Human, agent or unknown session verdict |
| Integration | Browser SDK plus backend verification and action-specific policy |
| Evidence limit | No live classifier or adoption result established |
Sources checked
official Speedrun profile · company homepage · source page
Sources checked — September 20, 2026.
About the author
Cofounder of Lazyweb (a16z Speedrun). Previously grew subscriptions and built native ads at Duolingo. Writes First1000 (90,000+ subscribers).
I cofound Lazyweb and publish Mudpie. This is an owner-written publication, not an independent testing organization. Research notes distinguish observations, sourced reporting and editorial judgment.
First1000 ↗ · X ↗