Skip to main content

How to Give an AI Agent Access to Your Live Browser Without Handing Over Passwords

5 min readBy Hamza

How to give an AI agent access to a live, logged-in browser without sharing passwords. I compared Playwright MCP, BrowserMCP, Blueprint MCP, Comet, Gemini, and Claude — then built my own extension.

give AI agent access to browserAI agent browser automationconnect AI agent to ChromeBrowserMCPPlaywright MCPChrome extension MCP

Need AI agent automation scripts for LinkedIn scrapers, profile finders, or post checkers? Contact me — I'll help you build them on top of a live browser, no credentials exposed.


TLDR: Give an AI agent browser access via a Chrome extension that bridges over WebSocket using MCP. BrowserMCP and Blueprint MCP work on your live, logged-in Chrome. Skip Playwright if you need existing sessions — it launches a clean browser and you lose all your auth. For lower token burn and tighter security, build a small extension with only the tools you need.


Why a Live Browser and Not Playwright?


I wanted Cloud Code and Opencode to reuse my logged-in sessions — Gmail, LinkedIn, internal dashboards. Playwright MCP looked like the obvious answer for AI agent browser automation. But it opened a fresh browser, not mine. That means managing cookies and re-auth every session.


The easy fix? Hand credentials to the AI so it can log in. I will never do that.


A live browser keeps auth where it belongs: my session, my 2FA, never exposed to the model. It also slides past anti-bot systems. Playwright browsers leak automation signals — missing extensions, headless fingerprints, weird timing — that Cloudflare flags instantly. My real Chrome has extensions, history, cookies, and a human-looking fingerprint. Sites trust it because it looks normal.


Whatever I picked had to do two things: keep credentials safe and look like a real user.


Which Browser-Control MCPs Actually Worked?


I tested a bunch of MCPs from Reddit. Two worked well: BrowserMCP and Blueprint MCP.


Both run the same pattern. A Chrome extension exposes tools — click, read DOM, navigate, scrape. The extension connects to the MCP server over WebSocket. The agent talks to the server, the server talks to the extension, and the extension acts inside your real Chrome. You stay logged in the whole time.


Setup takes minutes. Accounts stay logged in. No credential touches the AI. My first automation scripts ran on top of these — LinkedIn checks, profile lookups, simple scrapes — and they worked.


What About Browsers With Built-In AI Control?


I also tried browsers with AI baked in.


Comet by Perplexity — worked sometimes, failed on a lot of tasks. I wasn't comfortable logging into real accounts. No idea how far its access reached.


Chrome with Gemini control — US only for now. Worth exploring if you're there. Same full-access model.


Claude Code's browser connection — drives your browser directly. Works, but you're still handing full control to the agent.


All three skip passwords because you're already logged in. That removes the main security worry. But two problems remain.


First, you hand full browser control to the AI. You don't always know what it's doing.


Second, tokens. The agent burns huge context navigating to a page, finding the search bar, finding the button, then acting. If I wanted a fully autonomous agent, fine — but I'm a developer running the same workflows against the same sites daily. Letting the AI rediscover the page every run burns quota fast.


Why I Built My Own Extension Instead


I built a small custom extension with only the tools I needed: markdown page fetch, JSON extractor, a few selectors for the sites I hit every day. It connects over multiple ports to multiple AI agents at once. Each session opens its own window, nothing collides.


The reason I needed browser access was live data — not full autonomy. Markdown, JSON, current page state. Targeted tools give me that without paying tokens for the AI to re-explore a UI it already knows.


I built a LinkedIn post checker and a profile finder on top of this. They've been running for months. No passwords touched. No tokens wasted on navigation fluff. It isn't scalable and it isn't general-purpose. But for repeatable automation against known sites? It beats giving an AI the keys to my browser every time.


Related: How to Use an MCP Server in a JavaScript Script · Build Your Own Custom MCP Server · Reduce Token Usage in Claude Code and Opencode


Key Takeaways


  • Use a live browser when you need logged-in sessions. Playwright MCP can't reuse them cleanly and pushes you toward handing credentials to the AI — don't.
  • BrowserMCP and Blueprint MCP are the cleanest pattern. A Chrome extension bridged to the MCP server over WebSocket gives the agent tools without exposing your auth.
  • Built-in AI browsers (Comet, Gemini in Chrome, Claude Code's browser) work but cost tokens and full control. Fine for autonomy, wasteful for repeatable workflows.
  • Build a small extension with only the tools you need. Markdown fetch, JSON extraction, a few selectors. Lower tokens, smaller attack surface, your passwords stay yours.
  • Never give passwords to an AI agent. Reuse the live session instead.