How does an AI agent use a website? For years the answer was "through an API," and when there is none, "badly." This week, two launches took different routes around the problem. Gumloop released Agent Browsers, which let agents operate real browsers on sites with no API. AgentMail launched AgentID, an OpenID Connect provider that gives an agent its own verified sign-in identity.
They are complementary, and together they sketch two possible futures for how agents access the web: the agent pretends to be a person with a vault of logins, or the agent shows up as an agent with an identity. This post explains both, what is known, and the security questions to ask. We worked from vendor documentation and press coverage and have not tested either product.
TL;DR: the questions people are asking
| Question | Gumloop Agent Browsers | AgentID |
|---|---|---|
| What is it? | Real browser sessions for agents | Sign-in identity for agents (OIDC) |
| Solves | Sites with no API or MCP | Agents proving who they are to apps |
| Credentials | Password vault, agent never sees them | No shared secret; keypair per agent |
| Cost | Not stated in coverage | Free for apps; agents need an AgentMail inbox |
| Integration | Gumloop platform | Two OIDC values, no SDK |
| Key risk | Anti-bot defenses, vault security | Adoption, accountability |
Gumloop Agent Browsers: use the site like a person does
Gumloop builds a multiplayer agent platform where anyone at a company can build agents with a model and integrations of their choice while IT controls access. Agent Browsers extend that to sites that offer no MCP connection or API. Per the launch coverage, agents open a real browser and click, type, upload and pull data from any site a team already uses.
The notable piece is credential handling. Gumloop provides a password vault built for agents: logins are saved once, or connected through 1Password, and the agent signs in without ever seeing the credential. That matters because the standard failure of a browser agent is that it reads and exposes a password, whether through a prompt injection or a bad log. If the agent never holds the secret, that class of leak shrinks.
What this does not solve is the arms race. A site that detects automation can block or challenge the agent, as we have seen with consumer agents, including Amazon's block on Meta's Muse and the reports of web tasks suddenly failing that we discussed in our agent teams opinion piece. Terms of service also matter: a business that automates a vendor's portal should check that the vendor allows it.
AgentID: let agents be agents
AgentID takes the opposite approach. Instead of an agent impersonating a user in a browser, it gives the agent its own identity that apps can verify. AgentMail describes it as an OpenID Connect provider that lets an agent sign in to any app with its own verified email identity.
How it works, per AgentMail's documentation:
- Enrollment. Once per browser, the agent generates a keypair. The private key is non-extractable and is a P-256 key, so it cannot be copied out.
- Sign-in. On each login, the agent signs a fresh, server-generated transaction. The app verifies the signature against published public keys, so no shared secret travels.
- Token. The app receives an ES256-signed ID token containing a stable
subderived from the agent's inbox, the agent's verifiedemail, a uniquejtito prevent replay, and, for registered apps, anowner_emailidentifying the accountable human.
The owner_email field is the interesting design choice. It ties every agent to a person or organization responsible for it, which is the missing link in most agent deployments: when an agent does something wrong, who answers for it? Apps can add AgentID as a custom OIDC provider in Clerk, Supabase, Auth0, Better Auth or Auth.js with two configuration values, an issuer (https://auth.agentid.com) and a client ID, and no SDK. The button reads "Sign in with AgentID." It is free for applications, and agents need an AgentMail inbox. It launched publicly on October 6, 2026.
AgentMail distinguishes AgentID from enterprise tools such as Microsoft Entra Agent ID, which governs agents inside a company's own tenant. AgentID is for agents acting across organizations.
Why identity may beat impersonation
Consider what each model implies for a website.
| Model | What the site sees | Site's options |
|---|---|---|
| Browser impersonation | A browser that looks like a human | Detect and block, or tolerate silently |
| Agent identity | A signed, labeled agent with an accountable owner | Allow, rate limit, require approval, or deny, per agent |
Identity gives sites something they currently lack: a clean way to say yes. A site that cannot tell a helpful agent from a scraper blocks both. A site that can verify who owns an agent can grant it a narrow lane. That is the "agent lane" we predicted in our opinion piece, and AgentID is an early concrete attempt. The same instinct appears in the push for open standards for personal agents, as in our coverage of the personal agent protocol from Meta, Sierra and partners.
The catch is adoption. Identity only helps if sites support it, and most do not yet. Until they do, browsers fill the gap.
Security questions to ask before using either
For a browser-with-vault product:
- Where is the vault hosted, and who can read entries? How does it handle 1Password connections and revocation?
- Can I scope an agent to specific sites and actions, and log every action?
- What happens when an agent encounters a prompt injection on a page? Does the vault prevent it from exfiltrating anything it should not?
- Do the target sites allow automated access under their terms?
- Can the agent be paused instantly?
For an agent identity provider:
- How are agents verified before they get an inbox and keys? Can anyone create thousands of agent identities?
- What is the revocation path if a key is compromised?
- Does the owner field reflect a verified person or organization, or just an email address?
- What does an app do with an unregistered agent?
- How does the provider handle abuse, such as agents used for spam or fraud?
For agent security in general, a cheap screening layer helps, as in our write-up of Security-One, but least privilege and logging remain the foundation.
A decision guide
- Your target app has an API or MCP server: use it. It is sturdier than either option.
- No API, internal tool you control: a browser agent with a vault can work, and you can add the agent identity yourself later.
- No API, third-party site: read its terms, expect breakage and keep a human fallback.
- You build an app and want to welcome agents: consider adding an agent sign-in option and decide what narrow permissions an agent identity should receive.
- You run agents at scale: insist on per-agent identity, per-action logging and instant revocation, regardless of vendor.
A note on terms of service and ethics
Letting an agent operate a website as a person raises questions beyond security. Many sites prohibit automated access in their terms, and some regulated services require that an actual authorized person acts. Using a vault and a real browser does not change what the contract says. For internal tools you own, the question is easy. For vendor portals, check the terms or ask the vendor, since some will approve automation and even offer a sanctioned route. Where agents act on a person's behalf, such as submitting forms or placing orders, keep a record of what was done and by whom, so accountability does not disappear into the automation. An agent identity with an owner field is one way to keep that record clean, and a good habit is to review those records every month.
What this means for what you build or pay
If you build internal automations, Agent Browsers can unlock systems that no one will ever build an API for, at the cost of fragility. If you build apps, AgentID is a cheap experiment: two configuration values to see whether agent traffic shows up and whether you want to treat it differently from humans. The deeper trend is that the web is slowly learning to distinguish agents from people, and the products that make that distinction explicit and accountable are likely to age better than those that try to blend in.
Related reading
- Agent teams are the new org chart
- Amazon blocks Meta's Muse from shopping
- Personal agent protocol from Meta, Sierra and partners
- Meta opens Muse to developer connectors
- Security-One: screening agent tool calls
- Is ChatGPT Dots safe to leave unattended?
- Apple tightens Full Disk Access for AI agents
Primary: Gumloop's Agent Browsers announcement · AgentMail, "AgentID: Sign-In for AI Agents" and "What is an Agent ID?" (launched October 6, 2026)
Details are accurate as of October 7, 2026 and come from vendor documentation and press coverage. We have not tested either product, and pricing, limits and supported providers may change.