DEV Community: Eli

Trust-sensitive agents need visible friction

Eli — Fri, 15 May 2026 11:10:43 +0000

Background workers are great until the agent is about to submit something under your name.

That is the line where automation changes character.

For low-risk work, the best interface is often no interface. Let the agent classify the lead, summarize the page, enrich the record, monitor the inbox, or draft the first pass. If the action is reversible, internal, and easy to inspect later, hiding the machinery is a feature.

But a different kind of workflow is arriving: agents that apply for jobs, publish content, issue refunds, update customer records, book travel, send replies, change dashboards, and operate logged-in web apps.

Those are not just browser tasks. They are trust-sensitive actions.

The product problem is not removing every bit of friction. It is deciding where friction belongs.

The browser is where authority lives

Agents want browsers because the browser is where work already happens.

APIs are incomplete. Internal tools are inconsistent. OAuth scopes are often too coarse. The real state of a workflow is usually scattered across tabs, forms, dashboards, inboxes, and account-specific UI.

A logged-in browser session can already do the thing. That is why it is useful. It is also why it is risky.

The useful browser bridge keeps auth and session state out of the prompt while still letting the agent work. That separation is the point: the agent gets a tool boundary, not a pasted credential bundle.

The boundary is not only “can it act?” It is also “what credentials does it silently inherit?”

Once an agent can use a real browser session, it is not just controlling pixels. It is borrowing authority: the user’s account, the company’s account, the brand’s account, the customer support account, the payment dashboard, the CMS, the CRM.

That is the part most demos skip.

The demo asks:

Can the agent click the button?

The production question is:

What should the agent have to prove before it clicks?

Background workers are not always the right shape

A useful signal came from a builder working on a job-application agent. They had built the normal backend shape: queue, workers, background tasks, submit pipeline. Then they ripped it out and kept the browser extension.

The reason was not that workers are bad. The reason was that job applications are trust-sensitive. Submitting under a person’s name needs a surface the user can see and interrupt.

That distinction generalizes.

A worker queue is great for:

collecting public information;
extracting structured data;
drafting content;
checking status;
classifying tickets;
preparing a recommendation.

A visible surface becomes important when the agent is about to:

submit a job application;
publish under a brand account;
send a customer reply;
process a refund;
update a CRM record;
pay, book, delete, or change account state.

The final mile matters because the action is no longer just computation. It changes the world under a real identity.

Ask what the agent can prove before it clicks

A smart pointer is not just a better cursor. It is a permission boundary.

Before an agent clicks, the product should be able to answer questions like:

Which account is this action using?
Which page, customer, order, or record is about to change?
Is this action reversible?
Is the dollar amount below the approval threshold?
Is this a draft, or is it about to be published?
Did the agent inspect the right evidence?
Is the user seeing the same final state the agent is acting on?

For browser agents, the click is often the last step in a chain of assumptions. The useful interface is not a giant approval modal for every action. It is a way to make the critical assumptions visible at the moment they matter.

A refund example makes this concrete.

If a support agent processes a $4,500 refund with no policy, no human in the loop, and no rule saying “anything over $500 needs approval,” the failure is not just model quality. The failure is the permission boundary.

The product allowed a high-blast-radius action to look like an ordinary tool call.

Approval gates should be thresholded, not everywhere

The wrong lesson is: make humans approve everything.

That turns an agent into a slow workflow UI. It also teaches users to click through approvals without thinking.

The better lesson is: place friction according to blast radius.

A practical policy model might separate actions by:

read vs write;
reversible vs irreversible;
internal-only vs customer-facing;
low-dollar vs high-dollar;
draft vs publish/send/submit;
ordinary path vs exception;
one record vs bulk action.

Most agent workflows need lanes, not one giant permission switch.

Read-only browser work can be broad. Drafting can be relatively free. Low-risk routine actions can be automated. But actions that spend money, affect customers, publish publicly, delete data, or submit under someone’s name should slow down.

The point is not to make agents timid. The point is to keep autonomy legible.

Completion is not the click

There is another quiet failure mode in business automation: false completion.

A refund clicked in Stripe is not necessarily finished. The customer may still need a note. Access may need to be removed. A duplicate refund check may still be pending. The CRM may need a record. The support thread may need a final reply.

The browser click can be successful while the workflow is incomplete.

That means receipts matter.

After the action, the agent should leave behind enough context for a human or another system to understand what happened:

what changed;
where it changed;
which evidence was used;
which policy allowed it;
whether follow-up tasks remain;
where to inspect or reverse the action if needed.

For trust-sensitive workflows, “the agent says it did it” is not a receipt.

A receipt is browser state, tool calls, before/after context, policy decisions, and artifacts that line up. It should be replayable enough that someone can reconstruct the action months later: which tool was called, on what input, under what authority, and what changed.

The BrowserMan angle: delegated browser authority

BrowserMan should not be framed as “an agent can click websites.” That is becoming table stakes.

The stronger frame is delegated browser authority.

A real Chrome session already contains trust. It has the cookies, tabs, login state, and messy context that make work possible. BrowserMan gives agents controlled access to that session while keeping cookies local and letting access be scoped, audited, approved, and revoked.

That means the important design questions are not only:

Can the agent navigate?
Can it click?
Can it type?

They are:

Which browser session can this agent use?
Which job is it allowed to perform?
Which actions need a visible pause?
What proof is required before the click?
What receipt exists after the action?
How does the user take access back?

The browser session is authority.

The future of browser agents is not just better clicking. It is better delegation.

Logs Are Too Late for High-Value Browser Actions

Eli — Thu, 14 May 2026 18:47:33 +0000

A browser agent that can read a support ticket is useful.

A browser agent that can refund $4,500 without approval is a production incident.

That distinction is where most browser-agent demos stop being demos and start becoming systems.

The click loop is getting good. Agents can open pages, read tables, fill forms, use tools, and drive real browsers. Some run in cloud browsers. Some run locally. Some are arriving as Chrome extensions with per-site permissions. The interface is improving quickly.

But production risk does not start at the click.

It starts when the click has write authority.

Refunding a customer, deleting a CRM record, publishing a post, exporting a list, changing account settings, sending a customer-facing email, charging a card — these are not the same kind of action as reading a dashboard. They cross the write boundary.

For high-value browser actions, logs are too late.

Logs explain. Gates prevent.

Receipts and audit logs are necessary. You need to know what the agent did, which page it touched, what it changed, what it saw, who approved it, and what happened before and after execution.

But a log after the fact is not a control point. It is evidence.

If a support agent processes a large refund and the human reads the log after the refund clears, the log did its job as a record. The system still failed as a control surface.

The useful distinction is simple:

Logs explain what happened.
Gates decide whether it should happen.

Browser agents need both, but they need them in the right order.

The write boundary is the product

Read-only actions can be broad. An agent can inspect an order, summarize a ticket, compare records, draft a response, or collect evidence from a logged-in dashboard with relatively low risk.

Write actions are different. They mutate the world.

A write action may:

refund money,
delete or update records,
publish public content,
send customer-facing messages,
change account configuration,
export private data,
trigger a workflow,
buy something,
submit a form that cannot be easily undone.

One wrong click in that category is not just a bad answer. It is operational damage.

That is why the product question is not only “can the agent use the browser?”

The better question is:

What is the agent allowed to do before a human sees the action?

A practical policy model

The simplest production pattern is broad read, narrow write.

Let the agent read and prepare. Let it gather evidence, draft changes, classify risk, and explain what it intends to do. Then put policy in front of the action.

A practical browser-agent policy can start with four rules:

Read-only by default. The agent can inspect pages, collect evidence, and prepare work without making irreversible changes.
Thresholds for high-value actions. Refunds over $500, account changes, exports, deletes, payments, and public publishes require approval.
Approval before execution. The gate sits before the click, not after the receipt.
Receipts after execution. Once approved and executed, the system records what happened, who approved it, and what changed.

This does not have to make the workflow slow. A good approval flow gives the human the context needed to decide quickly: what the agent wants to do, why, what rule triggered the gate, what page or record is affected, and what happens if the action is approved.

Approval is not just a safety brake. It is workflow infrastructure.

Denials should teach the boundary

A bad gate simply blocks the agent.

A good gate returns a structured denial.

For example:

{
  "allowed": false,
  "reason": "Refund amount exceeds approval threshold",
  "rule": "refunds_over_500_require_human_approval",
  "scope": "support_portal.refunds",
  "next_step": "request_approval"
}

That response gives the agent somewhere safe to go. It can ask for approval, switch to read-only mode, collect more evidence, or stop.

Without that feedback, agents learn the wrong lesson: the tool is broken, the page failed, or the action should be retried through another path.

Denied actions should teach the boundary.

Receipts need identity

Receipts also need to be stronger than plain text logs.

A useful receipt should answer:

Which agent or workflow requested the action?
Which browser session or account was used?
What page, record, or object was affected?
What did the agent see before acting?
What policy rule applied?
Who approved it, if approval was required?
What changed after execution?
Can the action be rolled back?

For enterprise workflows, receipts may also need tamper-evident identity. A log file that can be edited is not enough for serious audit requirements. The stronger version ties each action to actor identity, session context, approval state, and an execution record that can be reviewed later.

Still, receipts are not the gate.

They make the gate auditable.

Why real Chrome raises the stakes

This matters even more when the agent is operating through a real signed-in browser.

A real Chrome session can touch the same systems the human can touch: support inboxes, CMS tools, analytics, CRMs, admin panels, vendor portals, order systems, internal dashboards, and SaaS apps with no clean API.

That is exactly why real-browser access is useful.

It is also why raw autonomy is dangerous.

If the browser session is authority, delegated browser access needs a control model:

scope before execution,
gates during execution,
receipts after execution,
revoke when the workflow is done.

The point is not to hide the browser from the user or bypass the systems they already trust. The point is to make browser authority delegatable without making it silent.

BrowserMan’s position

BrowserMan is built around that model: controlled access to a user’s real Chrome session for AI agents.

The cookies stay local. The agent can run elsewhere. Access can be scoped. Risky actions can be gated. Execution can be logged and revoked.

That is the difference between “an agent can click around a website” and “an operator can trust an agent with a real workflow.”

The next phase of browser agents will not be won by the tool that clicks the fastest.

It will be won by the system that knows when not to click.

The Browser Agent Demo Is Not the Product. The Permission Model Is.

Eli — Wed, 13 May 2026 11:55:06 +0000

