I/O 2026 Put An Agent In Chrome. 2 Of 3 Users Broke It In 4

By Lazar Milicevic · Published August 20, 2026 · 8 min read

Google I/O 2026 dropped an AI agent into every Chrome tab. I ran it across a shared invoicing tool with four teammates for one afternoon. Two of them fired actions they never approved, one auto-sent an invoice to a real client, and none of it was logged anywhere I could pull. If your ops team shares browser profiles to do actual work, the governance hole is bigger than the productivity win.

The three I/O 2026 updates, ranked for an ops team (not a developer)

Every dev recap ranks these by API surface. Here's the ranking that matters if your bookkeeper gets sued when the agent misfires: Skills is the highest-risk update, WebMCP is second, Built-in AI is third. Skills lets a non-technical user install a packaged workflow from a blog post and trigger it from the address bar — same threat model as installing random Chrome extensions on the accounting laptop, except the install friction is one click and the permissions UI is unreadable.

Here's what each one actually does:

Every dev recap I read this week framed these as productivity. Fine for a solo builder. For a 3-person ops team sharing one Chrome profile against a live invoicing tool, the ranking flips. Skills is where a mistake hits a client. WebMCP is where your own SaaS becomes the weapon. Built-in AI is the reason your normal network logs won't show you what happened.

What broke in 4 hours of real testing

I ran this last week: three shared accounts on the invoicing tool we use daily, four users, one browser profile pattern, real client data. Not a sandbox. Within four hours, two of the three users triggered unintended actions.

The specific failure that still bothers me: one teammate installed a Skill that was supposed to "prep invoice drafts from selected line items." She hovered over a draft to read it. The Skill interpreted the hover as intent-to-send. The invoice went out. To a real client. For the wrong project.

Here's what Chrome did not give me after the fact:

• No default event log for agent actions in the browser
• No email confirmation before the send
• No undo / rollback
• No permission-scope UI a non-developer could read to figure out what the Skill was allowed to do
• No server-side notification that this request came from an agent vs. a human click

The only reason I know the send happened is the client replied asking why the invoice was for the wrong project. That's the audit trail. A confused email from a customer.

If you're small and shared-browser is your reality, this is the failure mode you inherit by default.

The three things to do this week

Don't wait for Google to ship a governance layer. Do these three things on Monday.

The checklist

• Disable Skills on any shared browser profile. Managed policy on the profile, or just turn it off in settings on every machine the accounting/ops team touches. Treat a Skill install like installing a random Chrome extension on the finance laptop — because functionally it is.
• If you own the web app your team uses, do not expose write actions through WebMCP. Read-only tools are fine (list invoices, search clients, summarize a report). Anything that sends, charges, deletes, refunds, or notifies a customer needs a human click the agent cannot fake.
• Log every agent-originated request server-side with the user, the tool called, the arguments, and a timestamp. Chrome will not do this for you. Your backend has to.

The third one is the boring work nobody showed a slide for at the keynote. It's also the difference between "we caught it in 5 minutes" and "the client emailed us three days later."

How to expose a WebMCP tool safely: a real pattern

Here's the pattern I use when a client asks to expose their SaaS to browser agents. Read-only endpoints are unrestricted. Write endpoints require a confirmation token that only a human interaction can generate.

# server-side: FastAPI example
from fastapi import FastAPI, HTTPException, Header
from pydantic import BaseModel
import secrets, time

app = FastAPI()
PENDING = {}  # token -> {user, action, args, expires}

class SendInvoiceArgs(BaseModel):
    invoice_id: str
    client_email: str

@app.post("/mcp/invoice/prepare_send")
def prepare_send(args: SendInvoiceArgs, user: str = Header(...)):
    # Agent can call this freely. It does NOT send.
    # It returns a token + a preview the user must confirm in-app.
    token = secrets.token_urlsafe(24)
    PENDING[token] = {
        "user": user,
        "action": "invoice.send",
        "args": args.dict(),
        "expires": time.time() + 120,
    }
    return {"confirm_token": token, "preview_url": f"/confirm/{token}"}

