Browser agents inherit all your permissions by default

Browser agents are finally useful for real work. I've watched our support agent book meetings, update CRMs, and handle vendor portals that would take humans 20 minutes of clicking through terrible UIs.

But then I saw it try to approve a $2,400 refund by clicking through our finance portal's "emergency override" button. That's when I realized browser agents need different security thinking than API agents.

The problem: browser agents inherit all your permissions by default. They click with your authority, see everything you can see, and access every system your browser can reach. Unlike API agents with scoped tokens, browser agents are basically you, but automated.

Browser agents don't just fail—they fail with your full privileges across every logged-in system.

Here's the permission boundary that actually works:

1. Separate browser profiles for agent work

Don't let your agent run in your main browser profile. Create a dedicated profile with only the permissions it actually needs:

chrome --user-data-dir=/path/to/agent-profile

Log into only the systems your agent should touch. Skip your personal accounts, admin panels, and financial systems unless the agent specifically needs them for its job.

2. Domain allowlists, not denylists

Configure your browser agent to only operate on specific domains. Most frameworks support this:

allowed_domains = [
  "app.hubspot.com",
  "calendly.com", 
  "support.zendesk.com"
]

If your agent tries to navigate outside these domains, it should ask permission or fail gracefully.

3. Action approval gates for destructive operations

Build a pattern that catches dangerous clicks before they happen. Look for specific UI elements that should always require human approval:

• Buttons containing "delete," "remove," or "cancel"
• Form submissions over dollar thresholds
• Any action in admin or settings panels
• File uploads or downloads

4. Session boundaries that actually work

Browser agents can run for hours, accumulating permissions and context. Set hard session limits:

max_session_time = 30 minutes
max_actions_per_session = 50
require_reauth_after = 24 hours

When limits hit, the agent should save state and request a fresh session rather than continuing with stale permissions.

5. Audit trails for everything

Browser agents leave traces across multiple systems. Centralize the logging:

{
  "timestamp": "2024-01-15T14:30:00Z",
  "agent_id": "support-agent-1",
  "action": "clicked_button",
  "element": "#approve-refund",
  "domain": "admin.stripe.com",
  "value": "$2400",
  "approved_by": "human_required"
}

Every click, form submission, and navigation should be logged with enough detail to reconstruct what happened and why.

The trust boundary isn't about stopping your agent from working—it's about containing the blast radius when something goes wrong. Browser agents are powerful because they can interact with any web interface. That same power makes them dangerous without proper constraints.

Start with the tightest permissions that let your agent do its job, then expand carefully based on what it actually needs.