Every time I gave an agent a browser via Playwright, the same thing bugged me: to let it do anything useful, it needs your logged-in session — and a logged-in session is basically all your access at once. It's the keys to the kingdom, or nothing.
That "all or nothing" is the actual problem. A few things I landed on to get an in-between:
Don't hand the agent the cookies — custody them. The browser session (Playwright's storage-state — cookies + localStorage) gets sealed and stored outside the agent. It's injected into an isolated browser profile at runtime, the agent process never actually holds it, and it's wiped when the run ends.
Seal per-site, not one blob. A GitHub-only session is its own sealed credential, separate from your email one. You grant an agent only the session it needs — so a repo-automation agent never carries your inbox.
Scope navigation, not just the login. Even with a session loaded, restrict where it can go. Allow github.com/* and everything else (mail.google.com, etc.) gets denied in-path, fail-closed — so a prompt-injected agent can't wander off to a site you never approved.
Kill switch = revoke the run. Revoking the instance drops the session immediately, mid-task.
Honest limitation: within one sealed session, this doesn't filter individual cookies — the granularity is "which session you seal" + "which URLs you allow," not per-cookie. Seal narrow sessions and it's tight.
I built this into an open-source tool (Chancery — Go binary, Apache-2.0, self-hosted) but the pattern matters more than the tool: custody the session, seal it narrow, scope the navigation, and make revocation drop it. If you're giving agents browsers and doing this cleaner, I'd genuinely like to hear it: https://github.com/chanceryhq/chancery
Top comments (0)