@app.post("/invoice/confirm_send/{token}")
def confirm_send(token: str, user: str = Header(...), csrf: str = Header(...)):
    # This endpoint is ONLY callable from a real form submit in the app UI,
    # protected by CSRF. The agent cannot forge the CSRF token.
    pending = PENDING.pop(token, None)
    if not pending or pending["expires"] < time.time():
        raise HTTPException(400, "expired or invalid")
    if pending["user"] != user:
        raise HTTPException(403, "user mismatch")
    # ... actually send the invoice ...
    audit_log(user=user, action="invoice.send",
              args=pending["args"], source="human_confirm")
    return {"ok": True}

Two properties matter here:

1. The MCP-exposed endpoint (prepare_send) never mutates state. Worst case, the agent spams your pending table, which you rate-limit.
2. The confirming endpoint requires a CSRF token that only your app's real UI issues. An agent driving the browser can click a button, so add a short-lived one-time code shown in a modal — a human reads it and types it, an agent using DOM automation reads it too. If you need real resistance, require WebAuthn on the confirm step. Now the agent physically can't complete it without a hardware key touch.

This is the "seatbelt" the keynote didn't ship.

The audit log Chrome won't give you

The other thing your backend has to do: mark every request that originated from an agent and log it separately from human traffic. Chrome doesn't set a standard header for this yet, but you can enforce your own convention on any tool you expose via WebMCP.

# middleware: tag agent-originated requests
@app.middleware("http")
async def tag_agent_requests(request, call_next):
    is_agent = (
        request.headers.get("x-mcp-client") is not None
        or request.headers.get("sec-agent-initiated") == "1"
    )
    request.state.is_agent = is_agent
    response = await call_next(request)
    if is_agent:
        await audit_write({
            "ts": time.time(),
            "user": request.headers.get("x-user-id"),
            "path": request.url.path,
            "method": request.method,
            "agent_client": request.headers.get("x-mcp-client"),
            "body_hash": request.state.body_hash,
            "response_status": response.status_code,
        })
    return response

Ship this before you expose a single write tool. When something misfires — and it will — you need to answer three questions in under 60 seconds: which user, which agent, what did it call, with what arguments. If your log can't answer those, you're the person emailing the client an apology while grep-ing nginx access logs at 11pm.

Two more practical rules I enforce on client projects:

• Rate-limit per-user, per-tool. An agent that fires 40 prepare_send calls in 10 seconds is not a workflow, it's a bug. Cap it.
• Reversibility window on destructive actions. Sends, deletes, charges — hold them in a 30-second "sent, but revocable" state and show a banner in the app. This is what Gmail's undo-send taught us. The agent can trigger, but the human still has a physical window to catch it.

The gap that decides who wins the SMB market

Here's the hot take. The agentic web is a governance problem before it's a productivity win. Whoever ships the audit layer, the permission-scope UI a non-developer can actually read, and a real undo button for browser-native agents will own the SMB segment for the next five years. Not the model vendors. Not Google. The person who makes it safe for a bookkeeper to install a Skill without hosing a client relationship.

Google's own Agent Safety guidance talks about human-in-the-loop for consequential actions. Fine as a principle. The Chrome shipping surface as of I/O 2026 does not enforce it — that's on you to add at the app layer and the profile-management layer.

If you're a small team, the near-term move is defensive: turn Skills off on shared profiles, expose only read tools via WebMCP, log everything server-side, and put human-confirmation gates on anything that touches a customer. If you're building a SaaS product, the opportunity is offensive: be the vendor that ships the confirmation flow, the per-tool audit stream, and the undo window. That's the market gap I see every week in real SMB deployments.

Where this lands in practice

I ship browser and workflow automation into small US ops teams every week — invoicing, CRM writes, email triage, lead follow-up. The pattern in this post (read-only MCP, human-confirmed writes, server-side audit, per-tool rate limits, revocable-send windows) is roughly the default checklist we apply before any agent touches a client's live SaaS. Most of the "agent went rogue" stories I hear from SMB owners resolve to two missing pieces: no confirmation gate on write actions, and no server-side log tagged with which agent called what. Both are a weekend of backend work, not a rewrite.

The keynote sold you the agent. Nobody sold you the seatbelt. Build the seatbelt before you let the agent drive.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.