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 diff --git a/content/blog/2026-04-20-org-api-keys/index.mdx b/content/blog/2026-04-20-org-api-keys/index.mdx new file mode 100644 index 0000000..38cf201 --- /dev/null +++ b/content/blog/2026-04-20-org-api-keys/index.mdx @@ -0,0 +1,119 @@ +--- +title: Org-Scoped API Keys: Enterprise Key Management for Multi-Agent Teams +description: Molecule AI ships org-scoped API keys — named, revocable, audit-trail-enabled tokens at the org level. Rotate without downtime. Attribute every call. Revoke instantly. +publishedAt: 2026-04-20 +--- + +When your engineering team scales from two agents to twenty, the last thing you want is a single `ADMIN_TOKEN` hardcoded in your environment. It's a single point of failure, impossible to rotate without downtime, and impossible to audit. Today's launch changes that. + +Molecule AI is rolling out **org-scoped API keys** — named, revocable, audit-trail-enabled tokens that live at the organization level and can reach any workspace in your org without breaking the security model. + +## What Are Org-Scoped API Keys? + +Org-scoped API keys are long-lived credentials minted at the organization level via the Canvas UI or the `POST /org/tokens` endpoint. Each key has: + +- A **display name** you choose at creation time (e.g., `ci-deploy-bot`, `devops-rev-proxy`) +- A **sha256 hash** stored server-side — the plaintext is shown once and never again +- A **prefix** (first 8 characters) visible in listings so you can identify keys without exposing secrets +- A **created-by** field that tracks provenance in the audit trail +- **Immediate revocation** — drop a key and it stops being accepted on the very next request + +The keys work across all workspaces in your org — not just admin-surface endpoints, but also per-workspace sub-routes like `/workspaces/:id/channels` and `/workspaces/:id/tokens`. + +## Why Enterprise Teams Need Org-Level Key Management + +### The `ADMIN_TOKEN` problem + +A single env-var token works for prototypes. For production multi-agent systems it creates three compounding risks: + +1. **Rotation requires downtime.** You can't rotate a token used by ten agents simultaneously. You rotate, or you don't — and both choices are bad. +2. **No attribution.** When something calls your API, you have no idea which agent or integration is responsible. +3. **No compartmentalization.** One compromised token compromises everything. + +### What org-scoped keys give you + +| Capability | `ADMIN_TOKEN` | Org-Scoped Keys | +|---|---|---| +| Rotate without downtime | ❌ | ✅ (one key revokes, another takes over) | +| Identify caller per request | ❌ | ✅ (audit prefix in every log line) | +| Revoke a single integration | ❌ | ✅ (per-key revocation) | +| Assign to workspace subroutes | ❌ | ✅ | +| Audit trail with attribution | Partial | ✅ (`created_by` + prefix in logs) | + +## Audit Trail and Rate-Limit Controls + +Every request authenticated with an org API key carries the key's prefix in the audit log, making it straightforward to trace calls back to a specific integration. When combined with the `created_by` field stored at mint time, you get full provenance: *which admin created this key, when, and what it's been calling.* + +The token hierarchy, from most to least trusted: + +- **Lazy bootstrap** (Tier 0) — only active when there are zero org tokens and no `ADMIN_TOKEN` at all +- **WorkOS session** (Tier 1) — verified user sessions +- **Org API tokens** (Tier 2a) — new org-scoped keys (primary path for service integrations) +- **`ADMIN_TOKEN` env var** (Tier 2b) — break-glass for operators, CLI tooling +- **Workspace tokens** (Tier 3) — deprecated per-workspace tokens + +## How to Get Started + +### Mint a key via API + +```bash +curl -X POST https://your-deployment.molecule.ai/org/tokens \ + -H "Authorization: Bearer " \ + -H "Content-Type: application/json" \ + -d '{ + "name": "ci-deploy-bot", + "description": "GitHub Actions deploy pipeline" + }' +``` + +Response (plaintext shown once — store it securely): + +```json +{ + "id": "tok_01HXYZ...", + "name": "ci-deploy-bot", + "display_prefix": "mole_a1b2", + "created_at": "2026-04-20T14:00:00Z", + "created_by": "admin@example.com" +} +``` + +### List and revoke keys + +```bash +# List all active keys (prefix-only, no plaintext) +curl https://your-deployment.molecule.ai/org/tokens \ + -H "Authorization: Bearer " + +# Revoke a key immediately +curl -X DELETE https://your-deployment.molecule.ai/org/tokens/tok_01HXYZ... \ + -H "Authorization: Bearer " +``` + +### Use in a workspace sub-route + +```bash +# Token hits workspace sub-route via org auth +curl https://your-deployment.molecule.ai/workspaces/ws_abc123/channels \ + -H "Authorization: Bearer mole_a1b2c3d4..." +``` + +## Org API Keys and the Browser Automation Governance Story + +Org-scoped API keys pair with Chrome DevTools MCP to give you a complete browser automation governance story. When an agent makes a screenshot or navigation call via Chrome DevTools MCP, every action is logged with the org API key prefix — so you can answer the question "which agent accessed what in this browser session?" without any additional instrumentation. + +See [Chrome DevTools MCP and the MCP Governance Layer](/blog/2026-04-20-chrome-devtools-mcp) for the full browser automation story. + +## Competitive Note: Hermes v0.10.0 Tool Gateway + +Hermes v0.10.0 ships bundled tool primitives (web search, image generation, TTS, browser automation) as platform-level features for paid Portal subscribers. This positions Hermes as "batteries included" for single-user AI. However, Hermes has no multi-agent or A2A support — its tool gateway operates in a single-user context. + +Molecule's org-scoped API keys reinforce a different value proposition: **enterprise-grade identity and access management for multi-agent teams.** The skills architecture offers greater composability than Hermes' bundled approach, and org tokens give teams the access-control primitives needed to deploy that composability safely in production. + +## Get Started + +Org-scoped API keys are available now on all Molecule AI deployments. + +- [Token Management API](/docs/guides/org-api-keys) — mint, list, and revoke org API keys +- [Org API Keys Architecture](/docs/architecture/org-api-keys) — technical deep-dive on the auth model and audit trail +- [Chrome DevTools MCP + Governance](/blog/2026-04-20-chrome-devtools-mcp) — browser automation with org-key audit attribution 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..4d34e3b --- /dev/null +++ b/content/blog/2026-04-20-remote-workspaces/index.mdx @@ -0,0 +1,126 @@ +--- +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 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 + +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: 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. + +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. + +## 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 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` | +| 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 diff --git a/content/blog/2026-04-20-waitlist/index.mdx b/content/blog/2026-04-20-waitlist/index.mdx new file mode 100644 index 0000000..893c3fd --- /dev/null +++ b/content/blog/2026-04-20-waitlist/index.mdx @@ -0,0 +1,45 @@ +--- +title: "Join the Molecule AI Beta: How Early Access Works" +description: "Molecule AI runs a beta allowlist. If you're not on it yet, the waitlist page is where you claim your spot — and tell us what you're planning to build." +publishedAt: 2026-04-20 +--- + +When Molecule AI launched its early access program, the team faced a familiar problem: you can't let everyone in at once, but you also can't afford to lose the people who want in. A "sorry, you're not on the list" dead-end is the fastest way to kill a potential customer's enthusiasm. + +That's why Molecule AI built the `/waitlist` page — and why it matters more than a generic "sign up for updates" form. + +## What the Waitlist Page Actually Does + +When someone attempts to log in via WorkOS and their email isn't on the beta allowlist, the platform doesn't show an error — it redirects them to `/waitlist`. There, they're greeted with a short explanation of what Molecule AI does, and a form that asks for three things: + +- **Email address** — so we can notify them when a spot opens +- **Name** (optional) — so we can personalize that notification +- **Use case** (optional) — so the team can prioritize the right kinds of teams first + +The form posts to `/cp/waitlist/request`, which stores the submission server-side. If the same email submits again within an hour, the backend returns a soft dedup response — the submission is noted, but the user sees a gentler "we already have you" message instead of a hard rejection. + +## Privacy: No URL Prefill, No Surprise Leaks + +Here's the detail that separates a thoughtful waitlist page from a careless one: the `/waitlist` form does not pre-fill the email from a URL parameter. + +In earlier implementations, some platforms passed `?email=user@example.com` as a query parameter in the redirect URL. It's convenient — the user doesn't have to type their email twice — but it means that email appears in server logs, browser history, shared links, and analytics tools that grab query strings. That's not acceptable when the data is a personal identifier. + +Molecule AI's `/waitlist` page was designed with this in mind from the start. Even if a bookmarked or cached redirect URL still carries `?email=`, the client-side code deliberately ignores it. The user re-enters their email themselves. + +## What Happens After You Submit + +Submissions flow into the Molecule AI backend, where the team can review them alongside the allowlist. High-signal signals — specific use cases, teams with existing agent infrastructure, organizations evaluating AI orchestration platforms — move faster. Generic "interested in AI" submissions still get through, but the team has the context to prioritize. + +There's no public waitlist count, no estimated wait time, no "you're #847 in line" anxiety. The team reaches out directly when a spot is ready. + +## The Launch CTA Angle + +For teams watching Molecule AI's trajectory, the `/waitlist` page is also a signal: this is an active, evolving product with a selective early access program, not a vapor-ware launch. When the platform is ready for a broader launch, the waitlist becomes the first cohort of production users — the ones who shaped the product through feedback. + +If you're evaluating AI agent orchestration platforms, submitting to the waitlist now means you're in the room when the next round of decisions gets made. + +## How to Submit + +Visit the `/waitlist` page after attempting to log in. If you haven't tried to log in yet, the page will accept your email directly. Fill in your use case — the more specific, the better. Someone on the Molecule AI team will follow up. + +Molecule AI is in active development. The fleet visibility, org-scoped API keys, and multi-cloud agent support shipped in Phase 30. If those features map to a problem you're trying to solve, the waitlist is where you get in. diff --git a/content/blog/2026-04-21-audit-trail-panel/index.mdx b/content/blog/2026-04-21-audit-trail-panel/index.mdx new file mode 100644 index 0000000..d16ffbd --- /dev/null +++ b/content/blog/2026-04-21-audit-trail-panel/index.mdx @@ -0,0 +1,63 @@ +--- +title: "See Every Decision Your AI Agents Make: Audit Trail Panel Ships on Canvas" +description: "Molecule AI Canvas now shows a live audit ledger for every workspace — delegation events, decision calls, human-in-the-loop gates, and tamper-evident chain integrity markers." +publishedAt: 2026-04-21 +--- + +> "We need to show our security team that our agent is making decisions the way we configured it — not going off-script. A screenshot of a chat log isn't going to cut it." +> +> — Platform engineer at a Series B fintech, describing what a compliance review needs before they'll approve agent workflows in production + +That's the ask. Not "show me the logs." Not "export a CSV." Show me what your agent actually did, in a form that a non-engineer can read and a compliance officer can sign off on. + +The Audit Trail Panel ships that answer directly into the Molecule AI Canvas. + +## What's in the Audit Trail + +Every workspace now has a live ledger accessible from the SidePanel's **Audit** tab. Each entry in the trail captures a discrete event in the agent's operational history: + +- **Delegation** — when the agent handed a task to another workspace. Who delegated to whom, when, and what the task was. +- **Decision** — when the agent made a consequential call: choosing a tool, routing a request, deciding to escalate. +- **Gate** — a human-in-the-loop checkpoint. When the agent paused for human approval before proceeding, what the human decided. +- **HITL** — a broader human-in-the-loop event, covering review flows and approval sequences. + +Each entry is color-coded by type, making it immediately visible at a glance whether you're looking at a routine delegation or a human-authorized escalation. The panel supports cursor-based pagination — "Load more" appends the next page, so there's no hard ceiling on how far back the trail goes. + +## Tamper Evidence: Chain Validity Indicators + +Here is the feature that separates an audit log from an audit trail. + +Each entry carries a `chain_valid` flag. When the Molecule AI backend detects that an event's cryptographic chain has been broken — that the entry may have been modified, deleted, or inserted after the fact — the ledger renders a red ⚠ indicator with accessible `aria-label` and `title` text. + +This is not a real-time intrusion detection system. It is evidence. When an auditor asks "can you prove this log wasn't altered after the fact?", the chain validity indicator is the answer. + +## Filtering by Event Type + +The filter bar at the top of the Audit Trail panel lets you isolate a single event type — all Delegation events, all Gates, all HITL checkpoints. Clicking a filter resets the page and re-fetches with the `?event_type=` parameter. The active filter shows `aria-pressed` state for accessibility. + +For compliance workflows, this means: "show me every human-in-the-loop gate this agent passed in the last 30 days" is one filter click and one scroll. + +## Enterprise Observability: The Layer Above Fleet Visibility + +Phase 30 gave operators fleet visibility — the ability to see every agent, everywhere, on one canvas. The Audit Trail Panel gives them **operational visibility**: the ability to understand *what happened* inside any individual agent's session, after the fact. + +These two features layer on top of each other. Fleet visibility tells you where your agents are and what state they're in right now. The audit trail tells you what they did, what decisions they made, and whether those decisions were authorized. + +For enterprises deploying AI agents in regulated environments — financial services, healthcare, legal ops, infrastructure — this is the observability stack that makes a production deployment defensible. + +## Where the Audit Trail Fits in the Phase 30 Story + +Phase 30 shipped per-workspace bearer tokens, giving every agent a cryptographic identity. The Audit Trail Panel is the observability layer that makes that identity useful: every API call made with a per-workspace token is now attributable to a specific agent, in a specific session, with a specific outcome. + +Combined with org-scoped API keys (which carry audit prefixes across every API call at the org level), Molecule AI now has a two-layer audit story: token-level attribution in API logs, and event-level attribution in the Canvas audit trail. Teams running production agents can answer "which agent did what, when, and was it authorized?" without stitching together a custom logging pipeline. + +## Get Started + +The Audit Trail Panel is live on all Canvas instances as of the 2026-04-17 release. + +- Open any workspace on the Canvas +- Click the **Audit** tab (⊟) in the SidePanel +- Filter by event type, scroll back through the history +- Look for the ⚠ indicator to confirm chain validity + +The panel requires no configuration, no plugin install, and no export step. It's already there.