The browser-agent demo is easy to understand.

The agent opens a website. It clicks. It fills a form. It fixes a broken UI. It posts the thing. It looks like a human moving through software.

That is useful. It is also not the product.

The product begins when the browser is signed in.

A signed-in browser is not just a UI surface. It is authority: inboxes, CRMs, admin dashboards, billing pages, customer records, CMS tools, social accounts, support queues, internal portals, and all the half-integrated web software where real work still happens.

That is why browser agents are becoming valuable. Operators are drowning in logged-in tools, too many tabs, fragmented dashboards, and workflows that APIs do not cover cleanly.

It is also why the demo is incomplete.

Once an agent can touch a real browser session, the question is no longer only:

Can it use the browser?

The production question is:

What authority did we delegate, what was the agent allowed to do with it, and what receipt did it leave behind?

The browser-agent demo is not the product.

The permission model is.

A browser demo proves capability, not trust

A browser demo can prove that an agent understands a page.

It can show that the model can inspect the DOM, interpret a screenshot, click the right button, or recover from a small UI mismatch.

That is real progress. But in a logged-in workflow, capability is only the first layer.

A click inside a public demo page is harmless. A click inside a signed-in business tool may:

send an email,
update a CRM record,
approve a refund,
publish a page,
change a price,
merge a customer account,
submit a form,
spend money,
or expose private data.

Those are not the same action.

They should not share the same permission.

This is where browser-agent products need to stop treating “browser access” as one checkbox. Read-only inspection, drafting, internal edits, external sends, purchases, deletes, refunds, and public publishing are different risk classes.

The browser is one surface. The authority behind each action is not.

Signed-in browser access is delegated authority

The reason agents want the browser is simple: the browser already has the user’s working context.

Your logged-in Chrome knows which account is active. It has cookies, open sessions, local state, tabs, dashboards, and workflows that would take weeks to re-create through clean integrations.

That is why “use the browser I already use” is such a powerful primitive.

But it changes the trust model.

When an agent uses a fresh cloud browser, the product mostly controls the execution environment. When an agent uses the user’s real signed-in browser, the product is mediating delegated authority.

That distinction matters.

The useful primitive is not:

this agent can use a browser

It is:

this agent can use this session, for this job, on these surfaces, with these gates, while leaving these receipts, until I revoke it.

That is a product surface.

It includes scope. It includes approvals. It includes logs. It includes identity. It includes a revocation path.

Without that, a successful browser demo can quietly become an operational liability.

Blanket permission feels fast until the risk class changes

Blanket permission is attractive because it removes friction.

Nobody wants a modal before every harmless click. Nobody wants an agent that asks for approval every time it reads a page, opens a tab, or drafts a response.

The problem is not autonomy.

The problem is when the system cannot tell that the action changed class.

An agent reading a support ticket is one class. Drafting a reply is another. Sending the reply to a customer is another. Issuing a refund is another. Changing the refund policy in the admin panel is another.

Those transitions are where the permission model matters.

The alternative to blanket permission is not endless prompts. It is action-aware delegation:

let the agent inspect low-risk pages,
let it draft changes without submitting,
allow reversible internal updates inside a defined scope,
gate writes that notify people or change customer/account records,
require explicit approval for spend, delete, publish, refund, merge, or other high-impact actions,
revoke the session when the job is done.

That is how browser agents become usable without becoming reckless.

Completion needs receipts, not just clicks

A browser agent should not claim success because it clicked a button.

Clicked is not done.

The receipt is the state after the click: the saved record, the sent message, the published URL, the updated dashboard, the confirmation screen after reload, the audit trail, or the visible diff.

This matters because browser workflows are full of false positives.

A button can click and fail silently. A form can submit and then reject server-side validation. A page can update optimistically and roll back. A post can appear in a composer but never publish. A CRM record can save locally but not persist. A checkout can advance one step without completing.

If the browser agent is operating with real authority, the receipt has to prove more than motion.

It should answer:

What did the agent change?
Which session did it use?
Which task was it acting under?
Which approval boundary did it cross?
What evidence shows the final state?
Can a human inspect or replay enough context to trust the result?

This is why screenshots and traces are useful, but not always sufficient. A screenshot says what the browser showed. A workflow receipt should explain what changed, why it was allowed, and how the final state was verified.

Tool-call policy is not enough for browser authority

The agent tooling ecosystem is moving toward policy layers around tool calls: schemas, MCP gateways, approval steps, isolation, DLP checks, and host-defined rules.

That direction is right.

But browser actions are messier than normal tool calls.

A structured tool call can say:

{
  "tool": "refund_order",
  "args": {
    "order_id": "123",
    "amount": 42
  }
}

A browser action may only say:

click button

The meaning depends on the page, the session, the current account, the surrounding form, and the state of the workflow.

A click can mean “open details” or “delete customer.” A submit button can mean “save draft” or “publish publicly.” The same UI action can be harmless in one app and irreversible in another.

So browser permissioning needs to understand more than command syntax.

It needs to understand the authority boundary around the session and the risk tier of the action.

The useful model: scope before, gates during, receipts after

For browser agents, the control model should be simple enough to explain and strict enough to matter.

Scope before execution

Before the agent acts, define the job.

Which browser session is available? Which sites are in scope? Which tabs or workflows can it touch? Is it reading, drafting, updating, publishing, spending, or deleting?

The agent should not get “the browser.”

It should get a bounded delegation.

Gates during execution

During the run, the system should notice when the agent is about to cross a higher-risk boundary.

Reading a CRM page may be fine. Updating a field may need a log. Emailing the customer may need approval. Issuing a refund should probably need a stronger gate. Deleting the account should be outside the job entirely unless explicitly granted.

The point is not to interrupt every click.

The point is to put friction where authority changes.

Receipts after action

After the agent acts, it should leave evidence.

Not just “done.”

A useful receipt includes the action class, the delegated session or account context, the approval boundary, the final verified state, and enough audit trail for a human to inspect what happened.

This is how browser agents move from demos to operations.

Where BrowserMan fits

BrowserMan is built around a specific category bet:

the browser session is authority, and users should be able to delegate that authority carefully.

BrowserMan connects agents to a user’s real Chrome session. Cookies and credentials stay in the user’s browser. Agents can run elsewhere. Access can be scoped, audited, approved, and revoked.

That is different from simply launching another browser for the agent.

Cloud browser infrastructure is useful when the agent needs a reliable remote execution environment. Browser frameworks are useful when developers need better control primitives. Browser automation tools are useful when a task can be scripted end-to-end.

BrowserMan’s lane is delegated real-browser authority: the agent needs to work in the same logged-in web environment the user already uses, but the user should not have to hand over the whole house.

The practical promise is not “the agent can click.”

It is:

use the real Chrome session when that is where the work lives,
keep cookies local,
delegate a job instead of sharing credentials,
scope what the agent can touch,
gate risky actions,
log what happened,
revoke access when the job is over.

That is the permission model as the product.

The category will compete on trust, not just clicks

The browser-agent market is moving quickly.

Some products optimize cloud browser scale. Some optimize visual control. Some optimize local desktops. Some optimize persistent agent computers. Some optimize tool-call policy and runtime isolation.

All of that matters.

But once the agent touches a signed-in browser, the durable question becomes sharper:

Can I safely delegate the authority behind this browser session?

The winners will not only be the systems that click fastest.

They will be the systems that know when a click is just navigation, when it is a draft, when it is a write, when it is a public action, and when it should stop.

The demo gets the agent into the browser.

The permission model decides whether it belongs there.

Enterprise portals are where browser agents become workflows

Eli — Fri, 08 May 2026 09:10:38 +0000

Browser-agent demos are usually about the click.

The agent sees a page, reasons about it, presses a button, fills a form, and something happens. On a clean demo site, that is enough to feel like the future.

Enterprise portals are where the future gets less theatrical.

The page is dense. The table has hidden state. The session may be stale. The form may trigger a real customer update, refund, filing, inventory change, support reply, or vendor action. The agent is no longer just browsing. It is operating inside a logged-in account with consequences.

That is the point where browser agents stop being a demo and start becoming workflow infrastructure.

The demo is clicking. The workflow is everything around the click.

A browser agent that can navigate a website is useful. But the hard production questions live around the action:

Should the agent rediscover this flow every time?
Is the page read-only, or can it change business state?
Whose logged-in account is being used?
What is the agent allowed to touch?
Where should it stop for approval?
What proof remains after the work is done?
What happens if the portal drifts or the action fails halfway?

These questions matter most in the boring places: CRMs, support inboxes, CMS tools, admin dashboards, vendor portals, payment screens, and client portals.

They are also exactly where a lot of real work lives.

Stop rediscovering the same portal every time.

Screenshots and vision loops are good for unknown pages. They let an agent inspect a surface it has never seen before and choose a next step.

But repeated enterprise workflows should not be rediscovered from scratch every time.

If the agent runs the same portal task every week, the path should become a saved action or browser skill. That does not mean the workflow becomes brittle automation again. It means the agent does not pay the full reasoning and observation cost for every known step.

A useful browser layer should support both modes:

exploration when the page is new or has drifted;
saved actions when the path is known and repeated.

This is one reason BrowserMan ships prebuilt platform actions alongside general browser tools. The agent can still navigate, read, click, and type, but repeated operations should not require endless page exploration when a more reliable action exists.

A logged-in browser session is authority, not just context.

Cookies are not just state. They represent what a person or team can do.

When an agent uses a logged-in browser session, it inherits some of that authority. That makes the session different from a cloud browser profile, a public page scrape, or a throwaway headless runtime.

This is the distinction BrowserMan is built around:

the agent can run anywhere;
the user’s real Chrome session stays on the user’s device;
cookies and credentials stay inside the browser;
access is delegated instead of shared as a password;
access can be scoped, audited, approved, and revoked.

For authenticated workflows, the question is not only “can the agent use a browser?”

The better question is: what browser authority did the user delegate, and under what limits?

Separate risk classes.

Not every browser action deserves the same treatment.

Reading a dashboard is not the same as submitting a form. Drafting a customer reply is not the same as sending it. Looking up an order is not the same as issuing a refund. Opening a payment page is not the same as spending money.

A practical browser-agent system needs risk classes:

Read / observe — view a page, extract information, summarize state.
Draft / prepare — fill a form or compose a reply without submitting.
Low-risk internal update — change data that is reversible or contained.
External send / submit — send an email, post content, submit a form, trigger a workflow.
Delete / refund / spend / high-impact action — irreversible, financial, public, or customer-visible changes.

