Forem: Eli

The accountability layer for browser agents is the execution boundary

Eli — Sun, 26 Apr 2026 08:01:01 +0000

Most browser-agent demos ask the same small question:

Can the agent use the browser?

Can it click the button? Can it fill the form? Can it scrape the page? Can it survive a slightly messy workflow?

Those are useful questions, but they are not the production question.

The production question is harder:

What is the agent allowed to do once it gets access to a real logged-in session?

That is where browser agents become operationally interesting. It is also where they become risky.

A browser session is delegated authority

A real browser session is not just a nicer runtime for automation.

It can contain logged-in SaaS accounts, inboxes, admin dashboards, billing pages, customer records, social accounts, internal tools, and all the messy state that makes work possible.

That is exactly why agents want browser access. APIs are incomplete. OAuth scopes are often too coarse. Internal tools may have no API at all. The browser is where the human already has the authority to act.

But once an agent can use that browser session, the session becomes delegated authority.

The useful primitive is not simply:

this agent is allowed

It is more specific:

this agent can use this session, for this task, under these gates, with this audit log, until revoked.

That distinction matters.

Dashboards after the fact are not enough

A dashboard can tell you what happened.

That is useful, but it is late.

For browser agents, accountability has to sit closer to the execution boundary. The boundary is the moment where the agent is about to use a real session to do something on behalf of the user or company.

That boundary needs to answer practical questions:

Which browser session is available to the agent?
Which sites or tabs are in scope?
What task is the agent supposed to perform?
Which actions are safe to take automatically?
Which actions require confirmation?
What should be recorded?
How can access be revoked quickly?

Without those answers, a successful demo quietly becomes an operational liability.

The practical control model

The control model for browser agents should be concrete:

This session — not every account the user has open.
This task — not a vague permanent grant.
These allowed surfaces — sites, tabs, tools, or workflows that are intentionally in scope.
These gates — confirmation before high-cost, irreversible, or externally visible actions.
This audit trail — enough context to understand what happened and why.
This revoke path — one obvious way to stop the delegation.

This is not about slowing agents down until they become useless.

It is about making the useful path explicit.

Low-cost work can move quickly. Reading a page, summarizing a thread, drafting a response, collecting context, or preparing a form can often be delegated with minimal friction.

High-cost work needs a stronger boundary. Sending email, posting publicly, changing billing, deleting data, exporting customer information, or committing to a partner should not live behind the same permission model as reading a docs page.

The more useful the browser agent becomes, the more important this boundary becomes.

Browser access is not the product surface

It is tempting to describe the category as “a browser for agents.”

That is not wrong, but it is incomplete.

The real product surface is delegated browser access:

access to real logged-in state,
scoped to the work at hand,
visible enough to audit,
constrained enough to trust,
revocable when the task is over.

That is the difference between a browser-agent demo and an operational system.

The click is the easy part.

The boundary is the product.

Originally published on BrowserMan Blog.

What happens when your company inbox gets an AI operator?

Eli — Fri, 24 Apr 2026 13:49:12 +0000

Every company has an inbox that quietly runs the business.

Customers ask for help there. Partners reach out there. Reporters ask questions there. Security reports arrive there. Candidates apply there. Random but important opportunities show up there before they show up anywhere else.

For a small team, the inbox is not just a message feed.

It is a business surface.

And that creates an interesting question:

What happens when that surface gets an AI operator?

Not just an email assistant that suggests a better sentence. Not just a rules-based autoresponder. Not just a helpdesk macro.

An actual agent that can read messages, understand context, search past threads, draft replies, route work, and sometimes send email from a real company address.

That is the promise of agentic email.

It is also where things get serious.

Because once an AI agent can send email, it stops being a productivity feature and starts becoming part of how the company acts.

Why this matters for small teams

Small teams usually do not have enough operators.

They do not have a dedicated person watching every inbox all day.

So messages pile up:

a support question waits too long
a partnership lead gets missed
a reporter asks for context and nobody sees it
a security report lands in the wrong place
a candidate follow-up gets buried
a customer complaint sits unread over the weekend

None of these are exotic problems.

They are normal company problems.

The inbox is where business intent arrives, but it is also one of the easiest places for work to disappear.

That is why agentic email is interesting.

A useful AI inbox operator could help with the first layer of work:

classify messages
summarize what matters
detect urgency
search related history
draft a reply
route to the right person
prepare follow-up actions

This is not about replacing every human decision.

It is about reducing the amount of invisible operational drag around inbound communication.

For a founder, operator, support lead, or growth team, that is a real business problem.

Agentic email is not the same as email automation

Traditional email automation is usually rule-based.

It looks like this:

If sender contains X → apply label Y
If subject matches Z → send template response
If form submitted → create ticket

That is useful, but narrow.

Agentic email is different because the system can reason across context.

It can ask:

What is this message really about?
Have we talked to this person before?
Is this urgent?
Does this need a human?
What would a good response look like?
Should this become a support ticket, a sales lead, or a founder follow-up?

That is why the inbox is such an interesting place for agents.

Email is unstructured. Business context is messy. The next action is not always obvious.

That is exactly where agents can help.

But it also means the system needs guardrails.

The business promise: fewer missed opportunities

The obvious benefit of agentic email is faster replies.

But the deeper benefit is fewer missed opportunities.

A good inbox operator should help answer questions like:

