The Browser as a Personal Policy Engine

So far, the browser has supplied models, sessions, context and tools. We used them to inspect applications and constrain agent actions.

There is another direction the same architecture can travel.

Instead of asking only, “What can an agent do to a website?”, ask:

What should the website be allowed to do to the user’s attention?

A personal policy engine observes the page, evaluates content under rules chosen by the user and changes presentation locally. It is not the site’s moderation system. It is the user’s mediation layer.

1. Policy sits between content and attention

The pipeline is:

    flowchart TD
    P[Page content] --> U[Content units]
    U --> S[Evidence and signals]
    S --> D[User policy decision]
    D --> A[Show, label, blur or hide]
    A --> T[Audit and feedback]
  

The browser already receives the page and controls its local rendering. An extension can identify meaningful units, gather evidence, evaluate a declared rule and apply a reversible presentation change.

This is a better abstraction than a collection of unrelated blockers. The same engine can express policies about provenance, distraction, accessibility, privacy or personal workflow.

2. Evaluate content units, not entire pages

A page may contain human writing, generated summaries, advertisements, comments and images from different sources. Assigning one label to the whole document throws away that structure.

The extractor should produce units such as:

{
  "unitId": "local:feed-card:42",
  "kind": "article-card",
  "text": "…",
  "media": [],
  "declaredAuthor": "…",
  "provenance": [],
  "location": {
    "origin": "https://example.test",
    "route": "/feed"
  }
}

Site adapters can provide high-quality boundaries. A generic fallback may use semantic HTML, accessibility roles and conservative DOM heuristics. The trace must say which extractor produced the unit.

Private fields, editors, payment forms and messages should be excluded by default. Site access is not permission to ingest every visible character.

3. The runtime is an adapter

The policy engine should not belong to one AI company or one model.

Its classifier interface might be:

interface EvidenceProvider {
  id: string;
  capabilities(): Promise<CapabilityReport>;
  evaluate(unit: ContentUnit, request: EvidenceRequest): Promise<Evidence[]>;
}

Adapters may use:

• a Chrome built-in AI capability;
• a model running through Transformers.js with WebGPU or WASM;
• a localhost service such as a user-controlled model server;
• another browser-native runtime;
• an explicitly enabled remote provider.

The policy is stable even when the provider changes. Each decision records the adapter, model identity when known, configuration and evidence returned.

This is the same abstraction lesson we learned from the Prompt API: an application should depend on a capability boundary, not quietly entangle its rules with today’s model.

4. Policies are declarative

A portable policy should be data, not hidden prompt prose:

{
  "schema": "browser-policy/1",
  "id": "my-generated-content-policy",
  "scope": { "origins": ["*"] },
  "when": {
    "all": [
      { "signal": "ai-origin", "operator": "in", "value": ["verified", "declared"] }
    ]
  },
  "action": "hide",
  "fallback": "label",
  "allowReveal": true
}

The engine compiles this into deterministic predicates. Models may produce evidence, but they should not secretly decide the action. The user can inspect, export and edit the rule.

Policies need versioning because meaning changes. A decision should identify the exact policy version used.

5. Preserve uncertainty

Many useful signals are probabilistic. The engine should not collapse them prematurely into true or false.

An evidence item can state:

{
  "kind": "classifier-assessment",
  "label": "likely-ai-origin",
  "confidence": 0.71,
  "provider": "local-classifier-a",
  "limitations": ["short-text", "language-en"]
}

Policy then decides what that evidence warrants. One user may label uncertain content; another may take no action unless provenance is cryptographically verified.

“Unknown” is an important result. It prevents missing evidence from being mistaken for evidence of human authorship.

6. Make every presentation action reversible

The first actions should affect rendering, not underlying content:

• show unchanged;
• add a label and evidence summary;
• reduce prominence;
• blur with a reveal control;
• hide while leaving a placeholder;
• transform locally, such as removing an autoplaying element.

A placeholder should explain which policy acted and offer “show once” or “change rule.” The user needs an escape hatch when a classifier is wrong or the current context makes the rule unhelpful.

Reversibility also makes experimentation safer. We can compare policy versions without deleting information.

7. Budget latency and computation

A feed can add hundreds of units while the user scrolls. Running a model over every node would be slow and wasteful.

Use a staged pipeline:

1. inspect explicit provenance and platform labels;
2. apply deterministic rules;
3. hash and consult a local decision cache;
4. evaluate only units near the viewport;
5. batch compatible inference jobs;
6. cancel work for units that disappear;
7. fall back to a declared safe presentation when the runtime is unavailable.

The Observatory already knows how to measure queue time, first result, total latency and failure. Those metrics now describe the cost of the user’s policy.

8. Keep decisions inspectable

For each unit, record:

extractor → evidence → classifier → policy version → action → user override

The record should distinguish site declarations, signed provenance, local inference and remote inference. It should also show what data, if any, left the browser.

This turns a mysterious disappearing page into a debuggable system. It also lets the user ask whether a rule hides too much, fails on one language or behaves differently after a model update.

Conclusion

Browser AI does not have to mean an assistant owned by the browser vendor. It can be infrastructure for policies owned by the person using the browser.

The architecture is provider-independent: extract content units, gather typed evidence, apply declarative rules, render reversible actions and preserve a trace. In the next chapter we will use that engine to build a difficult concrete feature: a filter for content with evidence of AI origin.

Sources and further reading

1. Chrome for Developers, Chrome Extensions documentation.
2. Hugging Face, Transformers.js.
3. MDN, Intersection Observer API.