This is where generic “human approval” language gets too vague.

Approval for every click is unusable. Approval for nothing is reckless. The useful layer is policy: what class of action is this, what evidence is needed, and what should happen next?

Approval gates need UX, not just policy.

A gate can make a system safer and still make it unusable.

If an approval takes ten seconds of human attention and the agent asks twenty times in one session, the workflow is dead. The operator is not supervising the agent anymore. They are being interrupted by it.

Good approval design needs batching and evidence.

Instead of twenty tiny prompts, an agent should be able to say:

I found 18 records. I drafted 12 updates. Three are uncertain. Seven require external submission. Here is the diff. Approve the safe batch, review the uncertain batch, and block the risky one.

The policy modes are not binary:

deny by default for irreversible or high-risk actions without human availability;
queue work that can wait;
escalate urgent work to a human;
pre-approve bounded actions when the scope is narrow and the blast radius is small;
require receipts after state-changing actions.

That is where browser automation becomes operational software.

Receipts are the audit trail for browser work.

After an agent acts in a real browser session, the operator should not be left guessing.

A useful receipt answers:

which site and account were used;
what the agent saw;
what it changed;
what evidence supported the action;
who or what approved it;
what was submitted, sent, deleted, refunded, or purchased;
what happened on failure or retry.

For payment and spend flows, the minimum bar is even higher: vendor or endpoint, budget, signer or approver, receipt, and failure behavior.

A payment page is not another screen. It is a permission boundary.

Where BrowserMan fits.

BrowserMan is not trying to be the smartest browser agent or the largest cloud browser fleet.

It is the delegated real-browser authority layer.

The product is built for the moment when an agent needs to operate in the same web environment a person already uses, without turning that into password sharing or unlimited browser access.

That means:

real Chrome session;
agents can run anywhere;
cookies stay local;
scope before execution;
gates during execution;
receipts after;
revoke when done.

Enterprise portals are where browser demos go to become workflows.

The click loop is the easy part. The workflow layer is where the system proves whether it can be trusted.

Browser agents need authority-aware execution

Eli — Fri, 08 May 2026 03:56:26 +0000

Cloud agents are starting to make runtime handoff feel normal.

You can send an agent to a cloud VM. It can keep working after your laptop closes. It can have a shell, files, an IDE, a browser, and enough continuity to finish a long task without you babysitting the process.

That is a real improvement. But it exposes the next problem.

A cloud browser is not the same as your browser.

The moment the agent needs to operate inside a real logged-in account, the clean demo starts collecting sharp edges: SSO, 2FA, anti-bot checks, account-specific state, existing tabs, saved context, user consent, and audit expectations.

Copying cookies into the cloud is the wrong default. Re-authenticating every time is brittle. Giving the agent credentials is worse.

Desktop MCP solves one half of the problem

Desktop and browser MCP setups have the opposite strength. They can inherit the browser session you already have. The agent can work with the account state that exists on your machine instead of starting from a blank cloud browser.

That matters. The logged-in browser is often the workflow.

But local-only control creates its own constraint:

the user’s machine has to stay online;
the agent often has to run near the browser;
remote, mobile, chat-driven, or 24/7 agents hit a boundary;
long-running workflows become awkward when the browser and runtime are tied together.

Desktop MCP is powerful for local control. It is not the whole remote-agent story.

The missing shape is runtime separated from authority

The better architecture separates where the agent runs from whose browser authority it can use.

The agent runtime might live in Claude Code, Cursor, OpenClaw, n8n, a cron job, a cloud worker, or a chat interface.

The browser authority should remain in the user’s real Chrome session.

That distinction matters because the browser session is not just context. It is authority.

A signed-in browser can read private data, send messages, update CRM records, post publicly, submit forms, delete content, change settings, or spend money. Treating that as “just browser access” is too broad.

The question is not only:

Can the agent use a browser?

The better question is:

Can the agent use the right browser authority, from the right runtime, with the right permission boundary?

Account-aware is useful. Authority-aware is sharper.

There is a useful phrase emerging in browser automation: account-aware execution.

It means the script is not enough. The account profile, cookies, local storage, browser state, workflow state, review rules, and task logs are part of the runtime.

That is right for team browser automation.

For AI agents, the sharper version is authority-aware browser delegation.

The account is often not a synthetic profile in a fleet. It is a real human’s logged-in Chrome session. That makes the browser not only account context, but account authority.

A script needs the right account context.

An agent needs the right permission boundary.

Read-only and posting should not share the same permission

Browser work should be permissioned by action class.

Reading a page is different from drafting a reply. Drafting is different from clicking submit. Clicking submit is different from deleting content, changing billing, or modifying account settings.

A practical permission model should separate:

observe / read;
draft / prepare;
click / type / navigate;
submit / post / delete / spend;
admin or settings changes.

Read-only research and externally visible actions should not share the same permission.

This is especially obvious in social and support workflows. Letting an agent inspect a profile, summarize an inbox, or draft a response is useful. Letting it publish, refund, update an account, or message a customer needs a gate.

What a browser-handoff layer should provide

A real browser-handoff layer should do more than forward clicks.

It should provide:

Scope before execution — what can this agent touch?
Approval during execution — when does the user need to say yes?
Receipts after execution — what clicked, changed, or failed?
Revoke when done — how does the user remove access?
Cookie locality — are credentials and cookies staying in the browser, or being copied into the runtime?

This is the layer BrowserMan is built around: agents can run anywhere, while the signed-in browser stays on the user’s device. The agent receives delegated browser access, not credentials. Cookies stay local. Access can be scoped, attributed, approved, and revoked.

The boring workflows are where this gets valuable

The most useful browser agents are rarely the flashiest demos.

They are things like:

checking a support inbox;
drafting customer follow-up;
enriching CRM records;
publishing CMS updates;
looking up an order;
preparing a refund;
researching leads across logged-in tools;
updating admin SaaS dashboards.

These workflows need real account context. They also need boundaries.

That is why the category should move past “agents need browsers.”

Agents need browser authority they can safely borrow.

Cloud handoff solves where the agent runs.

Browser handoff solves whose account it can safely use.

The product gets real at that boundary.

Boring admin SaaS is where browser agents become real

Eli — Tue, 05 May 2026 13:52:08 +0000

Browser agents stop being demos when they enter boring logged-in admin SaaS.

Not the polished demo site. Not the one-off form fill. The real test is ZohoBooks, QuickBooks, Xero, CRM, inboxes, CMS dashboards, customer portals, and the other web apps operators already live in.

That is where the value is.

It is also where the risk starts.

A browser agent that can read a public website is using a browser as an interface. A browser agent that can use an operator's accounting SaaS is holding delegated authority. It may be able to see financial records, prepare invoices, update customer data, send messages, publish content, approve refunds, or click something that changes money.

That changes the product question.

The question is no longer only:

Can the agent use the browser?

It becomes:

Which browser authority did the agent receive, and what boundary stops it before the risky action?

The buyer workflow is not the flashy demo

Browser-agent demos often optimize for spectacle: open a site, click around, complete a task, show the UI moving.

That proves something technically useful. But it is not usually the buyer workflow.

The buyer workflow is more boring:

read invoices,
match them against vendor records,
categorize transactions,
flag duplicates,
review exports,
update CRM fields,
triage support messages,
prepare CMS changes,
check customer portals,
draft the next action.

The work that gets paid for is often the work nobody screenshots.

That pattern kept showing up in recent market scans. One builder was showing ZohoBooks automation through a browser-agent setup. Another account described a QuickBooks/vendor-invoice workflow: read invoices from email, categorize them, flag duplicates, and reduce how often the owner has to open QuickBooks. Another described a Quality of Earnings workflow around QuickBooks/Xero exports, category mapping, and anomaly flags.

The common thread is not “the agent opened a website.”

The common thread is repeated operational work inside logged-in SaaS.

The workflow is not “open QuickBooks”

A weak version of this category says: the agent can open QuickBooks.

A useful version says:

read the invoice,
compare it against vendor and customer context,
categorize it,
flag duplicates or anomalies,
prepare the entry,
stop before posting money or mutating the record unless the action is approved.

That last step matters.

The valuable part is not blind autonomy. The valuable part is reducing the repeated human work while preserving control over the actions that create side effects.

For many admin workflows, the right split is:

the agent reads, gathers, compares, drafts, and prepares;
a human or policy gate reviews the risky transition;
the system leaves a receipt of what happened.

That is less magical than “fully autonomous browser agent.”

It is also much closer to what serious operators will actually trust.

Logged-in SaaS turns browser access into authority

Fresh cloud browsers are useful. They are great for extraction, testing, browsing public pages, and running clean workflows at scale.

But many admin workflows need the exact environment the operator already uses:

the existing logged-in session,
OAuth/MFA already completed,
extensions and device context,
the same SaaS state the human sees,
the same permissions the operator has.

That is why real browser sessions keep appearing as a product primitive for agents.

But a real browser session is not just convenience. It is authority.

If an agent can use the same session, it may inherit the same practical power as the human sitting at the browser. In accounting, that may mean changing records or preparing payments. In CRM, it may mean editing customer data. In support, it may mean sending a reply. In CMS, it may mean publishing.

So the product cannot stop at browser control.

It needs delegation.

Three requirements for real admin-SaaS browser agents

1. Real session access

Many useful workflows depend on the user's actual browser context. Asking the agent to log in from a clean browser, copy cookies, or maintain a parallel profile often turns the workflow into authentication infrastructure.

The user already has a browser session that works. The question is how to delegate it without handing over the keys.

2. Separation of read/prepare from write/submit

The safest useful agent is often not the agent that clicks everything autonomously.

It is the agent that can do the boring work up to the boundary:

gather evidence,
prepare the record,
explain the proposed change,
stop before the action that changes money, customer data, or public state.

This boundary is where browser-agent products will earn trust.

3. Receipts

When an agent acts inside logged-in SaaS, teams need to know what happened.

A useful receipt answers:

what did the agent inspect?
what did it prepare?
what did it change?
who or what approved the change?
how can access be revoked?

Without receipts, approval becomes theater. With receipts, delegation becomes operational.

Browser agents get serious in boring software

The future of browser agents may look less like an impressive one-shot demo and more like:

