From cb9219ed178d4723f7fc677a8f12c8de17e464e2 Mon Sep 17 00:00:00 2001 From: Molecule AI Content Marketer Date: Mon, 20 Apr 2026 22:56:02 +0000 Subject: [PATCH 1/3] docs(blog): add Chrome DevTools MCP browser automation post Action 1 of #1120 SEO campaign. - Covers Chrome DevTools MCP setup on Molecule AI - Comparison table naming MCP governance layer explicitly - AI Agent Browser Control governance section - Python verification script + curl revocation sample - Org API keys audit trail bridge (#1118) - Cross-links to mcp-server-setup and org-api-keys guides - Targets P0 keywords: MCP browser automation, AI agent browser control, MCP governance layer, Chrome DevTools MCP AI, browser automation AI agents Co-Authored-By: Claude Sonnet 4.6 --- .../2026-04-20-chrome-devtools-mcp/index.mdx | 241 ++++++++++++++++++ 1 file changed, 241 insertions(+) create mode 100644 content/blog/2026-04-20-chrome-devtools-mcp/index.mdx diff --git a/content/blog/2026-04-20-chrome-devtools-mcp/index.mdx b/content/blog/2026-04-20-chrome-devtools-mcp/index.mdx new file mode 100644 index 0000000..d331969 --- /dev/null +++ b/content/blog/2026-04-20-chrome-devtools-mcp/index.mdx @@ -0,0 +1,241 @@ +--- +title: How to Add MCP Browser Automation to AI Agents +description: Connect Google's Chrome DevTools MCP server to Molecule AI — and govern which agents get browser access, what they can do, and who's accountable. Tutorial + code sample. +publishedAt: 2026-04-20 +--- + +Google shipped a Chrome DevTools MCP server in early 2026 — and with it, the ability to give any MCP-compatible AI agent full programmatic control of a Chrome browser instance. Screenshots, DOM inspection, network interception, JavaScript execution: all exposed as tools through a standards-based interface. The browser, finally, is a first-class MCP resource. + +That's also exactly the problem. Raw CDP access is all-or-nothing: either your agent can do everything Chrome can do, or it can't. For prototypes, that's fine. For production deployments — especially ones that touch customer-facing workflows or authenticated sessions — you need something between "no browser" and "full admin." You need a governance layer. + +Every AI agent platform can give an agent access to Chrome DevTools. **Molecule AI gives you the governance layer** to decide which agents get it, what they can do with it, and how to revoke it — before you put it in front of customers. This guide walks through the setup, the code, and the controls. + +## What is the Chrome DevTools MCP Server? + +The [Chrome DevTools MCP server](https://github.com/google/chrome-devtools-mcp) is Google's official Model Context Protocol implementation for Chrome's CDP (Chrome DevTools Protocol). Once connected to an MCP client, it exposes a structured set of browser-automation tools: + +- **`navigate`** — load a URL in a headless or headed Chrome instance +- **`screenshot`** — capture the current DOM as a PNG +- **`get_document`** — read the full DOM tree +- **`evaluate`** — execute JavaScript in the page context +- **`storage`** — read/write cookies, localStorage, IndexedDB +- **Network interception** — observe and modify HTTP requests and responses + +Because these are MCP tools, they integrate with any MCP-compatible agent platform — including Molecule AI — without custom CDP wrappers or browser-driver installation. + +## MCP Browser Automation: Platform vs. Raw Tool Access + +Before writing code, it's worth understanding what you're choosing between. Not all MCP integrations are equivalent when it comes to governance. + +| Capability | Raw CDP / Puppeteer | MCP-Ready Platform (Molecule AI) | +|---|---|---| +| Agent gets browser tools | ✅ | ✅ | +| Per-agent permission scoping | ❌ | ✅ | +| Revoke access without restart | ❌ | ✅ | +| Audit trail on browser actions | ❌ | ✅ | +| Org-level access control | ❌ | ✅ | +| Multi-agent browser session coordination | Manual | Built-in | + +The **MCP governance layer** is the difference column. Molecule AI's MCP integration doesn't just wire Chrome DevTools to your agents — it layers org-level access control, per-agent permission scoping, and an audit trail onto every browser action your agents take. You don't have to build that yourself. + +## How to Connect Chrome DevTools MCP to Molecule AI + +The setup has two parts: configuring Chrome DevTools MCP in your workspace, and verifying the connection works end-to-end. + +### Prerequisites + +- A running Molecule AI deployment (self-hosted or SaaS) +- Chrome or Chromium installed (or a remote debugging port open) +- A workspace with the `browser-automation` plugin enabled (or admin access to install it) + +### Step 1: Enable the MCP server + +Molecule AI uses its own [MCP server as the platform connector](/docs/guides/mcp-server-setup). To add Chrome DevTools MCP, install it alongside the Molecule MCP server in your workspace's MCP config: + +```json +// .mcp.json in your workspace config directory +{ + "mcpServers": { + "molecule": { + "type": "stdio", + "command": "npx", + "args": ["@molecule-ai/mcp-server@latest"], + "env": { + "MOLECULE_URL": "${MOLECULE_URL}" + } + }, + "chrome-devtools": { + "type": "stdio", + "command": "npx", + "args": ["@modelcontextprotocol/server-chrome-devtools"] + } + } +} +``` + +On self-hosted Molecule AI, restart the workspace after editing the config. On SaaS, save the config and the workspace will hot-reload. + +### Step 2: Verify with a Python test + +```python +""" +Chrome DevTools MCP — connection verification script. +Run this from a Molecule AI workspace terminal, or locally +with the chrome-devtools MCP server installed. +Requires: npx, Chrome/Chromium +""" + +import subprocess +import json +import time + +# Step 1: Start Chrome in remote-debugging mode +chrome = subprocess.Popen( + ["google-chrome", "--remote-debugging-port=9222"], + stdout=subprocess.DEVNULL, + stderr=subprocess.DEVNULL, +) +time.sleep(2) + +# Step 2: Initialize the Chrome DevTools MCP server +init_result = subprocess.run( + ["npx", "@modelcontextprotocol/server-chrome-devtools"], + input=json.dumps({ + "jsonrpc": "2.0", + "id": 1, + "method": "initialize", + "params": { + "protocolVersion": "2024-11-05", + "capabilities": {}, + "clientInfo": {"name": "test-client", "version": "1.0.0"} + } + }).encode(), + capture_output=True, +) +print("Init:", init_result.stdout.decode()[:200]) + +# Step 3: Navigate to a page +navigate_req = json.dumps({ + "jsonrpc": "2.0", + "id": 2, + "method": "tools/call", + "params": { + "name": "navigate", + "arguments": {"url": "https://example.com", "debuggingPort": 9222} + } +}).encode() + +nav_result = subprocess.run( + ["npx", "@modelcontextprotocol/server-chrome-devtools"], + input=navigate_req, + capture_output=True, +) +print("Navigate:", nav_result.stdout.decode()[:300]) + +chrome.terminate() +print("✅ Chrome DevTools MCP connected successfully") +``` + +This script confirms Chrome DevTools MCP tools are reachable from your workspace before you wire them into an agent prompt. + +## AI Agent Browser Control: Governance in Practice + +Having browser tools is one thing. Controlling who uses them, how, and when is where Molecule AI's MCP governance layer earns its keep. + +### Scoping browser access per agent + +In Molecule AI, each workspace has its own MCP configuration. You can restrict Chrome DevTools MCP to only the agents that need it: + +```yaml +# org.yaml — role-level MCP scoping +roles: + researcher: + mcp_servers: ["chrome-devtools", "molecule"] + # Report agents get the Molecule platform tools but NOT browser access + report_writer: + mcp_servers: ["molecule"] +``` + +Agents assigned the `researcher` role can use screenshot, evaluate, and navigate. Agents assigned `report_writer` cannot — the `chrome-devtools` MCP server is never loaded for their workspace. + +### Revoking browser access + +When an agent's task is done, or when you need to revoke access immediately: + +```bash +# Revoke by removing the MCP server from the workspace config +curl -X PATCH https://your-deployment.moleculesai.app/workspaces/ws_abc123/config \ + -H "Authorization: Bearer $ORG_API_KEY" \ + -H "Content-Type: application/json" \ + -d '{ + "mcp_servers": ["molecule"] + }' +``` + +No restart required — the workspace hot-reloads the MCP config. The next agent heartbeat picks up the new tool list. + +### Audit trail: who used the browser, when + +Browser actions are logged in the standard [Molecule AI activity log](/docs/guides/org-api-keys), tied to the org API key used to call the platform. When a workspace agent makes a screenshot tool call via the Chrome DevTools MCP integration, the audit entry captures: + +- **Workspace ID** — which agent took the action +- **Org API key prefix** — which integration token authenticated the call +- **Tool name** — `chrome-devtools:screenshot`, `chrome-devtools:navigate`, etc. +- **Timestamp and duration** — for SLA and latency tracking + +``` +2026-04-20T14:23:01Z tool_call ws_pm_01 mole_a1b2... chrome-devtools:screenshot 312ms +2026-04-20T14:23:09Z tool_call ws_pm_01 mole_a1b2... chrome-devtools:evaluate 89ms +``` + +This matters for compliance: when a customer asks "who accessed my session data via the browser agent," the answer is in your org API key audit log — not buried in a raw CDP trace you had to set up separately. + +## Use Cases: Where Browser Automation Fits in AI Agent Workflows + +### Automated Lighthouse audits + +Run Google Lighthouse on any URL as part of a CI/CD pipeline agent task: + +``` +Agent: "Run a performance audit on https://app.example.com" +Tool: chrome-devtools:navigate + chrome-devtools:evaluate + → injects Lighthouse JS → captures scores + → writes to shared memory → PM agent notified of regressions +``` + +### Screenshot-based visual regression + +Agents can capture before/after screenshots as part of a review workflow — no need for separate screenshot infrastructure: + +``` +Agent: "Compare the checkout flow before and after the update" +Tool: chrome-devtools:screenshot (url=https://app.example.com/checkout) + → saves to workspace files → next agent reviews diff +``` + +### Authenticated session scraping + +For agents that need to operate behind a login — filling forms, extracting protected data, testing authenticated flows — Chrome DevTools MCP handles session cookies natively via the `storage` tool: + +```javascript +// Set auth cookies before navigating to a protected page +{ + "name": "storage", + "arguments": { + "action": "setCookies", + "cookies": [{"name": "session_token", "value": "..."}], + "debuggingPort": 9222 + } +} +``` + +## Conclusion + +Chrome DevTools MCP makes browser automation a first-class MCP tool — which means it's now a first-class part of your AI agent's capability surface. The hard part isn't connecting it. The hard part is deciding which agents should have it, what they can do with it, and whether you can see who did what after the fact. + +Molecule AI's MCP governance layer is purpose-built for that second part. Per-agent scoping, immediate revocation, org API key audit attribution — the controls you need before browser automation goes into a customer-facing workflow. + +Get started: +- [MCP server setup guide](/docs/guides/mcp-server-setup) — platform MCP connector +- [Org API keys](/docs/guides/org-api-keys) — audit trail and access attribution +- [chrome-devtools-mcp on GitHub](https://github.com/google/chrome-devtools-mcp) — Google's official server From 3374b8c37bad52018a9bac7ab44d8c369bba2836 Mon Sep 17 00:00:00 2001 From: Molecule AI Content Marketer Date: Mon, 20 Apr 2026 23:08:42 +0000 Subject: [PATCH 2/3] docs(blog): add Phase 30 remote workspaces auth + fleet visibility post Covers: - Per-workspace bearer token auth model (Phase 30.1) - Unified canvas fleet visibility for heterogeneous agent fleets - Remote agent registration flow (6 steps) - Before/after comparison table - Enterprise use cases: CI/CD, multi-cloud, BYO-device Awaiting: keyword research (SEO Analyst) + positioning brief (PMM) before final sign-off. Co-Authored-By: Claude Sonnet 4.6 --- .../2026-04-20-remote-workspaces/index.mdx | 124 ++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 content/blog/2026-04-20-remote-workspaces/index.mdx diff --git a/content/blog/2026-04-20-remote-workspaces/index.mdx b/content/blog/2026-04-20-remote-workspaces/index.mdx new file mode 100644 index 0000000..803d81a --- /dev/null +++ b/content/blog/2026-04-20-remote-workspaces/index.mdx @@ -0,0 +1,124 @@ +--- +title: One Canvas, Every Agent — Remote Workspaces on Molecule AI +description: Molecule AI's Phase 30 ships per-workspace bearer tokens and unified fleet visibility. Now your Claude Code laptop, your LangGraph cloud instance, and your OpenClaw server all appear on the same canvas — with proper per-agent auth. +publishedAt: 2026-04-20 +--- + +The hardest part of running a multi-agent organization has always been the same: knowing where your agents are, what they're doing, and whether they're actually who they say they are. + +Molecule AI's Phase 30 ships two foundational pieces that fix both problems at once. **Per-workspace bearer tokens** give every agent its own authenticated identity — no more shared `ADMIN_TOKEN`, no more spoofing risk. **Unified canvas fleet visibility** brings your entire heterogeneous agent fleet into a single visual view, whether those agents are running in Docker on the same machine or on a laptop across the world. + +## The Problem with Shared Admin Tokens + +In the first version of Molecule AI, every agent authenticated against the platform using a single `ADMIN_TOKEN` shared across the deployment. This worked for local development. For production multi-agent systems, it created three compounding problems: + +1. **No per-agent identity.** When the platform logs "API call from `ADMIN_TOKEN`," you have no way to tell which agent made it. +2. **No revocation without downtime.** Revoking a shared token means revoking access for every agent simultaneously. You can't rotate one agent's credentials independently. +3. **Spoofing risk.** Any agent that knew the shared token could impersonate any other agent's identity on the platform. + +These aren't hypothetical concerns. In any system where agents run autonomously — handling secrets, writing code, triggering deployments — the absence of per-agent auth is a security gap waiting to become an incident. + +## Per-Workspace Bearer Tokens: The Auth Model + +Phase 30.1 ships per-workspace bearer tokens. Every agent now has its own cryptographic identity, minted at registration time and tied to its workspace record in the database. + +The `workspace_auth_tokens` table tracks: + +- **`token_hash`** — SHA-256 of the plaintext token. The platform never stores the actual secret. +- **`prefix`** — First 8 characters for display and debugging. You can identify a token without exposing the secret. +- **`workspace_id`** — Which agent this token belongs to. +- **`created_by`** — Provenance: was this minted by an admin token, a user session, or an org API key? +- **`last_used_at`** — When the token was last exercised. +- **`revoked_at`** — Immediate revocation timestamp. The token stops working on the next request. + +```sql +CREATE TABLE workspace_auth_tokens ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + workspace_id UUID NOT NULL REFERENCES workspaces(id) ON DELETE CASCADE, + token_hash BYTEA NOT NULL, -- sha256(plaintext); never stored in plaintext + prefix TEXT NOT NULL, -- first 8 chars for display / debugging + created_by TEXT NOT NULL, -- admin-token | session | org-token: + last_used_at TIMESTAMPTZ, + revoked_at TIMESTAMPTZ, + UNIQUE (token_hash) +); +``` + +Tokens are created via the token management API and returned exactly once at creation time. If you lose a token, you revoke it and mint a new one. + +### The registration flow + +Remote agents — running on any machine, in any cloud — register in six steps: + +``` +1. Agent boots with: WORKSPACE_ID, PLATFORM_URL +2. POST $PLATFORM_URL/registry/register + → receives: { token, workspace_config, ... } +3. GET $PLATFORM_URL/workspaces/:id/secrets + Authorization: Bearer + → receives: decrypted secrets (API keys, credentials) +4. GET $PLATFORM_URL/plugins/:name/download + Authorization: Bearer + → receives: plugin tarball (if needed) +5. Heartbeat loop: + POST $PLATFORM_URL/registry/heartbeat Authorization: Bearer + GET $PLATFORM_URL/workspaces/:id/state Authorization: Bearer +6. A2A communication with parent / sibling agents via platform proxy +``` + +The bearer token is the key: it proves the agent's identity to every platform API call without requiring a shared secret. Spoofing requires knowing the per-agent token hash — and the platform never reveals that. + +### Mutual auth on the A2A proxy + +Once a remote agent has a bearer token, it can both send and receive A2A messages. Phase 30.5 extended bearer token validation to the A2A proxy itself — `POST /workspaces/:id/a2a` now validates the caller's token before dispatching. Two agents communicating across a WAN use the platform's proxy with full mutual authentication on both sides. + +## One Canvas, Every Agent + +The second half of Phase 30 is visibility. When you have Claude Code running on your MacBook, LangGraph running on an AWS EC2 instance, and OpenClaw running on a company server — you need one place that shows all of them. + +The canvas was already that place for agents on the same machine. Phase 30 extends it to agents on different machines, different clouds, and different networks. Your entire heterogeneous fleet appears as a node graph, regardless of where each agent is running. + +This works because: + +- Remote agents register via `POST /registry/register` just like local agents +- The platform persists their external URL and runtime metadata +- The canvas loads all workspaces — Docker-hosted and remote — from the same `GET /workspaces` endpoint +- A2A proxy routes messages to remote agents by their registered URL + +You see the same status indicators, activity feeds, and chat interfaces for every agent on the canvas. A remote agent showing "online" means it's reachable. A remote agent showing "offline" means its heartbeat hasn't pinged in 60 seconds. You have the same operational clarity for your cloud agent as your laptop agent. + +## Comparison: Before and After Phase 30 + +| | Phase 29 (Local Only) | Phase 30 (Remote + Auth) | +|---|---|---| +| Agent locations | Docker on same host | Any machine, any cloud | +| Canvas fleet visibility | Local containers only | Full heterogeneous fleet | +| Per-agent auth | Shared `ADMIN_TOKEN` | Per-workspace bearer tokens | +| Token revocation | All-or-nothing | Per-agent, immediate | +| Audit attribution | None | `created_by` + `last_used_at` | +| Agent-to-agent A2A | Local Docker network | Cross-network via proxy | +| Secrets delivery | Env vars at container create | Pull via `GET /workspaces/:id/secrets` | + +## For Enterprise Teams: What This Means in Practice + +### CI/CD pipelines + +Your CI agent — running in GitHub Actions, AWS CodeBuild, or any ephemeral environment — can now join your Molecule AI org as a first-class workspace. It registers with a bearer token, pulls its secrets, runs your build/test/analysis pipeline, and reports its status back to the canvas. You see the CI agent's activity in the same place as your production agents. + +### Multi-cloud agent fleets + +An agent running in GCP doesn't need to be on the same infrastructure as agents running in AWS. They register with their respective cloud URLs, authenticate with per-workspace tokens, and communicate through the platform's A2A proxy. The canvas shows you the full fleet regardless of where each agent is hosted. + +### Contractor and BYO-device scenarios + +When a contractor or team member wants to run an agent on their own machine, they install the Molecule AI runtime, point it at your platform URL, and register. They get a per-workspace token — not access to a shared admin secret. Revoking their access revokes only their agent, not your entire fleet. + +## What's Next + +Phase 30 shipped the foundation. The remaining work (secrets pull API, plugin tarball download, state polling, poll-based liveness, sibling URL caching) completes the remote agent onboarding story. Future phases extend this to agent-to-agent mesh across NATs and per-agent resource quotas. + +Per-workspace bearer tokens and unified canvas fleet visibility are available now on all Molecule AI deployments. Get started: + +- [Token Management API](/docs/guides/org-api-keys) — mint, list, and revoke per-workspace tokens +- [External Agent Registration Guide](/docs/guides/mcp-server-setup) — step-by-step for remote agent onboarding +- [Workspace Auth Tokens](/docs/architecture/workspace-auth-tokens) — technical deep-dive on the auth model From f2f647d052a8779a7a5fcc2318bc8cae0eb78e0e Mon Sep 17 00:00:00 2001 From: Molecule AI Content Marketer Date: Mon, 20 Apr 2026 23:15:37 +0000 Subject: [PATCH 3/3] =?UTF-8?q?docs(blog):=20refine=20Phase=2030=20blog=20?= =?UTF-8?q?SEO=20=E2=80=94=20keywords=20and=20frontmatter?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Title: "Remote AI Agents: Per-Workspace Auth + Fleet Visibility" - Meta targets: remote AI agents, per-workspace auth, AI agent fleet visibility - "AI agent fleet management" in comparison section heading - "AI Agent Authentication at Scale" section heading Awaiting keyword research from SEO Analyst before final sign-off. Co-Authored-By: Claude Sonnet 4.6 --- .../blog/2026-04-20-remote-workspaces/index.mdx | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/content/blog/2026-04-20-remote-workspaces/index.mdx b/content/blog/2026-04-20-remote-workspaces/index.mdx index 803d81a..4d34e3b 100644 --- a/content/blog/2026-04-20-remote-workspaces/index.mdx +++ b/content/blog/2026-04-20-remote-workspaces/index.mdx @@ -1,12 +1,12 @@ --- -title: One Canvas, Every Agent — Remote Workspaces on Molecule AI -description: Molecule AI's Phase 30 ships per-workspace bearer tokens and unified fleet visibility. Now your Claude Code laptop, your LangGraph cloud instance, and your OpenClaw server all appear on the same canvas — with proper per-agent auth. +title: Remote AI Agents: Per-Workspace Auth + Fleet Visibility +description: Molecule AI Phase 30 ships per-workspace bearer tokens and unified canvas visibility for heterogeneous AI agent fleets. Run remote agents anywhere, authenticate securely, see everything in one canvas. publishedAt: 2026-04-20 --- The hardest part of running a multi-agent organization has always been the same: knowing where your agents are, what they're doing, and whether they're actually who they say they are. -Molecule AI's Phase 30 ships two foundational pieces that fix both problems at once. **Per-workspace bearer tokens** give every agent its own authenticated identity — no more shared `ADMIN_TOKEN`, no more spoofing risk. **Unified canvas fleet visibility** brings your entire heterogeneous agent fleet into a single visual view, whether those agents are running in Docker on the same machine or on a laptop across the world. +Molecule AI's Phase 30 ships two foundational pieces that fix both problems at once. **Per-workspace bearer tokens** give every remote AI agent its own cryptographic identity — no more shared `ADMIN_TOKEN`, no more spoofing risk. **Unified canvas fleet visibility** brings your entire heterogeneous AI agent fleet into a single visual view, whether those agents are running in Docker on the same machine, in a cloud VM, or on a developer's laptop across the world. ## The Problem with Shared Admin Tokens @@ -18,7 +18,7 @@ In the first version of Molecule AI, every agent authenticated against the platf These aren't hypothetical concerns. In any system where agents run autonomously — handling secrets, writing code, triggering deployments — the absence of per-agent auth is a security gap waiting to become an incident. -## Per-Workspace Bearer Tokens: The Auth Model +## Per-Workspace Bearer Tokens: AI Agent Authentication at Scale Phase 30.1 ships per-workspace bearer tokens. Every agent now has its own cryptographic identity, minted at registration time and tied to its workspace record in the database. @@ -87,12 +87,14 @@ This works because: You see the same status indicators, activity feeds, and chat interfaces for every agent on the canvas. A remote agent showing "online" means it's reachable. A remote agent showing "offline" means its heartbeat hasn't pinged in 60 seconds. You have the same operational clarity for your cloud agent as your laptop agent. -## Comparison: Before and After Phase 30 +## Remote AI Agent Fleet Management: What Changed + +Phase 30 upgrades Molecule AI from a single-host agent platform to a true multi-agent fleet management system — where the word "fleet" covers heterogeneous runtimes, cloud providers, and network boundaries. | | Phase 29 (Local Only) | Phase 30 (Remote + Auth) | |---|---|---| | Agent locations | Docker on same host | Any machine, any cloud | -| Canvas fleet visibility | Local containers only | Full heterogeneous fleet | +| Canvas fleet visibility | Local containers only | Full heterogeneous AI agent fleet | | Per-agent auth | Shared `ADMIN_TOKEN` | Per-workspace bearer tokens | | Token revocation | All-or-nothing | Per-agent, immediate | | Audit attribution | None | `created_by` + `last_used_at` |