Automation with consent, by construction.
Twin Browser is gated at every layer — an allowlist of authorized hosts, signed authorization references, database-enforced tenant isolation, hashed keys, and a complete audit log. Consent isn't a policy here; it's the architecture.
Five layers between a goal and an action.
Each control is independent and fails safe — a missing authorization, an unlisted host, or an unreachable key store all stop the run rather than risk acting without consent.
Per-tenant consent allowlist
Every execution call is checked against your allowlist of authorized hosts. A request to an unlisted target returns 403 before a browser is ever launched. The allowlist is the technical backstop for consent — there is no bypass.
Signed-authorization references
Each authorized host is bound to a signed authorization — its scope, window, and rules of engagement. That reference is recorded with every run, so any action can be traced back to the paper that permitted it.
Row-Level-Security isolation
Tenancy is enforced in the database, not just the app. Postgres Row-Level-Security scopes every row to its owner, so one tenant can never read or drive another tenant's keys, skills, or run history.
Hashed API keys
The raw API key is shown exactly once, at creation. We store only a hash and metadata — a leaked database never yields a usable key, and revocation fails closed.
Full audit log
Every run records its goal, the path taken, the success condition, and the authorization reference. The result is an auditable trail of exactly what each agent did, on which target, under whose consent.
Built for authorized execution.
Every run is tied to a signed authorization. Every key is scoped to a tenant. Every action is logged. Security by architecture, not by policy.