invoice cleanup,
QOE review prep,
CRM updates,
lead research,
support inbox triage,
CMS checks,
admin portal reconciliation.

Boring enough to pay for. Risky enough to need a boundary.

That is the lane BrowserMan is built around: delegated browser access for AI agents. The user's real Chrome stays local. Cookies stay in the browser. Agents can run elsewhere. Access can be scoped, gated, audited, and revoked.

Because once browser agents enter logged-in admin SaaS, the product is no longer just navigation.

It is delegated authority.

Existing Chrome profiles are becoming a product primitive for agents

Eli — Mon, 04 May 2026 21:19:18 +0000

AI agents are getting better at planning, calling tools, and running longer workflows.

But the boring part keeps winning: the agent still has to log in.

That is where browser-agent work often collapses into infrastructure. Fresh browser contexts fight OAuth. Copied cookies rot. Separate Chrome profiles need sync scripts and refresh jobs. Local-only browser bridges work until the agent has to run somewhere else. Longer agent tasks make the browser-auth tax more visible, not less.

The market is converging on the same primitive: use the real Chrome profile or browser session that already has identity, state, extensions, and permissions.

That is the right direction. But it is only half the product.

An existing Chrome profile is not just a convenience layer. It is authority. If an agent can use it, the agent can often read private data, mutate customer records, send messages, publish posts, approve refunds, or click checkout.

The real product question is no longer:

Can the agent open a browser?

It is:

Which browser authority did the agent receive, and what boundary stops it before the risky action?

The browser-auth tax is becoming visible

For simple demos, authentication looks like a setup step. Log in once, save state, run the flow.

For real workflows, authentication becomes an ongoing tax:

OAuth breaks in automated or fresh-browser contexts.
Copied cookies expire or get rejected.
Separate profiles need cron jobs, launch agents, and refresh cycles.
Long-running automations hit reconnect and profile ownership problems.
Multiple agents or jobs can fight over the same profile.

One operator described spending a day wiring a separate Chrome profile, cookie access, a launchd service, a sync script, and a six-hour refresh cycle so an agent could stay logged in. Another described trying to give an agent the existing Chrome profile after several headless/local approaches failed. Another debugged an agent repeatedly killing Chrome because a forgotten background job shared the same browser profile.

None of that is model intelligence. It is browser-auth infrastructure.

The model can plan for an hour. The workflow still dies if the browser session, profile, and approval boundary are duct-taped together.

Why agents collapse back to the existing Chrome profile

The existing Chrome profile works because it already contains the things web apps use to recognize a real user:

cookies and session state,
OAuth/MFA completion,
extensions,
device and enterprise context,
user preferences,
the exact app state the human already uses.

That is why “use my actual browser” keeps showing up as a product request. It is also why “just copy the cookies” is an uncomfortable answer.

A browser profile is not a loose credential bundle. It is a live authority surface.

If the agent gets the same browser profile, it may inherit the same app permissions as the user. That can be useful for logged-in workflows like support, CRM, CMS, lead research, admin portals, or checkout. It also means the product has to answer ownership questions:

Which agent, job, or human is allowed to use this profile right now?
Can multiple automations touch it at once?
Which actions are read-only?
Which actions require review?
What receipt proves what happened?

The existing Chrome profile solves auth, but it creates a new product problem: delegation.

Three lanes are emerging

There are at least three browser-agent infrastructure lanes forming.

1. Cloud browser infrastructure

Cloud browsers are useful for scale, clean environments, testing, extraction, crawling, and controlled remote execution.

They are often the right answer when the workflow does not need the user's actual signed-in browser state.

But many operator workflows are not just “open a browser.” They require the specific browser session where the user is already logged in and authorized.

2. Local or browser-resident agents

Local browser agents and Chrome-extension agents solve a different problem: the agent lives with the browser.

That can be excellent for privacy, current tabs, browser history, local page context, and direct UI access. It also keeps the agent and browser tightly coupled to one environment.

This lane answers:

What if the agent lives inside my browser?

3. Delegated real-browser access

The delegated-access lane answers a different question:

What if my agent lives somewhere else, but needs my real browser session without copying the keys?

This is BrowserMan's lane.

The user's real Chrome stays local. Cookies and credentials stay in the browser. The agent can run elsewhere. Access is treated as something delegated, scoped, audited, approved, and revoked — not as a cookie jar to export or a headless browser pretending to be the user.

Local browser agents solve “the agent lives in my browser.” Delegated browser access solves “my agent lives somewhere else, but needs my real browser session without copying the keys.”

The wrong abstraction is “browser access.” The useful abstraction is “which session authority is being delegated?”

The browser is the execution boundary

For browser agents, the browser is not just an input/output device.

It is the execution boundary where identity, UI, session authority, and side effects meet.

The UI matters because it encodes what the user can see, click, confirm, undo, and recover from. A web app's interface is often where permission stops being theoretical. The app shows the record. It labels the action. It asks for confirmation. It exposes the difference between viewing an order, drafting a refund, and submitting the refund.

If an agent bypasses or guesses around that boundary, the system loses important context.

This is why browser agents should not be evaluated only on whether they can click through the flow. The product has to understand the risk level of the action:

Action class	Example	Default boundary
Read-only lookup	Check order status	Usually allow within scope
Reversible update	Add CRM note	Log and sample-review
Draft	Draft email/refund/social post	Human review before send
External side effect	Send email, publish, refund, checkout	Explicit approval
Irreversible/high-risk	Delete, spend, price change, account action	Strong approval + receipt

The useful browser agent is usually boring: check the order, update the CRM, draft the refund, stop before submit unless the rules say yes.

Approval is not always friction

Some agent products pitch “no approval queue” as the value.

Sometimes that is right. Read-only data collection, private drafts, or low-risk internal automation should not force a human to approve every tiny step.

But once an agent can publish, email, refund, buy, delete, or modify a customer record, the approval queue is not bureaucracy. It is the trust boundary.

“No approval queue” sounds fast until the agent can publish, refund, email, or delete.

The key is not to require approval everywhere. The key is to attach approval to action risk.

A good approval surface should not simply ask:

Allow?

It should answer:

What changed?
Which account/session/merchant/customer is involved?
What authority will be used?
What will happen next?
Can this action be undone?

If the human has to re-run the entire workflow mentally before approving, the product has not built an approval layer. It has only paused the agent.

Side effects need receipts

Approval is the gate before the side effect. A receipt is the proof after it.

Browser agents need both.

Once an agent can trigger checkout, publish a post, send an email, approve a refund, or mutate a customer record, a chat summary is not enough. The receipt should be outside the agent's own narration.

The receipt might include:

who requested the action,
which browser/session authority was delegated,
the policy or approval state at the time,
the app/merchant/customer context,
what changed,
the resulting URL, record ID, invoice, or confirmation,
a timestamp,
whether the action was reversible.

This is the difference between “the agent says it posted” and “here is the post URL.” It is the difference between “the refund probably went through” and “here is the refund ID and customer record diff.”

Checkout is a useful stress test because the agent is not only choosing an item. It is crossing from recommendation into execution. A serious checkout flow should show the spend scope, the approval checkpoint, retries and failure handling, the merchant context, the invoice or confirmation state, and whether the action can be cancelled or reversed.

If the first audit log is a stranger replying “you posted this,” the agent did not have autonomy. It had unattended authority.

What BrowserMan changes

BrowserMan exists for the delegated-access case.

The agent does not need your password, a copied cookie jar, or a headless browser pretending to be you. It gets controlled access to your real signed-in Chrome session, with the browser session kept local and the authority treated as something you delegate, observe, and revoke.

That distinction matters because authenticated browser work is not just about solving login. It is about preserving the boundary where real web authority lives.

The browser session already has identity. The UI already represents what the user can see and do. The app already asks for confirmation at important moments. BrowserMan's job is to make that real browser session available to agents without turning it into loose, portable power.

The category is still young. Cloud browsers, local browser agents, local bridges, and delegated real-browser access will all be useful. But for the workflows where the user says, “I need the agent to use the browser I already trust,” the product primitive is clear:

Use the existing session. Delegate it deliberately. Put boundaries around risky actions. Leave receipts.

That is how browser agents move from demos to production work.

Delegated browser access vs cookie sync: the browser session is authority

Eli — Sun, 03 May 2026 13:58:05 +0000

For browser agents, the hard part is no longer just giving the model a logged-in browser.

That part is getting solved from several directions. Cloud browser platforms can run managed browsers. Local browser tools can attach to a user’s existing Chrome profile. Agentic browsers can isolate the agent in a clean profile. Cookie-sync experiments can move authenticated state into a remote runtime.

All of that is useful.

But the production question is not only:

Can the agent use a logged-in session?

The better question is:

Where does browser-session authority live, how is it delegated, and what identity, policy, isolation, and audit trail follow the agent?

A logged-in browser is not just state. It is authority.

It can contain your inbox, CRM, support queue, billing portal, admin dashboard, SaaS console, ad account, CMS, private docs, customer records, social accounts, and internal tools. That is why agents want browser access. It is also why the permission model matters.

Once an agent can use a real browser session, “browser access” stops being a convenience feature. It becomes a delegation model.

There are at least four different models emerging.

1. Cloud browser plus cookie sync

The first model is the most infrastructure-friendly:

Run the browser in the cloud, then move or copy enough session material into that browser so the agent can act as an authenticated user.

This is appealing for obvious reasons. Cloud browsers are easy to schedule, scale, observe, reset, and integrate into server-side agent systems. They do not depend on the user’s laptop being online. They can be provisioned like infrastructure.

Cookie sync adds the missing piece: authenticated state.

Instead of asking the user to log into a fresh remote browser, the system can copy cookies or session state from the user’s local browser into a remote browser. The agent gets the convenience of a managed runtime with the usefulness of a logged-in session.

That is powerful.

It also changes the trust boundary.

If the cookie jar is exported, copied, or synced into a remote runtime, the security and revocation story becomes about how that session material is moved, stored, scoped, expired, and destroyed.

This model solves remote execution by exporting the jar.

That may be a good tradeoff for some workflows. If the goal is high-scale cloud automation, a managed remote browser may be exactly right. But it is not the same as keeping the user’s credentials and cookies inside the browser they already use.

The key question is not whether the agent can act. It can.

The key question is what had to move to make that possible.

2. Isolated agent browser or profile

The second model goes in the opposite direction:

Put the agent in a separate browser profile so it cannot touch the user’s main cookies, logins, or browsing data.

