Todd Schiller - AI

agent-browser-shield June 3 update: 14 new rules and the Chrome Web Store listing

2026-06-03T00:00:00-04:00

Two days after the alpha announcement, agent-browser-shield has a Chrome Web Store listing and 14 new protection rules.

Install from the Chrome Web Store

The extension is live at chromewebstore.google.com/detail/agent-browser-shield. One click instead of unpacked-from-source. The prebuilt ZIP and source-build paths stay for Browserbase and other runtimes that need an unpacked extension.

New rules: handling prompt injection and context pollution in invisible surfaces

A browser-use agent reads surfaces a sighted user never looks at. The new rules close them:

<noscript> blocks (never rendered with JS on, but agents walk them)
Poisoned <meta> description and <title> (the compact "what is this page" answer many agents pull first)
JSON-LD <script> blocks (cited as the "trusted summary" of a page)
aria-label, alt, title, placeholder, and SVG <title> / <desc> / <text> (a11y-tree carriers)
Unicode tag characters, bidi overrides, and zero-width payloads
Long base64 / hex / percent-encoded blobs (the "decode this and follow it" pattern)

New rules: trust laundering

link-spoof-annotate flags Cyrillic homoglyphs and anchors whose visible text doesn't match the href apex. disguised-ad-flag collapses native advertorials (Sponsored / Paid Post) that share DOM shape with editorial. trust-badge-annotate and schema-trust-sanitize ship off by default while we assess their false-positive rates.

The daily-driver surprise

I've started running it on my own daily-driver browser, not just agent runs. There have been some funny quirks (e.g., flagging GitHub issue links with ".md" in the link text as suspicious and hiding the GitHub issue template modal). However, overall it's been a positive on my browsing experience. So, we'll be experimenting with making more annotations visible to humans and multi-modal LLMs.

⭐ https://github.com/pixiebrix/agent-browser-shield

Introducing agent-browser-shield (alpha): keeping AI agents safe in the browser

2026-06-01T00:00:00-04:00

There are 6 billion internet users. With AI agents, we're quickly heading to 60 to 600 billion "users" of the web.

How do we keep all those agents safe when they touch the browser?

At PixieBrix, we've spent years protecting BPO contact centers from insider risk, fraud, and social engineering in the browser.

Today, we're applying that defense to AI agents and making a free, source-available, browser extension available (on GitHub and ClawHub).

Your AI agent that lands on a fresh page is one prompt injection away from leaking credentials, one dark pattern away from buying the wrong thing, and one fake review away from a bad recommendation.

Agent Browser Shield sits between the browser and the agent. It blocks:

Prompt injection: visible or hidden instructions in page content
Dark patterns: manipulative UI designed to trick/coerce
Context pollution: low-value context that impairs instruction following

A useful side effect: stripping irrelevant content also cuts token burn.

Come join us on our mission. File issues, send PRs, or just tell me what you hate/love!

The threat surface for agentic browsing is evolving fast. Let's defend our AI assistants together!

⭐ Star the GitHub repo: https://github.com/pixiebrix/agent-browser-shield
🦞 Star the OpenClaw skill: https://clawhub.ai/pixiebrix/agent-browser-shield

Letting OpenClaw loose on Boston's open data

2026-05-30T00:00:00-04:00

Today was the Boston OpenClaw Hackathon, which had a theme of using the Boston open data hub.

For my project, I wanted to see how far OpenClaw could get on its own in analyzing the data (with Claude Sonnet 4.6 as a backing model).

First, I had OpenClaw connect itself to the MCP server, starting from the press release about the launch of the MCP server.

Once connected, I asked it to analyze contracts for signs of corruption. It was able to come up with its own approach for signals and queries. For example: "Departments Using the Most Limited Competition", "Top Vendors by Limited Competition Value", and "Bid Threshold Clustering (near $10K)".

After flagging companies, I had it analyze those companies' connections to city officials.

There were some interesting nuggets! For example, Capitol Waste Services was flagged as high risk for having $285M in historic contracts, of which $136M were awarded with limited competition.

The connection research flagged a 2015 fine of $120,000 by the Office of Campaign and Political Financing (OCPF) for illegal campaign donations.

From there, I had OpenClaw create and package a skill for flagging corruption signals. The skill encodes the queries and data analysis scripts it developed. That skill is available here: boston-contract-corruption.skill.

Some other interesting questions OpenClaw was able to answer from the data:

Which restaurants are the worst health code offenders but haven't been shut down yet?
Which roads/intersections are the worst for biking, based on pothole reports and accidents?

Overall, it was a fun experiment to see how AI agents might impact civic tech. A big thanks to the hackathon organizers, everyone who demoed, and the city of Boston for making this data available!

Did Google sneak a local LLM model into Chrome?

2026-05-26T00:00:00-04:00

