After Shipping 8 Chrome Extensions, These Are the 5 Rules I Always Give AI Agents

AI agents can build Chrome extensions surprisingly fast.

After shipping eight extensions, though, I found that the biggest risks usually do not come from whether the code runs.

They come from what the agent quietly adds while trying to be helpful:

• another permission
• an external request
• a new dependency
• a refactor I did not ask for
• a change in what user data is read or stored

All of those can affect security, privacy, maintenance, and Chrome Web Store review.

So before I ask an AI agent to implement anything, I now give it a small set of rules.

These are the five I use most often.

1. Do not add or broaden permissions without asking

Chrome extension permissions are part of the product.

If the agent adds:

"permissions": [
  "storage",
  "tabs"
]

or expands host_permissions, that is not just an implementation detail.

It changes what the extension is allowed to access and may change what users see during installation or what I need to explain during review.

So I explicitly tell the agent:

Do not add or broaden permissions without asking me first.

If a new permission is necessary, I want the agent to stop and explain:

• which permission is needed
• why it is needed
• what feature requires it
• whether there is a narrower alternative

The default should be minimum permissions, not “whatever makes implementation easier.”

2. Do not add network communication

A small local extension can easily become something very different if an agent introduces:

• an external API
• analytics
• telemetry
• a CDN
• remote configuration
• cloud storage

Sometimes these are useful.

But they should never appear accidentally.

For many of my extensions, I deliberately keep the design simple:

Web page
   ↓
Chrome extension
   ↓
chrome.storage.local

No server.

No account.

No external transmission.

That makes both the implementation and the privacy story easier to understand.

So my second rule is:

Do not add external network requests, analytics, telemetry, or CDN dependencies.

If network access is truly required, I want that to become a design decision before it becomes code.

3. Do not modify unrelated files or features

This one became more important as I started using coding agents for larger changes.

Suppose I ask:

Add a function that stores selected text in chrome.storage.local.

An agent may notice nearby code and decide to improve it too.

The result might work.

But now one small task has changed five files.

That makes review harder.

It also becomes difficult to answer a simple question:

What exactly changed because of this request?

So I usually add:

Do not modify unrelated files, features, or architecture.

For small Chrome extensions, I prefer changes that are easy to understand and easy to reverse.

I would rather make five small changes than one clever change that touches the entire project.

4. Do not add dependencies unless they are really necessary

AI agents are very good at finding packages.

That does not mean I want them.

If a 20-line utility function can solve the problem, adding another npm dependency may not be worth it.

Every dependency creates more things to understand:

• supply-chain risk
• updates
• licenses
• bundle size
• build complexity
• future maintenance

My rule is:

Do not add new dependencies unless they are necessary. If you think one is needed, explain why before adding it.

This is especially useful for browser extensions because many features can be implemented with the browser APIs and plain JavaScript.

Small tools benefit from staying small.

5. Stop before changing the data flow

This is the most important rule.

If an implementation changes:

• what data is read
• where data is stored
• how long it is stored
• whether data leaves the browser
• which pages the extension can access

I do not want the agent to decide that silently.

I tell it:

If your change affects what data is read, stored, or transmitted, stop and explain the change before implementing it.

This turns data flow into an explicit design decision.

For example:

Selected text
    ↓
Content script
    ↓
chrome.storage.local
    ↓
Extension UI

If the agent wants to change that into:

Selected text
    ↓
Content script
    ↓
External API
    ↓
Extension UI

that is not a small implementation change.

It is a different product architecture.

I want to know before the code changes.

The prompt I actually reuse

Here is the short version I give coding agents:

When modifying this Chrome extension:

- Do not add or broaden permissions without asking me first.
- Do not add external network requests, analytics, telemetry, or CDN dependencies.
- Do not modify unrelated files or features.
- Do not add new dependencies unless they are necessary.
- If your change affects what data is read, stored, or transmitted, stop and explain the change before implementing it.
- Keep the implementation compatible with Manifest V3.

I usually add the task itself underneath this block.

For example:

Task:

Add the ability to save selected text to chrome.storage.local.

Do not change the list UI or reordering behavior.

The important part is that the agent receives both:

what I want it to do

and

what it is not allowed to decide on its own.

I still verify everything myself

These rules reduce surprises.

They do not replace review.

Before publishing, I still check:

[ ] Are all permissions necessary?
[ ] Did any host permissions become broader?
[ ] Are there unexpected network requests?
[ ] Did the agent add a dependency?
[ ] Do I know exactly what data is read?
[ ] Do I know exactly what data is stored?
[ ] Does any data leave the browser?
[ ] Does the Chrome Web Store declaration match the implementation?

I also load the extension through:

chrome://extensions

and use it on real pages before submitting it.

An extension can pass tests and still feel annoying, request too much access, or behave differently from the store description.

What changed after eight extensions

AI has definitely made implementation faster for me.

But after shipping eight Chrome extensions, I spend less time asking:

Can the agent build this?

and more time asking:

What decisions should the agent not be allowed to make?

That distinction has become one of the most useful parts of my workflow.

AI agents are good at completing tasks.

My job is to define the boundaries around those tasks.

For Chrome extensions, those boundaries are especially important because permissions, network access, dependencies, and data handling affect not only the code, but also what users are being asked to trust.

I am building and documenting these experiments as part of Legacy Tools, a collection of small browser tools.

The full development workflow I use — from choosing an idea to Chrome Web Store review — is also available on the Legacy Tools site.