#Security

A tool that drives your logged-in browser has to be careful with it. reins keeps the attack surface small by having no cloud half at all: the pieces only ever talk to each other, on your machine.

##Network surface

• Everything binds 127.0.0.1. Neither the daemon nor the extension is reachable from the network.
• /rpc and the other daemon endpoints validate the Host header, so web pages cannot reach the daemon even through rebound DNS.
• The daemon accepts extension WebSocket connections only from exact allowlisted chrome-extension://<id> origins. The browser stamps that header itself, so pages and other extensions cannot forge it. Dev builds are added explicitly with reins allow <id>.

##Visibility and control

• Chrome shows its native "is being debugged" banner whenever the extension is attached to a tab, so you always know when an agent is acting.
• The toolbar popup's Disconnect toggle cuts the daemon connection at once.
• Nothing happens in the background: the extension only acts on explicit commands sent through the CLI on your machine.

##Per-site permissions

• Every host resolves to a tier: deny, read or full. The extension enforces it before any command touches a tab. The check runs inside the extension, so nothing that speaks the protocol can skip or loosen it. That includes the CLI, the daemon, and any other local client.
• Grants happen only in the extension popup. That is a user gesture, and an agent cannot perform it from the shell. The CLI (reins policy) can view and tighten the policy, never loosen it.
• The shipped default is full everywhere, which is today's behavior, so tightening is opt-in. deny also redacts the site's tabs from reins tabs.

→Tiers, wildcard rules and matching precedence

##Trust boundary

The tiers contain the agent you invited in. They are not a defense against other software on your machine. Anything already running as your OS user sits inside the trust boundary: it could talk to the daemon or rewrite the policy store directly, and no browser automation tool's permission model survives local malware. The honest write-up covers what the tiers protect against, what they do not, prompt injection, and a hardening checklist. It is the threat model (SECURITY.md).

##Audit trail

• Every command the daemon executes, and every one the policy blocks, appends one structured line (timestamp, command, browser, tab, host, tier, outcome, duration) to ~/.reins/logs/audit-YYYY-MM-DD.jsonl. reins audit renders the trail, and --denied shows only what policy blocked.
• Value-bearing params are redacted before the line is written: typed text, fill values, eval code and CDP payloads. The trail never stores what the agent typed, only that it typed.
• Audit files are pruned after 30 days. Writes are best-effort: a full disk never blocks a command.

##Data handling

• Page content and tab metadata are read through the Chrome DevTools Protocol only when your local daemon asks, and are sent only to that daemon over localhost.
• No analytics, no telemetry, no tracking, no remote servers, no remote code.
• The only stored state is the extension's own settings (auto-connect, cached daemon port, connection status) and your site-permission policy, kept in chrome.storage on your device.

The full policy is at reins.tech/privacy. The code is MIT-licensed and auditable at github.com/karnstack/reins.