Logging AI agents into web apps: From cookie hacks to proper OAuth

AI agents can browse the web, call APIs, manage calendars, and file support tickets. But ask one to log into your app, and it hits a wall.

Authentication is the single biggest bottleneck preventing agents from being useful. Not model capability, not tool availability, but login screens. And the way most teams are solving this today is a mess.

The hack era of agent authentication

There are four common approaches teams use to get agents past login screens. They get the job done, but are also introducing some real problems.

Cookie syncing

When you log into a website, the server responds with Set-Cookie headers. Your browser stores those cookies in its user data directory, a folder on disk that holds everything about your browsing session: cookies, localStorage, IndexedDB, cached credentials, and more. On subsequent requests, the browser matches cookies by domain and sends them back automatically. That's how the server knows you're still you.

Cookie syncing copies this data from your real browser into the agent's browser. Most browser automation platforms support some version of this. Some let you export a storage_state JSON file containing cookies and localStorage. Others let you point the agent at your actual Chrome profile directory, or sync your local profile to a cloud-hosted browser.

The result is that the agent's browser is now carrying the same session tokens your browser has. Every server it connects to treats it as an authenticated session, with full access to everything your account can reach.

This is the fastest way to get an agent authenticated, and for personal automation it's often good enough. But the access is completely unscoped. There's no way to limit what the agent can do within that session, no audit trail distinguishing the agent's actions from yours, and no way for an IT team to even know an agent is operating. From the server's perspective, it's just you clicking around.

Sessions also expire unpredictably. Some cookies last hours, others last weeks, and the agent has no way to re-authenticate when they expire without going through the full login flow again.

Credential injection via password managers

Rather than copying an existing session, some platforms integrate directly with password managers like 1Password. The agent encounters a login form, queries the vault for matching credentials by domain, and fills them in programmatically. The agent never sees the actual password; values are injected directly into the page's DOM.

This is more robust than cookie syncing because it lets the agent establish new sessions rather than relying on an existing one that might expire. Some implementations go further: the vault item can be matched automatically by URL, credentials can be filled without the agent's vision model ever seeing them, and form fields can be blurred immediately after input to prevent screen-based extraction.

The security model here depends on how tightly the password manager integration is controlled. With a service account, the agent gets access to whatever's in the vault. Some platforms add a human-in-the-loop step where you approve each credential fill via Touch ID or a master password. But once the credentials are filled and the session is established, the agent has the same unrestricted access as the cookie syncing approach.

TOTP and two-factor authentication

Many apps require a second factor after the password, most commonly a six-digit TOTP code. These codes are generated from a shared secret key and the current time, refreshing every 30 seconds. If you have the secret key, you can generate valid codes programmatically without an authenticator app.

Agent platforms handle this in a few ways. Some accept the TOTP secret as a configuration parameter and generate codes at input time. Others pull the secret from a password manager's TOTP field. A few provide code templates where you implement the generation logic yourself.

This means agents can now clear 2FA gates autonomously. The implication is that two-factor authentication, a control designed to verify that a human is present, no longer guarantees that.

Email and SMS verification

Some sites send verification codes via email or SMS instead of using TOTP. Agents handle this by creating dedicated inboxes they control, then polling for incoming messages. Services like AgentMail provide an API for this: create an inbox, use that address when signing up or verifying, and the agent extracts the code from the incoming message.

This is the most niche of the four approaches, but it's becoming more relevant as agents handle account creation and onboarding flows.

Where these approaches break down

For individuals automating their own accounts, these techniques are practical and often sufficient. The person accepting the risk is the same person getting the benefit.

They don't translate to B2B software. If you're building a SaaS product and your customers' agents start showing up with cloned cookies and auto-generated 2FA codes, you have no visibility into what's happening. You can't distinguish agent traffic from human traffic. You can't scope an agent's permissions to a subset of the user's access. You can't revoke agent access independently. And your audit logs are meaningless because every action looks like it came from the user.

The problem isn't that agents can't log in. It's that they shouldn't log in like humans.

Agents aren't humans. They shouldn't authenticate like humans.

When a human logs in, they're establishing an interactive session, one where they make decisions in real time, understand the consequences of their actions, and can be held accountable for what they do. Session cookies and passwords were designed for this kind of relationship between a user and an application.

Agents are different. They act autonomously, often across multiple systems, sometimes chaining actions together in ways no human would. They don't read consent dialogs. They don't notice when something looks off. Giving them a human's full session is like handing someone your house keys when they only need to water the plants.

What agents actually need is a proper identity of their own, one that comes with scoped permissions, time-limited access, and a clear audit trail. In other words, they need OAuth.

OAuth 2.1: the agent auth standard hiding in plain sight

The infrastructure for agent authentication already exists. OAuth 2.1 was designed for exactly this kind of delegated, scoped access. A user authorizes an application (or agent) to act on their behalf, but only within defined boundaries, only for a limited time, and with the ability to revoke access at any point.

