Security Model

Threat model, invariants, sandbox architecture, and security principles for Gao Browser (Layer 2).

Design Philosophy#

Gao Browser security is built on three non-negotiable principles:

Explicit authorization — no consequential action executes without a user-provided signature or approval
Trust signals are mandatory — the trust level of every .gao identity is always shown; no page or agent can suppress it
Sandbox isolation — the browser runtime isolates execution contexts to prevent cross-contamination between sites, agents, and zones

Threat Model#

In-Scope Threats

Threat

Mitigation

Phishing via unverified domains

Mandatory Level 0 warning; cannot be suppressed by page content

Agent impersonation

Trust badge derived from parent domain on-chain; cannot be self-asserted

Unsigned payment execution

All payments require explicit wallet signature; browser cannot sign on user’s behalf

Agent scope escalation

Scope checked against on-chain domain record; browser blocks out-of-scope actions

Receipt tampering

Receipts produced by Layer 4; browser displays but cannot modify

Cross-site agent contamination

Agent execution isolated per domain; agents cannot read across domain boundaries

Malicious 402 response

Browser validates payee domain trust level before showing payment UI

Replay of stale payment proof

Receipt IDs are unique; browser passes to server which enforces replay prevention

Trust badge spoofing via CSS/content

Badge rendered by browser chrome, not page content; page cannot override

Out-of-Scope Threats

Compromise of the user’s wallet private key → wallet security responsibility
Malicious browser extension with DOM access → OS/extension security responsibility
Physical device compromise → device security responsibility
Smart contract vulnerabilities in Layer 4 → Layer 4 audit scope

Security Invariants#

The following invariants are enforced by the browser and cannot be overridden by page content, agent instructions, or governance:

Invariant

BR-INV-01

Every settlement action requires an explicit user wallet signature

BR-INV-02

Trust badge is always rendered from fresh resolver data, never from page-provided claims

BR-INV-03

Level 0 (Unverified) warning is always shown before payment or agent interaction; cannot be suppressed

BR-INV-04

Agent actions are always logged; the log cannot be cleared by the agent or page

BR-INV-05

Tier 2 actions always show an approval dialog; no page instruction can bypass it

BR-INV-06

Tier 3 actions always require out-of-band human authorization

BR-INV-07

The browser never stores private keys or seeds

BR-INV-08

Receipts are passed through unmodified; the browser cannot alter receipt content

BR-INV-09

Agent scope violations are always surfaced to the user; violations are never silent

BR-INV-10

Cross-domain agent contamination is impossible by architecture; agents are isolated per domain

Sandbox Architecture#

┌─────────────────────────────────────────────────────┐  
│                  Browser Process                     │  
│                                                      │  
│  ┌─────────────────┐    ┌─────────────────────────┐  │  
│  │  Browser Chrome  │    │   Policy Enforcement    │  │  
│  │  (trust badges,  │    │   Engine                │  │  
│  │   approval UI,   │    │   (invariants BR-INV-   │  │  
│  │   address bar)   │    │    01 through -10)      │  │  
│  └────────┬─────────┘    └────────────┬────────────┘  │  
│           │                           │               │  
│  ┌────────▼───────────────────────────▼────────────┐  │  
│  │              Content Renderer                   │  │  
│  │  ┌──────────────┐    ┌──────────────────────┐   │  │  
│  │  │  Site Frame  │    │  Agent Sandbox       │   │  │  
│  │  │  (site.gao)  │    │  (agent.site.gao)    │   │  │  
│  │  │              │    │  Isolated; no direct  │   │  │  
│  │  │  No access   │    │  cross-domain access  │   │  │  
│  │  │  to agent    │    │                      │   │  │  
│  │  │  sandbox     │    │                      │   │  │  
│  │  └──────────────┘    └──────────────────────┘   │  │  
│  └─────────────────────────────────────────────────┘  │  
└─────────────────────────────────────────────────────┘

Browser Chrome — the UI elements that display trust badges, approval dialogs, and payment confirmations. Page content cannot modify or overlay these elements.

Policy Enforcement Engine — evaluates every action against the invariant set before execution. Operates outside the content renderer; cannot be reached by page scripts.

Content Renderer — loads and renders page content. Isolated from the browser chrome and policy engine.

Agent Sandbox — isolated execution context for each agent. An agent operating under assistant.site.gao cannot access the frame or storage of site.gao or any other domain.

Trust Badge Rendering#

The trust badge in the address bar is rendered by the browser chrome — not by page content. This means:

A page cannot modify its own trust badge via CSS, JavaScript, or content injection
A page cannot overlay a fake trust badge on top of the real one
A page cannot instruct the browser to display a different trust level than what the resolver returned

This is the same principle as HTTPS padlock display — the browser controls it, the page cannot.

Known Limitations#

Resolver availability — if all resolver nodes are unavailable, the browser cannot verify trust levels. In this case, the browser shows an explicit “Resolution unavailable — trust unverified” indicator rather than showing a cached or assumed trust level.
Extension security — malicious browser extensions with DOM access could potentially overlay the browser chrome. Users should only install extensions from trusted sources. Gao Browser’s official distribution does not allow arbitrary extension installation in high-security mode.
Phishing outside the browser — the browser protects users within the browsing session. Social engineering attacks that happen outside the browser (email, messaging) are outside the browser’s security scope.
TTL window — trust levels are cached for up to 3600 seconds for content loading. For payment and agent contexts, the browser always re-queries — but there is a small window where a trust level change may not immediately propagate to content rendering.

Responsible Disclosure#

Security vulnerabilities in Gao Browser:

Email: security@gao.systems
Response SLA: 24 hours for critical, 5 business days for other
Scope: Trust badge rendering, payment flow, agent isolation, policy enforcement engine

The browser security model enforces the invariants described here on top of the Layer 4 (Payment), Layer 5 (Domain), and Layer 8 (AI OS) security models. See each layer’s security documentation for the invariants they enforce independently.