This is a strong security default.

Agentic browsing has a prompt-injection problem. A page can contain instructions. The agent can misread them as task instructions. If that agent has access to the user’s real logged-in profile, the blast radius can be large.

A clean or isolated profile limits that blast radius. The agent gets a browser, but not the user’s main browser. It can browse, search, test flows, fill public forms, read pages, or perform low-auth tasks without inheriting the user’s entire web authority.

That is useful and often correct.

But isolation has a tradeoff: it removes the very state that makes many work tasks valuable.

A separate browser profile is safer because it is not logged into everything. But if the workflow requires the user’s actual SaaS dashboard, support inbox, ad account, internal tool, or customer portal, then the isolated profile still needs one of the other routes: a fresh login, an API, OAuth, cookie sync, or a controlled way to borrow the real session.

So isolated profiles protect cookies. They do not automatically provide delegated access to the user’s real work surface.

This distinction matters because “safe browser agent” and “use my actual logged-in workflow” are often in tension. A clean profile is good when isolation is the goal. It is less useful when continuity with the user’s real browser state is the goal.

3. Local attach to existing Chrome

The third model says:

Do not create a separate browser. Attach to the browser the user already has.

This solves the login problem cleanly.

The user is already logged into X, Gmail, Vercel, GitHub, Salesforce, Stripe, Notion, Linear, Intercom, Shopify, or whatever else they use. The agent does not need a separate login flow. It can operate in the same browser state the user already trusts.

For local developer workflows, this is extremely attractive.

It can also preserve a lot of context that cloud or isolated browsers do not have: existing tabs, extensions, cookies, permissions, session history, and the messy state of real work.

But existing Chrome attach is not the same thing as delegation.

It solves access. It may not solve boundaries.

If the agent runs on the same machine and gets broad control over the user’s active browser profile, the trust model is often coarse. The user has granted local control, and now the question becomes: which tabs, sites, actions, files, tools, and workflows are actually in scope?

Local execution is also not magic security. A browser agent may run locally, but the sites it acts on do not. Every logged-in action still sends requests to external services with the user’s session authority.

Existing Chrome attach solves login.

It does not automatically solve delegation.

4. Delegated real-browser access

The fourth model is the one BrowserMan is built around:

Let the agent run anywhere, but delegate access to the user’s real Chrome session while cookies and credentials stay in the browser.

The agent does not need the user’s password. It does not need the cookie jar exported into a cloud browser. It does not have to run on the same machine as the browser.

Instead, the user’s browser stays local. The agent receives controlled browser access through a relay and extension. Commands move through the system; the browser session remains the authority source.

This model is trying to solve a different problem from pure cloud browser infrastructure, isolated profiles, or local attach.

The problem is not:

How do I give an agent any browser?

The problem is:

How do I let an agent use my real browser authority without handing over credentials or exporting the session?

That requires explicit delegation.

The useful primitives are scope, gates, audit, approval, and revoke:

which browser is available;
which sites or tabs are in scope;
which task the agent is supposed to perform;
which actions are safe to take automatically;
which actions need human approval;
what gets recorded as a receipt;
how access can be revoked quickly.

This is why “browser session” is the wrong abstraction by itself.

The better abstraction is controlled browser authority.

The comparison is really about authority models

These four patterns are not just implementation choices. They are authority models.

Question	Cloud browser + cookie sync	Isolated browser/profile	Local attach / existing Chrome	Delegated real-browser access
Uses real logged-in state?	Yes, via copied/imported cookies	No, unless separately logged in	Yes, current browser/profile	Yes, current browser/session
Agent can run elsewhere?	Yes	Usually local or managed runtime	Usually local / setup-dependent	Yes
Cookies stay in the user’s browser?	No, not if synced/exported	Main cookies stay protected because they are absent	Yes	Yes
Main safety primitive	Managed remote runtime	Isolation	Local trust / process boundary	Explicit delegation
Delegation is explicit?	Depends on product	Limited by isolated profile	Often coarse	Core product primitive
Revocation model	Revoke cloud session/token	Delete or stop isolated profile	Stop local process/access	Revoke delegated access
Best for	Scalable remote browser automation	Safe low-auth browsing and blast-radius reduction	Local developer workflows and private tasks	Controlled use of a user’s real browser authority

None of these models is universally best.

Cloud browsers are excellent when the agent needs managed infrastructure and scale.

Isolated profiles are excellent when the priority is protecting the user’s main browser from prompt injection and broad access.

Local attach is excellent when the developer wants the agent to use their current machine and browser state directly.

Delegated real-browser access is useful when an agent running elsewhere needs controlled access to the user’s actual logged-in browser, without exporting cookies or sharing credentials.

The right choice depends on what kind of authority the workflow needs.

The missing enterprise axis: identity and isolation

There is another layer beyond the browser session itself.

As soon as multiple agents enter the picture, the question becomes:

Which agent acted, under whose authority, with what policy, and inside what isolation boundary?

This is where agent identity, policy, and audit logs become more important than model capability.

A company may not want one generic “AI agent” with broad browser access. It may want six agents, each with its own browser window, file scope, tool access, task boundary, and audit trail.

The sales agent should not inherit the finance agent’s authority. The support agent should not be able to publish marketing pages. The research agent should not be able to issue refunds. A vendor’s agent should not get permanent access to the founder’s browser profile.

This is not science fiction governance. It is basic operational hygiene.

The agent needs a policy. The policy needs a scope. The scope needs an audit trail. The audit trail needs to trace back to a human or organization that intentionally delegated the authority.

Without that, agents carry credentials but not identity.

And credentials without identity are hard to govern.

Questions to ask before choosing a browser access model

Before giving an agent browser access, ask:

Does the agent need a real existing login, or can it use a clean browser?
Is the goal isolation from the user’s main profile, or controlled access to that real profile?
Does the agent need to run in the cloud or from another machine?
Are cookies exported, copied, synced, or kept inside the user’s browser?
Which identity or policy is the agent acting under?
Are multiple agents isolated by browser profile, browser window, file scope, and tool access?
Can access be scoped by site, tab, task, or action class?
Are high-risk actions gated before execution?
Is there a receipt of what changed?
Can the user revoke the delegation quickly?

The browser itself is only one part of the answer.

The authority model is the product.

Where BrowserMan fits

BrowserMan should not pretend every workflow needs delegated local Chrome.

Some agents should use cloud browsers. Some should use isolated profiles. Some should attach locally during development. Some should use APIs or MCP servers instead of a browser at all.

BrowserMan’s lane is narrower and more specific:

an agent running anywhere, using the user’s real browser authority, without exporting cookies or sharing credentials.

The user’s signed-in Chrome stays local. Cookies and credentials stay in the browser. Access can be scoped, audited, approved, and revoked.

That is the distinction.

Browser agents do not just need sessions.

They need a permission model for sessions.

And once the browser session becomes authority, the product category is how safely that authority is delegated.

Use GitHub Gists as an AI Agent Skill Registry with gh skill

Eli — Sat, 02 May 2026 03:52:18 +0000

AI agent skills are becoming a useful packaging format.

A good skill is not just a prompt. It is a small folder that usually contains:

a SKILL.md instruction file;
scripts;
examples;
docs;
repeatable commands;
tool-specific setup notes.

That makes skills useful for real agent workflows. But it also creates a distribution problem.

Where should a skill live?

How should a user install it?

How does the same skill reach OpenClaw, Hermes, Claude Code, Codex, Cursor, OpenCode, or other agent runtimes?

One interesting answer is gh skill, a GitHub CLI extension by Nicholas Spencer.

Repo:

https://github.com/nicholasspencer/gh-skill

The idea is simple:

Use GitHub Gists as a lightweight registry for AI agent skills.

A Gist already supports multiple files, version history, forks, stars, and GitHub API access. gh skill adds a convention on top so a Gist can behave like a skill package.

This guide shows how to understand it, install it, and use it safely with an OpenClaw or Hermes agent.

Who this is for

This is for:

skill authors who want a simple way to publish skills;
agent builders who want to share skills across tools;
OpenClaw or Hermes users who want reusable agent workflows;
teams that want skills to be installable, inspectable, and versioned;
operators who want their AI agent to reuse practical workflows instead of rewriting prompts every time.

The job to be done is clear:

publish or install an AI agent skill in a way that is easy for both humans and agents to inspect

What `gh skill` does

According to the project README, gh skill is a GitHub CLI extension for managing AI agent skills as GitHub Gists.

The main commands are:

gh skill add https://gist.github.com/user/abc123
gh skill publish ./my-skill
gh skill search "git automation"

It is designed around a simple convention:

a skill is a Gist with a SKILL.md file;
subdirectories are flattened when stored in Gist files;
install expands files back into a folder;
the extension links skills into detected agent tool directories;
unknown authors go through a trust gate before install.

That last point matters.

Skills may contain instructions and scripts. They should be reviewed before an agent uses them.

Step 1: Install GitHub CLI

gh skill is a GitHub CLI extension, so you need gh first.

Check whether it is installed:

gh --version

If it is not installed, follow GitHub's official install guide:

https://cli.github.com/

You will also need GitHub authentication for commands that access your account, create Gists, or publish skills:

gh auth login

For read-only exploration, you may be able to inspect the repo without publishing anything. For real publishing, assume authentication is required.

Step 2: Install the extension

Install gh skill:

gh extension install nicholasspencer/gh-skill

Then check help:

gh skill --help

If the command is available, you should see help for publishing, installing, or searching skills.

If installation fails, check:

whether gh is authenticated;
whether your GitHub CLI can install extensions;
whether your network can reach GitHub;
whether the extension repo is accessible.

Step 3: Understand the skill folder format

A minimal skill folder might look like this:

my-skill/
  SKILL.md
  scripts/
    run.sh
  examples/
    input.md

The important file is SKILL.md.

A simple SKILL.md might look like:

---
name: weekly-competitor-check
description: "Check a fixed list of competitor pages and produce a cited weekly report."
---

# Weekly Competitor Check

Use this skill when the user wants a repeatable competitor monitoring workflow.

## Workflow

1. Read `competitors.md`.
2. Visit each public URL.
3. Compare with the previous report.
4. Summarize meaningful changes.
5. Cite every source.
6. Do not contact anyone or create accounts without approval.

## Output

Write a dated report with:
- executive summary;
- source list;
- changes;
- confidence labels;
- recommended follow-up.