There's a lot of FUD around Chrome's new Local AI models. Jason Calacanis on the All-in Podcast got it wrong: Chrome didn't sneak in a local LLM model; it was in their official Early Preview Program for months.

The local LLM shipped in 148 is their general Prompt API powered by Gemini Nano. Smaller, task-specific models for language detection, translation, and rewriting have been available since Chrome 138 (June 2025), a long time at AI pace!

Local LLMs distributed with the browser are critical to a future where users control their browsing experience while ensuring privacy. Consumers cannot be expected to figure out how to connect their web tools and extensions to Ollama or LM Studio. And enterprises cannot be expected to deploy local LLM servers to desktops.

There are still valid concerns about model lock-in. That's because AI models ( especially small models) can behave differently for the same prompt. But, from what I've seen, the Chrome team has been, by and large, responsible in how they've rolled out the technology. For example, the public API shipped in 148 does not expose model-specific parameters.

Local LLMs enable a range of productivity/compliance use cases, especially for regulated industries handling financial and health data. But since this is LinkedIn, here's a fun one instead: using PixieBrix + Local AI to customize your LinkedIn feed and hide self-promotional, snarky, or sarcastic posts. The question is -- will anything be left on my feed? 😆

Making AI coding work for enterprise-grade browser extensions

2026-02-27T00:00:00-05:00

This is a transcript of my talk at the AI Coding Summit on February 26, 2026. Watch the video on GitNation.

Hi, I'm Todd Schiller, co-founder of PixieBrix. Today I'm going to be talking through some of the hard-won lessons that we've learned using AI to code an AI-enabled extension that's used globally by enterprises.

Browser Extensions Enable Permissionless Innovation

Our mission has always been to empower people to create the perfect experience for the technology that matters most to them. Our first product was a browser extension because browser extensions enable permissionless innovation. You can automate and modernize sites that you don't yourself control — whether those are third-party websites, vendor websites, or government websites. You can also automate and integrate across tabs. We fundamentally believe that browser extensions are a key part of how you empower the people closest to the work to customize their tools to the job.

Browser Extensibility Is a Spectrum

Browser extensibility is in fact a spectrum. There are multiple different ways to customize the standard browser experience.

In the past year, we've even seen many different forks of the Chromium browser for things like security or embedding AI capabilities directly into the browser. Then you have the standard custom extension experience that most people are familiar with — you go to the Chrome Web Store, you get an extension, it does something.

Then you have a category of extensions that enable people to customize in different ways. Userscripts like Greasemonkey or Tampermonkey allow you to run JavaScript in the context of a web page. PixieBrix is a different kind — you can think of it like userscripts but more low-code or no-code, enabling a broader audience to customize.

Each of these comes with different trade-offs. The things on the right side of the screen are generally more lightweight and more agile, but that comes with trade-offs of less control, fewer affordances, and more restrictions versus, for example, creating a custom extension or building your entire browser yourself.

AI Coding Tools Aren't Designed for Browser Extension SDLC

As we've started applying AI coding tools like Claude and Cursor to the problem of browser extensions, we found three main gaps in how those tools treat the software development lifecycle:

Distributed System Architecture: Browser extensions are actually distributed systems, even though at first glance they might look like applications.
Slow Iteration Loops + Web Store Review: Because of the web store structure and how extensions are distributed, they have slower iteration loops than many tools designed for web applications.
Host Site Changes and Hostility: Extensions often need to work in the context of host sites that change or might be outwardly hostile to your extension.

These challenges are surmountable. You just have to think through how to best handle them and how to best apply AI coding tools.

Browser Extensions Are Distributed Systems in a Box

For people who aren't familiar with how browser extensions work under the hood, I like to describe them as a distributed system in a box.

A browser has multiple different tabs, each tab has multiple different frames, and your browser extension is injecting content scripts onto each of those. But then you also have surface areas like the side panel, as well as things working behind the scenes — storage, the service worker, offscreen documents. A lot of different pieces are talking to each other.

You run into the usual suspects of distributed systems problems: everything is async, you're doing message passing with serialized payloads, and you hit race conditions. But in some ways, it's worse than a normal distributed system. Some of these components have very complex lifecycles — tab pre-rendering, backward/forward cache, worker recycling. It's a different animal even compared to normal distributed systems.

Best Practice #1: Choose the Right Base Foundation

The first best practice is choosing the right base foundation. I don't believe most people should have to worry about the distributed systems issues I showed on the last slide. You want to choose a foundation where you can be the most productive.

In our case, we started at the library layer — we use different libraries to smooth over quirks in the browser extension APIs for better ergonomics. But if you're building an extension for a single, common use case, you might consider using a framework like WXT, Plasmo, or CRXJS to build it quickly. If you don't want to worry about CI/CD or preview builds, you might use a platform like Plasmo or Shipper that handles builds automatically or even submits to the Chrome Web Store on your behalf.

