← reins.tech

Site permissions

Every site resolves to one of three tiers, in order of power: deny < read < full. The extension checks the tier before it runs any command against a tab. The check lives in the extension itself, the one place a process on your machine cannot reach around, so even a misbehaving agent (or a compromised daemon) cannot skip it.

The shipped default is full everywhere, so a fresh install behaves exactly as before. The policy model is opt-in hardening: tighten the sites you care about, or flip the default and grant sites back one by one.

Tiers

denyNothing. Every command against the site fails, and its tabs appear redacted in reins tabs: tab id only, no URL or title.
readReading only. snapshot, text, screenshot, console, network and wait all work. click, type, navigate, eval, and everything else that acts on the page is blocked.
fullEverything, including navigation, interaction, eval and raw CDP.

Navigation is checked on both ends: reins nav and reins open need full on the destination host as well as the current one, so a read-only page cannot be steered somewhere permissive.

Rules and matching

  • A rule is a bare host (github.com) or a wildcard (*.google.com) paired with a tier.
  • An exact host match beats a wildcard. The longest wildcard suffix wins among wildcards. Anything unmatched gets the default tier.
  • *.foo.com covers subdomains and the apex foo.com, following Chrome's match-pattern convention.
  • Pages without an http(s) host (chrome:// pages, about:blank) are governed by the default tier.
  • Policy is stored per browser profile, so a locked-down work profile and a permissive scratch profile coexist naturally.

Granting and tightening

Grants happen only in the extension popup: click the reins icon, and the Site permissions section offers a tier control for the current tab, the rules list, and the default. That is deliberate. The popup is a user gesture, and an agent in your shell cannot perform one. From the CLI you can inspect the policy and tighten it, never loosen it:

$ reins policy                          # default, rules, tier per open tab$ reins policy readonly "*.github.com"  # reading only, no acting$ reins policy deny mybank.com          # off limits entirely$ reins policy allow mybank.com         # always errors: grants live in the popup

What a blocked agent sees

A blocked command fails with a policy_denied error. It names the host, its current tier, and what to do about it:

blocked by policy: mybank.com is read-only. Grant full access from thereins extension popup

The CLI prints the message and exits nonzero, so agents relay the instruction instead of retrying.

How this fits the broader trust model

Other pages