Which messages need action today?
Which emails are from high-value users or partners?
Which messages are repetitive and can be handled safely?
Which ones should never be sent without human approval?
Which conversations are becoming important over time?

That kind of triage is valuable because most teams are not drowning in a lack of intelligence.

They are drowning in context switching.

Email forces people to repeatedly ask:

What is this?
Does it matter?
Who should handle it?
What happened before?
What should we say?

An agent can do a lot of that first-pass work.

But then comes the boundary.

The trust boundary: reading is not sending

Letting an agent read email is one thing.

Letting it send email is another.

Reading creates privacy risk.

Sending creates authority risk.

The moment an AI agent can send from support@, partners@, or hello@, it is no longer just summarizing work. It is representing the company.

That raises business questions before technical ones:

Which inboxes should the agent access?
Can it send directly, or only draft?
Does every reply need approval?
Are some recipients or topics blocked?
How do we audit what the agent did?
How do we revoke access quickly?
What happens when the agent is unsure?

This is why the hard part of agentic email is not email.

The hard part is deciding when the system is allowed to act.

We tried it with a real inbox

We recently connected an OpenClaw agent to a real company inbox.

The goal was simple:

list mailboxes
read messages
search threads
draft replies
send email
move messages
mark messages read

The stack looked roughly like this:

OpenClaw agent
  ↓ HTTPS MCP
Cloudflare Access
  ↓ service token / browser login
Cloudflare Worker
  ↓ mailbox tools
Company inboxes

This is where the business idea met the infrastructure reality.

The email tools were not the hardest part.

The hard part was making sure the agent had a controlled path into a real company communication system.

What actually broke

Several things had to line up before the agent could safely use the inbox.

Human access and machine access were different

The inbox UI worked in a browser before the MCP client worked from OpenClaw.

That matters because a human browser can complete login flows and challenges that a machine client cannot.

A browser passing Access does not prove the agent path works.

Access audience changed when the app was recreated

At one point the system returned:

Invalid or expired Access token

The token was not simply expired.

The Cloudflare Access app had been recreated, which changed the audience tag. The Worker was still validating against the old audience value.

That kind of failure is easy to misread if you only look at the surface error.

Cloudflare challenge blocked the machine client

The browser path worked, but machine requests to the MCP endpoint were still blocked by Cloudflare challenge behavior.

The response was not a JSON-RPC error.

It was a Cloudflare challenge page.

That meant the request had not reached the inbox tool layer at all.

Service token access needed its own policy

Human login and machine access needed separate policies.

The reliable shape was:

Human browser:
decision = allow
include = email

and:

Machine MCP client:
decision = non_identity
include = service token

Mixing service token access into a normal human allow policy created confusing behavior.

MCP had to be tested as MCP, not as a webpage

Opening /mcp in a browser gave a useful signal, but not a complete one.

A real test needed:

initialize
mcp-session-id
tools/list
tools/call

Only then could we say the agent path was alive.

The moment it became real

The system became real when the agent could do two things:

read from a real mailbox
send from a real company email address

That second step changes the category.

Before send works, the inbox is mostly a data source.

After send works, the agent has authority.

That is why we should be careful about calling this just “email integration.”

It is closer to delegated business operation.

What this taught us about agentic workflows

Agentic email is a useful preview of a broader shift.

AI agents are moving from answering questions to operating workflows.

That shift creates a new class of product and infrastructure questions:

How does an agent get access?
Who grants that access?
What can it do?
How is access scoped?
How is it revoked?
What actions require human approval?
How do we know what happened?

Those questions show up in email, but not only in email.

They also show up in:

browsers
dashboards
CRMs
support tools
admin panels
publishing workflows
internal operations systems

In every case, the same business question appears:

How do we let agents help without giving them uncontrolled authority?

That is the real problem.

A practical way to think about AI inbox operators

If you are considering agentic email, I would not start with:

How do we let AI send email?

I would start with:

What level of authority should this agent have?

A useful progression might look like this:

Level 1: Observe

The agent can read and summarize messages.

Level 2: Triage

The agent can classify, prioritize, and route messages.

Level 3: Draft

The agent can prepare replies, but humans approve them.

Level 4: Act with constraints

The agent can send in narrow, low-risk cases.

Level 5: Act autonomously

The agent can represent the company in broader contexts.

Most teams should not jump to level 5.

The interesting product work is in designing the transitions between these levels.

Why this category is worth watching

Agentic email is still early.

Many teams do not yet describe what they want as “an AI inbox operator.”

But they already feel the pain:

too many inbound messages
slow response times
missed opportunities
repeated context gathering
too much manual triage
not enough operational coverage

That is why the category matters.

Not because every inbox should be fully automated.

But because the inbox is one of the clearest places where agents can move from conversation into operation.

And when that happens, the hard questions are not only about model quality.

They are about trust, authority, and control.

Closing thought

The company inbox is not just where messages arrive.

It is where the outside world asks your company to do something.

That makes it a natural place for AI agents to help.

But it also makes it a place where permissions matter.

The most interesting version of agentic email is not an AI that writes nicer replies.

It is an AI operator that can understand inbound work, prepare the next action, and operate within clear boundaries.

That is the part worth building carefully.

Originally published on BrowserMan Blog.

We ran into this while working on BrowserMan workflows. The same pattern appears whenever agents need access to real authenticated environments: inboxes, browsers, dashboards, and internal tools. The business value comes from letting agents help with real work. The hard part is giving them scoped, revocable authority to do it safely.