How to build a browser agent that works behind a login

Browser agents stall the moment a task moves behind a login. Reasoning and tool calls can drive a public page, but a dashboard, an account, or a signed-in feed needs a real user session.

This guide combines eve, Vercel Connect, and KERNEL so your agent can sign a user in through a human-in-the-loop handoff and keep that session fresh. The agent then drives the signed-in browser to finish the work as that user. No shared API key touches the app, and the model never handles raw credentials.

Copy link to headingQuick start with an AI coding agent

If you're working with an AI coding agent like Claude Code or Cursor, use this prompt to have it build the agent for you:

Copy link to headingVercel Plugin

The Vercel Plugin turns your AI coding agent (e.g., OpenAI Codex, Claude Code, or Cursor) into a Vercel expert. It adds skills, slash commands, and current knowledge of the tools you’ll use, including Vercel Connect and AI Gateway. The plugin is optional; it isn't required to use eve or to follow this guide.

npx plugins add vercel/vercel-plugin

Copy link to headingOverview

In this guide, you'll learn how to:

• Scaffold an eve agent and add KERNEL's browser toolset
• Broker per-user browser access through Vercel Connect, so no KERNEL_API_KEY touches your app, environment, or the model
• Sign a user into a target site through KERNEL managed auth with durable human-in-the-loop approval
• Save that session to a reusable profile that re-authenticates on its own
• Run tasks in the signed-in browser and watch through a live URL
• Run the agent locally as a TUI, then deploy it as a Slack bot

Copy link to headingPrerequisites

Before you begin, make sure you have:

• Node.js 24 or newer
• A Vercel account.
• A KERNEL account.

For local development, you also need Node.js 24+, pnpm, and the Vercel CLI.

Copy link to headingHow it works

KERNEL and Vercel pair on two independent axes. The model routes through the Vercel AI Gateway, which a linked project authenticates via an OIDC token. Internet access via a KERNEL browser is routed through Vercel Connect, which issues a per-user token to the KERNEL MCP server. The two are decoupled on purpose, so you can swap the model, the gateway, or the auth broker without touching the others.

At runtime, the agent runs this loop:

1. Add and consent. eve adds KERNEL's toolset through a Connect connector uid rather than a key. The first time a user drives the browser, eve surfaces a one-time Connect consent prompt. The user approves once, and the grant is cached across threads and sessions.
2. Sign in through a hosted login. When a task needs authentication, eve starts KERNEL's hosted login flow and posts the user a URL. It pauses on ask_question until the user signs in and clears MFA or SSO. Credentials go to the site, never to the agent or into a page the model is driving.
3. Save the session to a profile. KERNEL saves the authenticated session to a named, durable profile and creates a managed auth connection that reauthenticates automatically.
4. Drive the signed-in browser. eve opens a browser already signed in on that profile and works the task end to end. It reads the page, takes the single next action, re-reads, and repeats.
5. Report back. eve returns the outcome plus a live-view URL, so the user can inspect the session or take over.

The human-in-the-loop moment is step 2. The person signs in through KERNEL's hosted flow rather than pasting credentials into the chat, and ask_question pauses the turn until they answer, with no polling or guessing.

Access is granted twice, and both grants are explicit and scoped:

Neither grant is a shared key, and neither hands the agent raw credentials. Both persist, so the agent keeps working without asking again. That combination makes it safe to point an agent at a site behind a login on a real user's behalf.

This guide builds on the eve-connect-kernel cookbook, which contains the agent, its TUI and Slack channels, and the connector scripts used below. You'll clone it, wire it to your Vercel and KERNEL accounts, then run it.

Copy link to headingSteps

Copy link to heading1. Clone the cookbook and install dependencies

git clone https://github.com/kernel/eve-connect-kernel
cd eve-connect-kernel
npm install

Everything the agent does lives in the agent/ directory:

agent/
  agent.ts               # model (routed through the Vercel AI Gateway)
  instructions.md        # how to act on the open web with KERNEL
  skills/kernel-auth.md  # the managed auth hosted login flow, step by step
  extensions/kernel.ts   # mounts @onkernel/eve-extension via Connect
  channels/eve.ts        # local TUI channel, locked to loopback
  channels/slack.ts      # Slack channel with the sign-in handoff button

