The Login Handshake Nobody Designed: Handing an AI Agent Your Browser Session

Every credential this series has covered — API keys, OAuth tokens, mTLS certificates, decision tokens — exists because someone decided an agent needed to prove who it was before it acted. Computer-use and browser-automation agents increasingly skip that step entirely. The fastest way to point an agent at a web app that has no API, or an internal tool nobody wants to build OAuth for, is to hand it an already-authenticated browser profile: a live session cookie, a saved login, a screen the agent can drive because a human happened to be signed in on it. No handshake runs. No credential is issued. The agent simply inherits whatever the human’s session already proves.

The failure: a session is not a credential, it’s a loan with no terms

A session cookie was never designed to be handed to a second party. It’s the artifact of a login handshake a human completed — one where the browser, the device, and the person were all assumed to be the same principal for the life of the session. When that cookie (or the authenticated browser profile carrying it) gets handed to an agent instead, every one of those assumptions breaks, but nothing in the system notices, because a valid session looks identical whether a person or a model is driving it.

Compare what a session cookie actually grants against what even a mediocre API key grants:

• No audience binding. A session is typically valid for an entire application, not the one page or one action the agent was asked to perform.
• No scope. It carries the human’s full standing privilege — every permission, every role, every admin panel they happen to have access to — not the narrow slice the task needs.
• No expiry tied to the task. It lives as long as the human’s login does, which is hours or days, not the seconds an agent actually needs to complete one action.
• No independent identity. Every action the agent takes through that session is, to the target application, indistinguishable from the human clicking it themselves.

A leaked API key is bad. A leaked session is worse, because it was never scoped down from “everything this person can do” in the first place — the agent was simply given the master key and trusted to only turn it a little.

Why this counts as agentic AI gone wrong

The incident shape here is familiar from the rest of this series, but the forensics are worse. Picture a support agent given browser access to an internal admin console — logged in as a human operator — to look up a handful of account records. Somewhere in a long tool-use loop it clicks further than intended: a bulk action, a delete, a change to a billing plan, because the console offered the button and the session had the rights to press it. When someone reviews what happened, the access log says exactly one thing: the human operator’s account performed that action, at that timestamp, from that session. There is no agent identity in the record to investigate, because the agent never had one — it was wearing the human’s.

This is the same blind spot shadow AI describes at the deployment level, but at the level of a single action it’s sharper: it isn’t that governance didn’t know an agent was running, it’s that the audit trail structurally cannot tell the difference between the agent and the person whose session it borrowed. A login handshake that never happened can’t be logged, replayed, or scoped after the fact — there’s no negotiation to inspect, because negotiation was skipped in favor of impersonation.

Where the fix actually has to live

• Treat “no API exists” as a reason to build a narrower one, not a reason to hand over a session. A scraped-together internal endpoint behind a scoped, short-lived credential is a smaller blast radius than a full authenticated browser profile, even if it takes longer to wire up.
• Give the agent its own identity in every session it drives, even a browser one — a distinct login, a distinct account, or a token minted on the human’s behalf rather than as the human, so the access log can name the actor that actually clicked.
• Scope what the borrowed session can reach, if impersonation is genuinely unavoidable short-term: a read-only account, a sandboxed workspace, a console role stripped of the destructive actions the task doesn’t need — the same least-privilege discipline this series has argued for every other credential an agent holds.
• Expire the session on the task, not on the human’s workday. A cookie that outlives the five minutes an agent needed it for is a standing credential wearing a disguise.
• Log the agent’s actions as the agent’s, structurally, not as an annotation on a human’s session — an audit trail that can’t separate “the person logged in” from “the agent acting under that login” can’t answer the one question an incident review needs answered first: who actually did this.

The business case: never let the model hold the login

Fullmakt’s answer to “there’s no API for this” is not “then let the agent borrow a human session” — it’s to put the broker between the agent and whatever it needs to reach, so the agent authenticates as itself and never touches the underlying credential at all. Every call an agent makes through Fullmakt is dispensed a scoped, short-lived credential minted for that call, evaluated against policy at the moment of dispensing via a decision token the agent never sees the secret behind — not a copy of anyone’s standing login. The distinction that matters here is structural, not procedural:

• The agent’s identity is never the same record as a human’s. Every brokered action is attributable to the agent principal that requested it, so an audit trail never has to guess whether a logged action was a person or a process — that question is answered by construction, the same way this series has argued on-behalf-of delegation should work instead of silent impersonation.
• A credential minted for one call can’t outlive the call. There’s no equivalent of a session cookie sitting in an agent’s context for hours after the task that needed it is done, because the broker issues access per request, not per login.
• Revocation doesn’t mean logging a human out. Pulling an agent’s access through Fullmakt never touches the human account it might otherwise have been impersonating, because it never held that account’s session to begin with.

The commercial logic is the one this series keeps landing on: the moment an agent’s access is indistinguishable from a person’s, every governance control that assumes distinguishable actors — least privilege, audit, revocation, offboarding — silently stops applying. A credential broker that gives every agent its own scoped identity isn’t a convenience feature on top of authentication; it’s the thing that makes authentication mean anything once agents are the ones logging in.

FAQ

Isn’t giving an agent a browser session just a stopgap until a real integration exists? In practice it tends to become the permanent integration, because it works well enough that the pressure to replace it disappears — which is exactly why the access pattern needs a governance answer, not just an engineering-debt label.

Does this only apply to computer-use or browser-automation agents? The specific mechanism — a cookie — is unique to browser sessions, but the underlying failure (an agent inheriting a human’s standing credential instead of authenticating as itself) is the same pattern as pasting a personal API key into an agent’s environment, just with a wider blast radius because a session usually carries more privilege than any one key.

Can you scope a browser session the way you’d scope an API credential? Not natively — a session is bound to whatever the application’s login grants, not to a task. The closest you can get without changing the target application is a dedicated low-privilege account for the agent to log into on its own, which at least gives it a distinct, scopeable identity instead of a borrowed one.

What should an incident review be able to answer that a shared session can’t? Which actions were the agent’s, under what task, authorized by what policy decision, and revocable independently of the human whose session it might otherwise have used — four questions a structurally separate agent identity answers by default and a borrowed session can’t answer at all.

Does Fullmakt broker browser sessions? No — Fullmakt brokers scoped, short-lived credentials for API, GraphQL, gRPC, and MCP calls, issuing each agent its own identity and access rather than impersonating a human’s. The point of this post is the pattern to avoid; the fix is giving agents real, scoped credentials of their own instead of whatever session happens to be logged in already.

A login handshake exists to answer one question before anything sensitive happens: who is this, really? Handing an agent a human’s browser session skips that question rather than answering it cheaply — and every control downstream that depends on the answer inherits the gap.