That is enough to express a reusable agent workflow.

It is much better than leaving the workflow as a one-off prompt in chat history.

Step 4: Publish a skill

From the folder that contains your skill:

gh skill publish ./my-skill

Expected behavior:

the extension packages the skill folder;
creates or updates a GitHub Gist;
stores SKILL.md and related files;
returns a Gist URL you can share.

The exact output depends on the extension version and your GitHub authentication state.

A good result should give you a URL like:

https://gist.github.com/your-user/abc123

That URL becomes the install target.

Step 5: Install a skill from a Gist

To install a skill:

gh skill add https://gist.github.com/user/abc123

Before using it, inspect what was installed.

Ask your agent:

Please inspect the installed skill before using it.

Summarize:
1. what the skill does;
2. what files were installed;
3. whether it includes scripts;
4. what permissions or external services it may use;
5. whether it is safe to run as-is.

Do not execute scripts until I approve.

This is the right default posture.

Skills are powerful because they can include operational instructions. That also means they deserve review.

Step 6: Use it with OpenClaw or Hermes

Once installed, the skill should be available to your agent runtime or linked into a detected skill directory.

For OpenClaw or Hermes, the practical workflow is:

install skill → inspect SKILL.md → run a small first task → save output → refine workflow

Example user message:

Use the weekly competitor check skill.

First, inspect the skill instructions.
Then create a `competitors.md` template for me.
Do not browse anything yet.
Do not contact anyone.
After I approve the competitor list, run the first report.

This keeps the agent staged and controllable.

Step 7: Use ClawMama if you want a ready-to-use agent

If you already run OpenClaw or Hermes, use your existing environment.

If you want to try the workflow without maintaining an agent runtime first, create a ClawMama agent:

https://t.me/clawmamarun_bot

ClawMama gives you a managed OpenClaw or Hermes agent. New users get $2 of AI credits and access to the latest ChatGPT model, so you can test a skill workflow before setting up infrastructure.

A good first message is:

I want to try a GitHub Gist-based AI skill workflow with `gh skill`.

Please:
1. check whether GitHub CLI is available;
2. explain what `gh skill` does;
3. install the extension only after asking me;
4. inspect any installed skill before running it;
5. do not execute scripts, publish Gists, or change external accounts without approval.

That gives the agent a clear permission boundary.

What to use this for

Good skill candidates are repeatable workflows, not vague prompts.

Examples:

weekly competitor watch;
sales call follow-up formatting;
customer feedback tagging;
release note drafting;
GitHub issue triage;
local Stripe emulator testing;
browser QA checklist;
support inbox routing;
docs consistency checks.

The best skills have:

a narrow job;
clear inputs;
clear outputs;
safety rules;
installable examples;
minimal first-run path.

Safety notes

Treat skills like small software packages.

Before running a skill:

read SKILL.md;
inspect scripts;
check who authored it;
check whether it touches external APIs;
check whether it needs credentials;
prefer read-only or limited-scope tokens;
require approval before sends, purchases, deletes, deployments, or account changes;
keep logs of what the agent did.

This is especially important when a skill can operate GitHub, Stripe, Cloudflare, email, CRM, or browser sessions.

A useful rule:

The agent may inspect and draft by default.
The agent needs approval before external side effects.

Why this matters

The interesting part of gh skill is not only the CLI command.

It is the distribution model.

If skills are just local folders, they are hard to share.

If skills are packaged as Gists, they become:

linkable;
inspectable;
forkable;
versioned;
scriptable;
easy for agents to install.

That helps skill authors reach users across multiple agent tools.

It also helps agent users build a library of repeatable workflows instead of relying on chat history.

Final takeaway

gh skill points to a useful direction for agent tooling:

skills should be small, inspectable, versioned, and easy for agents to install

For OpenClaw and Hermes users, that means workflows can become reusable capabilities.

For ClawMama users, it means a ready-to-use agent can test a skill quickly, with human approval around anything risky.

Start small:

gh extension install nicholasspencer/gh-skill
gh skill --help
gh skill search "git automation"

Then inspect before you run.

Test Stripe Checkout with an AI Agent Skill — No Stripe Account Needed

Eli — Fri, 01 May 2026 05:05:42 +0000

Vercel Labs released a useful agent skill for anyone building payments: a Stripe Emulator skill.

The skill lets an AI agent test Stripe-like payment flows locally. It can create customers, products, prices, checkout sessions, payment intents, charges, payment methods, customer sessions, and webhooks without touching a real Stripe account.

That is exactly the kind of skill that should be easy to try.

This guide shows how to install Vercel Labs' Stripe Emulator skill in an OpenClaw or Hermes agent, run a first local Stripe test, and use ClawMama if you do not already have an agent runtime.

No real Stripe account is required.

No real Stripe secret key is required.

No real payment is processed.

Who this is for

This guide is for:

founders testing a checkout flow before setting up production payments;
developers who want a local Stripe-like API for app development;
AI agent builders who want a safe payment-testing workflow;
product teams that want agents to test checkout, customers, products, prices, and webhooks;
skill authors who want users to try a GitHub-hosted agent skill quickly.

The job is simple:

Let an AI agent test a Stripe checkout workflow locally before real payment credentials enter the system.

That is a good first workflow because the risk boundary is clear. The agent works against an emulator, not your production payment account.

The skill

Skill / repo:

vercel-labs/emulate

Install command:

npx skills add vercel-labs/emulate --skill stripe

For OpenClaw, use:

npx skills add vercel-labs/emulate --skill stripe --agent openclaw -y --copy

What it gives your agent:

a local Stripe emulator;
a fake test key pattern such as sk_test_emulated;
realistic Stripe-like API responses;
local customers, products, prices, checkout sessions, payment intents, charges, and webhooks;
a hosted checkout UI for local testing.

The point is not to replace Stripe.

The point is to let an agent test payment logic before the workflow touches real money.

Step 1: Create a ready-to-use agent

If you already run OpenClaw or Hermes, use your existing agent.

If you do not, create one with ClawMama:

https://t.me/clawmamarun_bot

ClawMama gives you a ready-to-use OpenClaw or Hermes agent. New users get $2 of AI credits, access to the latest ChatGPT model, and a simple Telegram control surface, so you can test a skill before maintaining your own infrastructure.

Think of it as creating a small agent workspace first, then giving that agent a specific skill.

In ClawMama language, you create a small lobster — a focused agent that can receive a task, install a skill, run a local workflow, and report back.

Step 2: Ask the agent to install the Stripe Emulator skill

Send this to your OpenClaw or Hermes agent:

I want to test Stripe checkout locally with Vercel Labs' Stripe Emulator skill.

Please install this skill:

npx skills add vercel-labs/emulate --skill stripe --agent openclaw -y --copy

After installing it, read the installed SKILL.md and summarize:
1. what the skill can do;
2. how to start the emulator;
3. what fake key to use;
4. which API endpoints are available;
5. any risks or setup notes.

Do not use any real Stripe API key.
Do not connect to a real Stripe account.

A good agent should first inspect the skill instructions.

That matters. Skills run with agent permissions, so the agent should understand what it installed before it uses it.

Step 3: Start the local Stripe emulator

The verified start command is:

npx emulate --service stripe

The emulator starts on:

http://localhost:4000

A typical startup output looks like:

emulate v0.5.0

  stripe  http://localhost:4000

  Tokens
  test_token_admin -> admin

  Config: defaults (run emulate init to customize)

The first run may install the emulate package from npm:

npm warn exec The following package was not found and will be installed: emulate@0.5.0

That is expected for a local development tool.

Step 4: Create a test customer

Ask the agent to run a local request:

curl -X POST http://localhost:4000/v1/customers \
  -H "Authorization: Bearer sk_test_emulated" \
  -d "email=user@example.com" \
  -d "name=Jane Doe"

Expected result:

{
  "id": "cus_Mpfm8dXJTRWa1o6e",
  "object": "customer",
  "email": "user@example.com",
  "name": "Jane Doe",
  "description": null,
  "metadata": {},
  "livemode": false
}

The exact customer ID will be different.

The important field is:

"livemode": false

That tells you this is not a real Stripe live transaction.

Step 5: List customers

Now ask the agent to list customers:

curl http://localhost:4000/v1/customers \
  -H "Authorization: Bearer sk_test_emulated"

The agent should return a Stripe-like list response.

This gives you a simple first loop:

create customer → list customers → inspect response

That is enough to prove the emulator is running.

Step 6: Create a product

Next, test product creation:

curl -X POST http://localhost:4000/v1/products \
  -H "Authorization: Bearer sk_test_emulated" \
  -d "name=Widget" \
  -d "description=A useful widget"

Expected result:

{
  "id": "prod_6ftApyNURynBJZGu",
  "object": "product",
  "name": "Widget",
  "description": "A useful widget",
  "active": true,
  "metadata": {},
  "livemode": false
}

Again, the exact ID will differ.

The useful part is that your agent can now test payment-related app behavior against a local API.

Step 7: Use it inside an app

If your app uses the Stripe Node SDK, there is one important detail.

The Stripe SDK does not automatically read an emulator base URL from an environment variable. You need to point the client at the local emulator when constructing it:

import Stripe from 'stripe'

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
  apiVersion: '2024-12-18.acacia',
  host: 'localhost',
  port: 4000,
  protocol: 'http',
})

Use a fake key:

STRIPE_SECRET_KEY=sk_test_emulated

This key is not from your real Stripe dashboard. It is a local test value for the emulator.

Step 8: Ask the agent to test a checkout flow

Once the emulator is running, give your agent a task like this:

Using the local Stripe emulator at http://localhost:4000, help me test a basic checkout flow.

Use the fake key:
sk_test_emulated

Please:
1. create a customer;
2. create a product named "Starter Plan";
3. create a price for $19/month if the emulator supports recurring prices;
4. create a checkout session if supported;
5. show the local checkout URL or API response;
6. summarize what worked and what failed.

Do not use real Stripe credentials.
Do not call api.stripe.com.
Do not process a real payment.

This is the workflow that makes the skill useful.

The agent is not just reading documentation. It is using the skill to test a real development path.

Step 9: Add webhook testing

The Stripe Emulator skill also supports webhooks.

A good next task is:

Help me test a local Stripe webhook handler with the emulator.

First, explain the webhook events this emulator can send.
Then create a minimal local webhook endpoint example.
Then show how to configure the emulator to send events to it.