The Model Context Protocol (MCP) recognized this and adopted OAuth 2.1 as its authorization framework. When an MCP client connects to your server, it goes through a standard OAuth flow: the user authenticates, approves a set of scopes, and the agent receives a token. That token represents a specific grant of access, not a cloned session.

This is a fundamentally better model for agent access because it gives you everything the hack approaches don't:

• ‍Scoped permissions. Instead of giving the agent everything, you define exactly what it can do. Read calendar events but not send emails. Query a database but not delete records. The agent gets a token that encodes these boundaries.‍
• Time-limited access. Tokens expire. When a task is done, or when a time window closes, the agent's access ends automatically. No persistent cookies sitting in a browser profile somewhere, waiting to be reused.‍
• Auditability. Every action the agent takes is tied to a distinct token and a distinct grant. You can tell the difference between what a human did and what their agent did. Your audit logs actually mean something.‍
• Revocability. If an agent misbehaves, or if a user simply changes their mind, access can be revoked instantly. No need to rotate passwords or clear cookie stores.‍
• IT visibility. Enterprise admins can see which agents have been authorized, what permissions they hold, and when those permissions expire. This is table stakes for any organization that takes security seriously.

How to add agent auth to your app with WorkOS

If you're building a web app and you want agents to access it securely, you don't need to invent a new auth system. You need to expose your existing one via the right protocol.

WorkOS AuthKit supports OAuth 2.1 as a spec-compatible authorization server for MCP applications. This means any MCP client, whether it's Claude, a custom agent framework, or an IDE plugin, can authenticate against your app using standard OAuth flows, with PKCE, scopes, and token management handled for you.

When an agent connects, the user sees a familiar authorization screen: they approve specific scopes, the agent gets a token, and it can start making requests. If the agent requests something outside its scopes, it gets a permission error.

For apps that already have their own login system, WorkOS Connect can run as standalone middleware that adds MCP OAuth flows without requiring you to migrate your existing auth. You keep your user database and sign-in experience; Connect handles the agent authorization layer on top.

Going further: Session-scoped access for third-party integrations

Agent auth gets more complex when agents need to reach beyond your app and into third-party systems on behalf of a user. Think of an agent that needs to query a customer's Snowflake warehouse, pull documents from their Google Drive, and update a record in Salesforce, all as part of a single task.

The traditional approach here is long-lived OAuth tokens. A user connects their Salesforce account, your app gets a refresh token, and it can act on their behalf indefinitely. This works fine when your application is the one making requests. But when an agent is making requests, autonomously, unpredictably, across multiple services, indefinite access is a liability.

Pipes MCP addresses this with session-scoped authorization. It sits on top of existing OAuth connections (managed through WorkOS Pipes) and adds a time-bound access layer specifically designed for agents:

1. The agent requests access to a set of third-party tools.
2. A human approves the session.
3. The agent can use those tools for the duration of the session.
4. When the session expires, access is automatically revoked.
5. The agent cannot renew the session on its own.

Each connected provider, Snowflake, Google Workspace, Salesforce, and others, appears as a discoverable tool via MCP. The agent can select and invoke them as part of its planning, but tool availability is session-bound. The MCP server enforces access checks on every invocation.

This is a meaningful step beyond both cookie-syncing (where access is unlimited and invisible) and traditional OAuth (where tokens live forever until explicitly revoked). Session-scoped authorization gives agents exactly enough access for a task, and nothing more.

What this means for developers building SaaS

If you're building a B2B application, agent traffic is coming whether you plan for it or not. Your customers' agents will attempt to interact with your product, and the question is whether they'll do it through legitimate, authorized channels or through hacked-together cookie sessions that bypass your security model entirely.

By adding MCP auth support to your app, you're doing a few things simultaneously:

• You're making your product agent-accessible in a way that's sanctioned and controlled, rather than ad-hoc and invisible.
• You're preserving your security model. Agents go through the same authorization framework as any other OAuth client. Your RBAC policies, your audit logs, your compliance controls all still apply.
• You're giving enterprise customers what they need. IT teams want to know which agents are accessing which apps, with what permissions, and for how long. OAuth-based agent auth gives them that visibility natively.
• And you're future-proofing your integration surface. MCP is becoming the standard protocol for agent-to-application communication. Supporting it now means you're ready for whatever agent frameworks and platforms emerge next.

The cookie-syncing era is ending

We're at an inflection point. The first generation of agent auth was built on workarounds, clever hacks that got agents through the front door by pretending to be humans. That was fine for demos and personal scripts. It's not fine for production software serving enterprise customers.

The next generation is standards-based. Agents authenticate with OAuth. They receive scoped, time-limited tokens. Their actions are auditable. Their access is revocable. And the infrastructure to support all of this already exists.

Your app has an auth system. It's time to let agents use it properly.