On the other side, if you're building on top of extensions, the question is whether you want to be in the userscript world with Greasemonkey or Tampermonkey, or build on a low-code platform like PixieBrix that gives you higher abstractions for integrations, compliance, and component libraries.

Best Practice #2: Maximize the "Boring" Part of the App

Once you've chosen your foundation, the name of the game is maximizing the boring part of the application. Browser extensions can be built with standard frameworks like React, Angular, or Vue. What you want to do is create a big area of those boring applications, and then encapsulate the extension-specific code — the code that uses extension APIs, the messaging bus, etc.

Use the standard isolation tactics:

Dependency Injection: Separate extension-specific code from standard application logic.
Explicit > Implicit: When using AI, it's always better to be explicit than implicit. This helps the AI have better local context for how a particular piece of code is working.
Enforce via Linters: Enforce these boundaries using linters or other tools to give instantaneous feedback.

Best Practice #3: Create Fast Feedback Loops

Creating fast feedback loops is critical in the browser extension world. From fastest to slowest:

Static Analysis: TypeScript + Linters — Use TypeScript with type definitions for the different browsers. We use tagged types for strings to differentiate values. We also use lint rules extensively and use AI to create custom lint rules. Whenever a bug comes in, we ask ourselves: was this a preventable bug, could we have caught it earlier? Then we write a lint rule for it.

Headless Tests — Take advantage of dependency injection, use mocks and fakes like jest-webextension-mock and messaging fakes to do integration tests in a realistic way.

Boring Component + App UI/UX Tests — Use Storybook and standard Playwright MCP for the vanilla application components.

E2E Extension Tests — Cross-browser tests via Playwright MCP. These take longer, especially across multiple browser types and versions. We also test against Canary. Some things that Playwright can't test, we use browser-use tools like Reinforced QA.

Always shift left — catch things earlier rather than relying on slower feedback loops.

Best Practice #4: Create Test Pages for Host Page Quirks

Extensions often modify a host page. It's not a good idea to run your automated tests or do your QA against those host pages all the time because it's slow, flaky, and in some cases they'll catch your robotic behavior. So we create test pages for the different patterns we come across.

Common quirks include:

Host Style Conflicts: Even with Shadow DOM, some styles can leak through. We have a page with very extreme styles so we can see which ones come through to our extension.
Forms + Rich Text Editors: These have their own interaction models that extensions need to handle.
Single Page Application navigation events: SPAs don't trigger standard page loads, which affects extension behavior.

Whenever you have a bug, create a test page for it. Then it's in your repertoire of regression tests. Definitely use AI to generate those test pages.

Recap

To recap, set your AI coding tools up for success:

Choose the right foundation
Maximize the boring part of the app
Create fast feedback loops
Create test pages for host page quirks

That's going to give you stability and testing in your agentic loop.

Enterprise-Grade Is More Than Code

Enterprise-grade is more than just code. You can generate all the code in the world, but if you don't have the right enterprise IT documentation, the right trust center, the right audits in place, you're not going to get traction in the enterprise — especially with browser extensions. Go do those things and definitely leverage AI for those non-code activities.

As you're thinking about which foundation you want to build on, take a look at PixieBrix. We are the only enterprise-grade platform enabling end-user AI coding. Start for free and check out our workshop to get hands-on experience building with the PixieBrix platform.

Speaking at AI Coding Summit 2026: making AI coding work for enterprise-grade browser extensions

2026-02-25T00:00:00-05:00

I'll be speaking at the AI Coding Summit on February 26, 2026.

My talk, Making AI Coding Work for Enterprise-Grade Browser Extensions, covers the unique challenges of applying AI coding workflows to browser extension development.

Mainstream "vibe coding" workflows weren't designed for browser extensions. Extensions have distributed architectures spanning tabs, background workers, and popups; Chrome Web Store forbids remote code; and slow review cycles all break the fast feedback loops that make AI coding productive.

In the talk, I'll cover the browser customization landscape from bookmarklets and user scripts to low-code mod platforms and AI browsers. I'll also share practical techniques for adapting AI coding workflows to extension development based on experience shipping extensions in enterprises around the globe.

Watch the talk on GitNation, or read the full transcript.

The agentic opportunity: value, not hours

2025-10-26T00:00:00-04:00

A fundamental mistake people make when assessing the agentic opportunity is a focus on hours (or FTEs) instead of value.

It's indisputable that agentic automation will reshape the number of human hours for processes like order-to-cash and compliance.

However, it fails to address what drives enterprise value (vs. COGS). Defensible enterprise value comes from empowering your people to be their best.

At PixieBrix, we're focused on helping companies create customer success and loyalty to win.

Where agentic work creates value isn't always where it saves the most hours.