Keep everything local.
Use fake keys only.

This is especially useful for app teams.

Webhook testing is one of the places where payment development becomes slow. A local emulator gives your agent a safe target to exercise the flow.

What the agent should produce

A useful result from the agent should include:

install confirmation;
emulator startup command;
local endpoint URL;
fake key used;
customer creation result;
product creation result;
checkout session or payment intent result;
webhook notes;
app integration changes;
what remains untested;
clear statement that no real payment was processed.

That final statement matters.

Payment workflows need a clean boundary between local testing and production money movement.

Why this works well with ClawMama

This kind of skill is a good fit for ClawMama because the user does not need to start by maintaining an agent server.

The path is simpler:

create a ClawMama agent → install the Stripe Emulator skill → run a local test → inspect output

For a new user, that means:

no VPS setup first;
no custom agent runtime first;
$2 of AI credits to test the workflow;
access to the latest ChatGPT model;
OpenClaw or Hermes as the agent runtime;
Telegram as the control surface.

For a skill author, this also matters.

A GitHub repo is powerful, but many users still need a first successful run. A ready-to-use agent gives the skill a shorter path from announcement to adoption.

Safety notes

A few rules keep this clean:

Review installed SKILL.md files before using them.
Do not give the agent real Stripe secret keys for this test.
Do not point the app at api.stripe.com while testing the emulator workflow.
Remember that npx skills add installs from GitHub.
Remember that npx emulate runs an npm package.
Keep this as a local development workflow, not a production payment setup.
If port 4000 is busy, start the emulator on another port:

npx emulate --service stripe --port 5000

Also note that emulator state is local. If you restart it, assume you may need seed data unless you configure persistence or seed files.

Final takeaway

Vercel Labs' Stripe Emulator skill is a strong example of what agent skills should do.

It gives an agent a narrow, useful capability: test payment flows locally without real payment credentials.

With ClawMama, a user can create a ready-to-use OpenClaw or Hermes agent, install the skill from GitHub, run a first test, and see a real Stripe-like response in minutes.

That is the right shape for an agent skill:

specific capability → easy install → safe first run → useful output

Start with the smallest test:

npx skills add vercel-labs/emulate --skill stripe --agent openclaw -y --copy
npx emulate --service stripe
curl http://localhost:4000/v1/customers -H "Authorization: Bearer sk_test_emulated"

If that works, your agent has a safe local payment lab.

Turn a Product Brief into a Launch Video with HeyGen Skills and OpenClaw

Eli — Fri, 01 May 2026 03:38:30 +0000

HeyGen's HyperFrames skill is a good example of why agent skills are getting interesting.

It is not just another prompt.

The promise is more practical: give an agent a reusable video creation workflow, then ask it to turn a product idea, website, or launch brief into video-ready assets.

For a founder, marketer, or product operator, that means you can move from:

I need a launch video, but I do not know where to start.

to:

Here is my product brief. Create a short launch video plan, write the script, define the scenes, prepare the HTML-to-video workflow, and let me review before final generation.

This guide shows a simple way to try that workflow with an OpenClaw or Hermes agent.

What you will build

You will create a small launch video workflow:

Start an OpenClaw or Hermes agent.
Add the HeyGen HyperFrames skills.
Give the agent a product brief.
Ask it to create a launch video script.
Ask it to turn the script into scenes and assets.
Review the plan before generating or publishing anything.

The goal is not to promise a perfect one-click video.

The goal is to use an agent to prepare the hard parts of a launch video: structure, copy, scenes, timing, and review steps.

Why this is better than a normal AI chat

A normal AI chat can write a video script.

An agent with skills can do more useful work:

install or load a reusable video workflow;
inspect the project files or website you provide;
create structured scene assets;
run commands in its workspace;
produce files you can review;
ask for approval before expensive or risky actions.

That is the difference between asking AI for an idea and giving an agent a job.

OpenClaw and Hermes give the agent a runtime. Skills give it a method. ClawMama gives you a fast way to start testing this without maintaining the infrastructure yourself.

What you need

You need:

an OpenClaw or Hermes agent;
a short product brief, website URL, or launch idea;
the HeyGen HyperFrames skills;
a human review step before publishing or spending money.

If you want the fastest managed path, start with ClawMama:

https://t.me/clawmamarun_bot

Create a trial agent, then use it as the place where you send the workflow below.

Step 1: Ask your agent to add HeyGen HyperFrames skills

Send this to your OpenClaw or Hermes agent:

I want you to help me create a short product launch video workflow.

Please add the HeyGen HyperFrames skills if your environment supports agent skills:

npx skills add heygen-com/hyperframes

After installing, review the skill instructions before doing anything else.

Do not generate, publish, upload, or spend credits without asking me first.
First, prepare the script, scene plan, asset checklist, and review checklist.

The npx skills add heygen-com/hyperframes command installs the HyperFrames skill set.

At the time of writing, the skills directory shows several related skills from heygen-com/hyperframes, including:

hyperframes
gsap
hyperframes-cli
website-to-hyperframes
hyperframes-registry
remotion-to-hyperframes

That is useful because the workflow can start from a product brief or from an existing website.

Step 2: Give the agent a product brief

Use a short brief. Do not overcomplicate it.

Example:

Create a launch video plan for this product.

Product:
ClawMama

What it does:
ClawMama helps people launch managed OpenClaw or Hermes agents quickly, with Telegram as a simple control surface.

Audience:
Founders, marketers, operators, consultants, and small teams who want AI agents to do real work but do not want to maintain a VPS or agent runtime first.

Main benefit:
Start testing an AI agent workflow quickly, then expand later.

Tone:
Clear, practical, not hype.

Video length:
30 to 45 seconds.

Please create:
1. one simple video angle;
2. a 6-scene outline;
3. voiceover script;
4. on-screen text;
5. visual direction;
6. assets needed;
7. review checklist.

Do not generate the final video yet.

This prompt keeps the agent focused.

You are not asking for vague creative ideas. You are asking for a launch video production plan.

Step 3: Review the first output

A useful first output should look like this:

Launch Video Angle
"Your AI agent should do work, not just chat."

Scene 1: Problem
On-screen text: AI agents are useful, but setup is still too much work.
Voiceover: You want an AI agent to help with research, content, and workflows. But first you have to deploy, configure, connect, and maintain it.
Visual: messy terminal windows, server settings, scattered notes.

Scene 2: Shift
On-screen text: Start from the workflow, not the server.
Voiceover: ClawMama gives you a faster way to test an OpenClaw or Hermes agent.
Visual: product brief turning into an agent task list.

Scene 3: Control surface
On-screen text: Send tasks from Telegram.
Voiceover: Give the agent a task, review the result, and approve important actions before they happen.
Visual: chat message becoming a workflow.

Scene 4: Real work
On-screen text: Research. Content. Monitoring. Sales discovery.
Voiceover: The agent can use skills, tools, and repeatable workflows to help with real business work.
Visual: cards showing workflows.

Scene 5: Low-friction start
On-screen text: Try it before maintaining infrastructure.
Voiceover: Start with a managed runtime, then expand when the workflow proves useful.
Visual: simple start button, then workflow dashboard.

Scene 6: CTA
On-screen text: Launch your first agent workflow.
Voiceover: Start with ClawMama and test your first OpenClaw or Hermes agent.
Visual: clean end card.

This is already useful before any video is generated.

You now have:

a clear angle;
scene structure;
voiceover draft;
on-screen text;
visual direction;
a checklist for review.

Step 4: Ask for a HyperFrames-ready plan

Now ask the agent to convert the creative plan into a more implementation-ready structure:

Turn this launch video plan into a HyperFrames-ready production outline.

For each scene, include:
- duration;
- layout;
- text blocks;
- animation idea;
- visual assets needed;
- notes for HTML/CSS implementation;
- what I should review before generation.

Keep the first version simple. Avoid complex effects unless needed.

The agent should now think more like a production assistant.

A good output might include:

Scene 1
Duration: 5s
Layout: split screen, left side messy setup, right side blank workspace
Text: "AI agents are useful. Setup is the bottleneck."
Animation: quick staggered appearance of terminal, config, server icons
Implementation notes: use simple cards, muted background, red/yellow friction accents
Review: confirm that the pain is setup friction, not AI quality

This is where the skill workflow starts to matter.

The agent is not just writing copy. It is preparing structured production inputs.

Step 5: Use a website as input if you already have one

If you have a website, you can ask the agent to use it as source material.

For example:

Use this website as input for the launch video:

https://clawmama.run

Create a 30-second launch video concept from the homepage.
Extract the main value proposition, audience, proof points, and CTA.
Then create the script and scene plan.

Do not submit forms or publish anything.
Ask before final generation.

If the website-to-hyperframes skill is available in your agent environment, the agent may be able to use that path.

If not, it can still read the website content through available browser or fetch tools and prepare the plan manually.

Step 6: Add a human approval step

Keep this rule in the workflow:

Before final video generation, show me:
1. final script;
2. scene list;
3. on-screen text;
4. assets required;
5. estimated commands or tools you will run;
6. any external services, credits, or API keys needed.

Wait for my approval.

This matters.

Video generation may involve external tools, files, rendering time, or paid services. The agent should not treat that as a background action without your review.

Step 7: Reuse the workflow

Once the workflow works, you can reuse it for:

product launch videos;
feature announcement videos;
landing page explainer videos;
release note videos;
investor update clips;
internal product demos.

Try prompts like:

Turn this release note into a 20-second product update video plan.

Turn this landing page into a 30-second explainer video.

Create three video angles for this product brief. Make one practical, one founder-led, and one feature-focused.

That repeatability is the point.

You are not saving one prompt. You are building an agent workflow for launch assets.

Where ClawMama fits

You can self-host OpenClaw or Hermes and run this yourself.

But if your goal is to test the workflow quickly, ClawMama gives you a simpler path:

start a managed OpenClaw or Hermes agent;
send it the skill installation task;
paste your product brief;
review the script and scene plan;
decide whether to generate final assets;
expand the workflow later if it proves useful.

This is the right order for most teams:

workflow first, infrastructure later

Safety notes

A few practical rules:

Review installed skills before using them for real work.
Do not give an agent unlimited access to paid services.
Ask for approval before final generation, publishing, sending, or deleting.
Keep source assets and brand claims accurate.
Treat the first video as a draft, not a finished brand campaign.

The agent can help move faster. You still own the final creative decision.

Final takeaway