Copy link to heading2. Link the project to Vercel

Linking connects this directory to a Vercel project. The connectors you create in the next steps attach to that project, and linking also authenticates the default model route for you via AI Gateway, so there's no model key to set:

vercel link

Copy link to heading3. Create the KERNEL connector

This provisions the kernel/kernel-mcp connector that the extension mount points at. kernel is KERNEL's entry in Vercel's connector registry, so Vercel fills in the MCP URL and branding. Run it once:

npm run connect:kernel

Copy link to heading4. Review how the browser toolset is mounted

The cookbook already mounts KERNEL's toolset in agent/extensions/kernel.ts, and it takes one line. The connect option carries a connector uid instead of a key, so the browser connection authenticates through Connect and no KERNEL_API_KEY lives anywhere:

import kernel from "@onkernel/eve-extension";

export default kernel({ connect: "kernel/kernel-mcp" });

Once added, the browser tools surface as kernel__browser__<tool>. eve discovers them at runtime, so the agent ships no browser code of its own.

The toolset gives you two execution styles within a single session:

KERNEL's toolset also manages the session itself:

• manage_browsers: session lifecycle and the live-view URL
• manage_profiles and manage_auth_connections: login state
• manage_proxies: proxy configuration
• manage_replays: session replays

You can enable more KERNEL features, including pre-configured browser pools, browser curl, and in-VM process execution.

Copy link to heading5. Run the agent locally

npm run dev

This opens the interactive TUI. The local channel it runs on only accepts connections from your own machine, so nothing is exposed to the network during development.

The first browser action triggers the one-time Vercel Connect consent prompt in the terminal. Approve it once, and you won't see it again.

Copy link to heading6. Deploy as a Slack bot

In production, the agent streams progress into a Slack thread and renders the sign-in handoff as a native button. Slack needs a public URL, so this path is deploy-only.

npm run connect:slack
npm run deploy

connect:slack creates the slack/eve-connect-kernel connector already wired into agent/channels/slack.ts, then points its webhook at eve's /eve/v1/slack route. Connect provisions the Slack app, bot token, scopes, and webhook verification, so no Slack secret touches your environment.

Invite the bot with /invite @your-app and send it a message. It streams progress, drops the sign-in button when it needs you, and finishes the task on its own with a live-view link so you can watch or take over.

Copy link to headingTwo workflows to try

Copy link to headingSet up managed auth

log me into github.com

eve opens KERNEL's hosted login flow, hands you the link, and waits while you sign in and clear MFA. It then saves the session to a reusable profile that reauthenticates automatically. Under the hood, eve:

1. Checks for an existing authenticated connection for the domain, and reuses it.
2. Picks a profile, creates a managed auth connection for the profile and domain, and starts a hosted login, which returns a hosted_url and a live_view_url.
3. Hands you the hosted_url, then pauses until you reply that you've signed in and cleared MFA or SSO. It never asks you to paste a password or code into the chat, which is exactly what the hosted flow avoids.
4. Confirms the connection reads AUTHENTICATED and saves the profile.

The profile is a named, durable bundle of cookies and login state that your sign-in produces. The managed auth connection keeps a profile and domain logged in by re-authenticating on a health-check interval, so the grant carries across runs instead of asking you to re-approve every time.

Copy link to headingDrive an authenticated task

using my github profile, go to github.com/explore and tell me 3 things it's showing based on my interests

eve starts the session on the saved profile, so it begins logged in, then runs the browse loop and reports back with the outcome and a live-view URL.

The browser session is shared between you and the agent, so either of you can take control at any point. Every session exposes a live URL that a human can watch, and eve re-reads the page after a takeover before continuing.

Copy link to headingTroubleshooting

Copy link to headingNext steps

• Vercel Connect: the access broker that mints per-user tokens
• @onkernel/eve-extension: the one-line mount that gives an eve agent KERNEL's browser toolset
• eve-connect-kernel cookbook: this guide’s reference implementation
• KERNEL managed auth docs: the canonical reference for profiles, connections, and hosted login
• KERNEL documentation: cloud browsers, sessions, and the full MCP toolset