HeyGen HyperFrames is interesting because it shows what agent skills can become: reusable production workflows, not just better prompts.

With OpenClaw or Hermes, you can ask an agent to install the skill, read a product brief, plan a launch video, prepare scene structure, and wait for your approval before final generation.

That is a practical first step toward agent-powered launch workflows.

Start small:

product brief → script → scenes → review checklist → generation only after approval

If that saves time, you have a workflow worth keeping.

Browser access is not one permission

Eli — Fri, 01 May 2026 01:49:21 +0000

Do not give an agent “browser access.”

Give it read access. Give it draft access. Maybe give it update access with receipts. Put a gate in front of publish, refund, delete, merge, and spend.

The browser is not the hard part anymore. A logged-in browser session is authority, and authority needs shape.

The bug is the permission shape

Most browser-agent demos compress the whole problem into one checkbox:

Can the agent use a browser?

That question is too broad.

A browser agent that reads public pages is one thing. A browser agent that operates inside your logged-in Chrome session is another. Once the agent can see private dashboards, submit forms, edit CRM records, issue refunds, publish content, or change ad budgets, “browser access” stops being a tool permission.

It becomes delegated authority.

And delegated authority should not be one permission.

A signed-in browser is authority

A signed-in browser is where work actually happens.

It has your CRM, support inbox, admin dashboards, analytics, CMS, ad accounts, billing portals, SaaS consoles, customer records, docs, and internal tools.

That is why browser agents are useful. They can operate where APIs are incomplete, absent, fragmented, or too slow to integrate.

But that is also why they are dangerous.

If the agent can use the same browser session you use, it may be able to:

read private customer data,
draft replies from your account,
update CRM fields,
route tickets,
submit refunds,
cancel subscriptions,
merge customer accounts,
publish pages,
launch posts,
change ad budgets,
buy things,
or change admin settings.

Those are not the same action.

They should not share the same permission.

The action-class ladder

The useful abstraction is not “browser access.”

The useful abstraction is action class.

1. Read

The agent can inspect pages, dashboards, tickets, records, reports, and private context.

This is the lowest-risk class, but it is still not risk-free. Read access can expose customer data, internal metrics, private messages, and credentials visible in the UI.

Still, for many workflows, read access can run with relatively broad autonomy.

2. Draft

The agent can prepare a reply, CRM note, campaign edit, page change, support response, or internal summary, but it does not submit it.

Drafting is where many agents should start. It saves time without crossing the line into irreversible action.

3. Annotate

The agent can add non-destructive metadata: internal notes, tags, labels, comments, todo items, or follow-up tasks.

This is more active than drafting, but usually less risky than changing core records or sending external messages.

4. Update

The agent can change fields, statuses, owners, routing, priorities, labels, or internal records.

This is where receipts start to matter. If an agent changes a CRM field or ticket state, you should know what changed, when it changed, and why.

5. Submit

The agent can send a form, reply to a customer, create an external-facing record, or trigger a workflow.

Submit actions need more care because they leave the internal system and affect other people.

6. Publish

The agent can push content live: website pages, docs, social posts, changelogs, campaigns, or public updates.

Drafting a page and publishing a page are different permissions.

7. Refund, cancel, merge, delete

These actions can affect customers, accounts, money, history, or compliance.

They are often hard to reverse, and sometimes impossible to reverse cleanly.

Read access and refund access should never be the same permission.

8. Spend

The agent can move money: ad budgets, purchases, paid APIs, wallets, subscriptions, cloud resources, or agent-to-agent payments.

Viewing a budget and spending a budget are different permissions.

Spend actions need explicit ceilings, approvals, and circuit breakers.

A better default policy

A practical browser-agent policy can start simple:

Read and draft can often run freely.
Annotate and update need receipts and rollback awareness.
Submit and publish need approval gates.
Refund, cancel, merge, delete, and spend need explicit gates, limits, and after-action receipts.

This does not mean every workflow needs a heavy compliance system.

It means the agent should not receive one ambient permission called “use browser.”

A support triage agent might read tickets freely, draft replies freely, add internal notes with receipts, but require approval before refunding a customer.

A marketing agent might draft posts freely, propose edits freely, but require approval before publishing.

A sales agent might summarize a lead freely, draft a follow-up freely, but require confirmation before sending from a real inbox or updating a CRM opportunity stage.

A finance agent might view invoices freely, extract data freely, but require explicit approval before paying, refunding, or changing billing settings.

That is the difference between a useful agent and a risky one.

Execution trace vs authority receipt

Browser traces are useful.

They tell you what the agent saw, clicked, requested, rendered, and logged. Screenshots, DOM snapshots, network requests, and CDP logs make browser agents easier to debug.

But execution traces are not enough.

If an agent submits a refund, publishes a page, changes an ad budget, or updates a CRM record, the important question is not only:

What happened in the browser?

It is also:

Why was the agent allowed to do that?

That is the authority receipt.

A good authority receipt should answer:

Which browser session was delegated?
Which site or app was in scope?
What action class was attempted?
Was the action reversible?
Was approval required?
Who or what approved it?
What changed before and after?
Can access be revoked?

The browser trace tells you what happened.

The authority receipt tells you why it was allowed.

Real workflows make this obvious

Sales workflow

A sales agent may need to read LinkedIn, Gmail, HubSpot, Salesforce, call notes, and a company website.

Summarizing the lead is low-risk.

Drafting the follow-up is still fairly safe.

Sending the email from a real inbox is a different action.

Updating the CRM stage is another.

Creating a discount, changing contract terms, or booking a customer-facing meeting may require approval.

Support workflow

A support agent may read a ticket, inspect order history, summarize context, and draft a response.

But issuing a refund, cancelling a subscription, merging accounts, or changing account status should cross a gate.

Publishing workflow

A content agent may draft a page, update a preview, generate screenshots, and check links.

Publishing the page live is a separate permission.

So is deleting a page, changing canonical URLs, editing pricing pages, or posting from a brand account.

Ads workflow

An ads agent may inspect campaign performance and recommend budget movement.

Changing the budget is different.

Launching a campaign is different again.

Turning on spend should have ceilings and circuit breakers.

Coding workflow

An in-browser PR testing agent may click through a product, reproduce bugs, and report findings.

That is different from changing production settings, migrating data, or editing customer-facing configuration.

Same browser, different authority.

What good infrastructure should expose

Browser-agent infrastructure should expose action boundaries directly.

At minimum:

per-site scopes,
per-action scopes,
read vs write separation,
approval gates,
before/after diffs,
receipts,
revocation,
loop detection,
spend limits,
and kill switches.

The boring pieces are the product.

Not because autonomy is unimportant, but because autonomy without boundaries becomes operational debt.

A browser agent that can do everything is impressive in a demo. In production, you want the agent to know when it can act, when it should draft, when it should ask, and when it must stop.

Where BrowserMan fits

BrowserMan is built around delegated real-browser access.

The point is not just to give an AI agent a browser. The point is to let agents use the real Chrome session you already use, while keeping cookies local and making access controllable.

That matters because useful browser work happens inside logged-in tools.

But logged-in tools need boundaries.

BrowserMan’s category is controlled browser authority: agents can operate from anywhere, use real sessions when delegated, and work inside scopes that can be audited, gated, and revoked.

That is the difference between “the agent has a browser” and “the agent has the right browser authority for this task.”

The practical rule

Do not ask whether an agent should have browser access.

Ask what kind.

Can it read?
Can it draft?
Can it annotate?
Can it update?
Can it submit?
Can it publish?
Can it refund?
Can it delete?
Can it spend?

Those are different questions.

They deserve different answers.

Browser access is not one permission.

DEV Community: Eli

Trust-sensitive agents need visible friction

The browser is where authority lives

Background workers are not always the right shape

Ask what the agent can prove before it clicks

Approval gates should be thresholded, not everywhere

Completion is not the click

The BrowserMan angle: delegated browser authority

Logs Are Too Late for High-Value Browser Actions

Logs explain. Gates prevent.

The write boundary is the product

A practical policy model

Denials should teach the boundary

Receipts need identity

Why real Chrome raises the stakes

BrowserMan’s position

The Browser Agent Demo Is Not the Product. The Permission Model Is.

A browser demo proves capability, not trust

Signed-in browser access is delegated authority

Blanket permission feels fast until the risk class changes

Completion needs receipts, not just clicks

Tool-call policy is not enough for browser authority

The useful model: scope before, gates during, receipts after

Scope before execution

Gates during execution

Receipts after action

Where BrowserMan fits

The category will compete on trust, not just clicks

Enterprise portals are where browser agents become workflows

The demo is clicking. The workflow is everything around the click.

Stop rediscovering the same portal every time.

A logged-in browser session is authority, not just context.

Separate risk classes.

Approval gates need UX, not just policy.

Receipts are the audit trail for browser work.

Where BrowserMan fits.

Browser agents need authority-aware execution

Desktop MCP solves one half of the problem

The missing shape is runtime separated from authority

Account-aware is useful. Authority-aware is sharper.

Read-only and posting should not share the same permission

What a browser-handoff layer should provide

The boring workflows are where this gets valuable

Boring admin SaaS is where browser agents become real

The buyer workflow is not the flashy demo

The workflow is not “open QuickBooks”

Logged-in SaaS turns browser access into authority

Three requirements for real admin-SaaS browser agents

1. Real session access

2. Separation of read/prepare from write/submit

3. Receipts

Browser agents get serious in boring software

Existing Chrome profiles are becoming a product primitive for agents

The browser-auth tax is becoming visible

Why agents collapse back to the existing Chrome profile

Three lanes are emerging

1. Cloud browser infrastructure

2. Local or browser-resident agents

3. Delegated real-browser access

The browser is the execution boundary

Approval is not always friction

Side effects need receipts

What BrowserMan changes

Delegated browser access vs cookie sync: the browser session is authority

1. Cloud browser plus cookie sync

2. Isolated agent browser or profile

3. Local attach to existing Chrome

4. Delegated real-browser access

The comparison is really about authority models

The missing enterprise axis: identity and isolation

Questions to ask before choosing a browser access model

Where BrowserMan fits

Use GitHub Gists as an AI Agent Skill Registry with gh skill

Who this is for

What gh skill does

Step 1: Install GitHub CLI

Step 2: Install the extension

Step 3: Understand the skill folder format

Step 4: Publish a skill

Step 5: Install a skill from a Gist

What `gh skill` does