Cloud Computer for AI Agents: Chrome Without Your Passwords

Posted on by
Contents show
cloud computer

The agent shipped the fix, wrote a tidy summary, and then stopped. The staging dashboard it needed to verify the change sat behind a login that lived in a person's browser, and the agent had no browser of its own. Nothing about the task was hard. The agent simply had no computer. A cloud computer is the smallest object that fixes this, because it bundles the browser, the session and the files into one addressable place.

That gap is what a cloud computer for AI agents is meant to close. Instead of handing an assistant another API key and another narrow tool, the assistant gets a real machine with Chrome on it, a machine you also use, with the sessions and files that make work continue between chats rather than restart with every prompt.

This piece looks at how that arrangement works in practice, what a cloud computer protects, and where the idea still runs into trouble.

The login wall is the real integration problem

Agent tooling has spent two years making models better at calling functions. It has spent far less time on the unglamorous question of what happens when the work is inside a web application that expects a human session.

Most internal tools never had an API worth using. Admin panels, staging environments, analytics dashboards, procurement portals and legacy CRMs assume a browser, a cookie and a person. An agent with a shell and a set of REST tools can read a repository all day and still be unable to click the button that reproduces a bug.

The usual workarounds are all compromised. Screenshot handoffs turn the agent into a spectator. Cookie export tools move credentials into places nobody audits. Handing over a password breaks the first rule of access control, because the agent can then do anything the person can do, from anywhere, with no record of which actor did it.

A cloud computer for AI agents attacks the problem from a different angle. The agent gets its own session on a machine that already holds the logins, and the human keeps the ability to watch, take over, or switch it off.

There is a reason this matters now rather than two years ago. Browser automation used to be brittle enough that only dedicated teams attempted it. Modern vision models read a page the way a person does, which means an agent can work an unfamiliar interface without a selector for every button. The missing piece stopped being perception and started being a place to stand. That shift is what makes a cloud computer practical rather than experimental.

What a shared cloud computer actually looks like

The machine on offer is modest and specific: eight CPUs, 16 GB of memory, Chrome, and a start time measured in seconds rather than minutes. It opens from any device, which matters more than it sounds, because the point is that the session is not tied to the laptop in front of you. The specification is deliberately unexciting. A cloud computer that promised more would be a server, and a server is what most teams already struggle to secure.

Each assistant gets labelled tabs. When two agents work at once, the labels are how you tell which one is editing the invoice and which one is reading the changelog. Two agents inside one cloud computer need labels more than they need speed. You can watch live, and you can take over the same tab without asking the agent to stop, which is the difference between supervision and a status report.

Connection is through the Model Context Protocol, so the setup is a single command against an HTTP endpoint rather than a bespoke integration per framework. Tools exposed this way include opening a browser, reading a page, and saving a screenshot into the machine's files, which means the artefacts of a run survive the conversation that produced them. The endpoint is the whole integration, which is why a cloud computer can be added to an existing harness in an afternoon.

For coding agents, the practical effect is a test loop that keeps running when the laptop closes. A cloud computer does not make the model smarter. It removes the requirement that a human stay at the keyboard while the agent clicks through a signup flow.

Storage follows the same logic. Files, sessions and logins are written to your own Google Drive, Dropbox or S3 bucket, and the vendor states that the durable copies are encrypted with AES-256. A session starts on a fresh isolated machine, and after ten minutes of inactivity the work is saved back and the machine is deleted. The desktop is disposable. The state is not.

Where this fits in an agent stack

A cloud computer for AI agents is not a replacement for the harness. It is a layer below it, alongside the sandbox that runs commands and the orchestration that decides what to do next.

Teams that already run coding agents in isolated workspaces will recognise the shape, because a dedicated workspace for coding agents solves a similar problem for files and terminals. The difference is that a browser session carries identity, and identity is what most sandboxes deliberately lack. This is also why the security section below matters more than the feature list.

Three ways to give an agent a browser

The shared cloud computer is one of three common patterns, and the trade offs are worth stating plainly.

Running Chrome locally with a debugging port is the cheapest option. It uses the real browser, with the real profile, and it costs nothing. It also runs on the machine that holds everything else, which means an agent mistake lands on your own desktop, and the session dies when the laptop sleeps.

A hosted browser API is the middle path. The agent gets a remote Chrome instance with a clean profile, controlled over a protocol, priced per hour. It is excellent for scraping and testing public pages. What it does not have is your logins, which is precisely the requirement that sends teams looking for something else. An AI agent browser that only reaches public pages is a different product from one that carries your session, and the difference is what a cloud computer sells.

A full cloud computer for AI agents goes further. It keeps a desktop, a browser, a filesystem and an identity together, and it lets a person share the same session. That is more surface area to secure than either alternative, and it is the only one of the three that answers the staging dashboard problem without exporting a cookie.

The security model, read carefully

Three promises define the security model of a cloud computer, and each one deserves a plain reading.

The data stays in storage you control. Files, browser sessions and logins are written to your own Google Drive, Dropbox or S3 bucket. The vendor states that sessions and logins are encrypted with AES-256, and that storage can be switched at any time. The meaningful part is not the cipher. It is that the durable copy sits in an account your organisation already governs, with the retention and access rules you already apply.

The machine is disposable. Each session starts on a fresh, isolated computer. After ten minutes of inactivity the work is saved back to your drive and the computer is deleted. A cloud computer built this way has a bounded blast radius by construction: whatever an agent installs, opens or breaks disappears with the session, and the next run starts clean.

Passwords are not handed to the model. Assistants work through the browser session rather than through a credential store, and the vendor states that assistants never see passwords. Access is granted per application, with read-only, read and write, or selected actions as the available levels. Thirty or more apps are supported, including Gmail, Calendar, Slack, Notion and Linear.

The fourth element is the one that turns monitoring into control. A mass deletion triggers an alert, an email arrives, and one click disables that assistant. The history of what it did stays available, which is what you need at the moment you are deciding whether to trust the next run.

What this does not defend against

None of the above stops prompt injection. If an agent reads a page that contains instructions, those instructions arrive in the same context as your task, and the model has no reliable way to tell a comment from a command.

The Open Web Application Security Project documents this as a top risk for language model applications and notes that retrieval and fine-tuning do not fix it. The mitigations it recommends are the ones a cautious operator would apply anyway: constrain the agent's role, enforce least privilege, require human approval for high risk actions, and treat external content as untrusted.

A cloud computer changes where those controls live. It does not remove the need for them. The browser is the most attacker-exposed surface in the stack, because every page an agent opens is untrusted input with a click available. A cloud computer narrows the blast radius. It does not shrink the attack surface.

There is a second, quieter problem. If an agent acts inside your session, the audit trail shows your account. Attribution depends on the platform's own logs, not on the application being automated. Teams in regulated environments should confirm that the per-assistant history is sufficient evidence before they connect anything that matters.

And there is a third: the shared session is a shared identity. A cloud computer for AI agents that logs in as you inherits every permission you hold, including the ones you forgot about. Per-app permission controls help, but they are enforced at the connection layer, not inside the target application. If the application itself has a destructive endpoint, the agent can reach it.

Watching is the feature

Most agent products sell autonomy. The more useful pitch here is visibility, because the failure mode that hurts is not an agent that refuses a task. It is an agent that completes the wrong one confidently.

Live tabs solve a specific problem: you can see which assistant is where, and you can interrupt without killing the session. A cloud computer with labelled tabs turns supervision into something a person can do while working. That is a different guarantee from a log written after the fact, and it is the reason a shared screen beats a report for anyone who has cleaned up after an automated mistake.

The mass delete alert is the same idea applied to consequences. It is a crude heuristic, and crude is appropriate. A rate based trigger catches the destructive case that no permission model predicted, and one click is the correct amount of friction for stopping it.

Where it pays off, and where it does not

The strongest fit for a cloud computer is work that lives behind a login and happens at human pace. Verifying a deployment on a staging box. Walking through a signup flow to confirm a fix. Checking three dashboards for the numbers a weekly report needs. Reading a supplier portal that has never had an API. Running those tasks after hours, when nobody wants to be at a desk, is the case that justifies the machine.

A worked example makes the value concrete. A release candidate needs a smoke test on a staging environment that sits behind single sign-on, with a test card and a seeded account. Without a browser session, a person runs the flow, takes screenshots, and reports back, which costs twenty minutes and breaks the agent's loop. A cloud computer earns its place in exactly this loop. The agent opens the same environment, walks the flow, saves screenshots into the shared files, and leaves the trail for review. The person checks the result instead of producing it.

The second fit is research across sources that require a session. A cloud computer for AI agents can hold a dozen authenticated tabs, and a person can review the trail afterwards instead of trusting a summary.

The poor fits for a cloud computer are just as clear. High volume scraping belongs on infrastructure built for it, not on a desktop with a browser. Work involving data that cannot leave a controlled environment should not be routed through a third party at all, encryption claims notwithstanding. And any task where a wrong click is irreversible, such as payments or production deletions, needs approval steps before it needs a faster agent.

There is also a skills fit. A cloud computer rewards teams that already write precise operating procedures. It punishes teams that expect the model to infer intent from a vague request, because the machine will do exactly what it is told, including the wrong thing.

The economics and the fine print

Free is the current price of a cloud computer, and free is a vendor statement rather than a settled fact. Free is a useful way to start and a poor basis for planning. Any team that builds a workflow on it should assume the terms will change once usage is expensive to serve.

A free cloud computer still costs money somewhere. The costs that do not appear on a pricing page are the ones to budget for. Storage egress from your own bucket. The engineering time to write per-app permission policies. The review time for alerts. The cost of a mistake that a human would not have made.

Portability is better than usual, because the connection is a standard protocol and the durable state sits in your storage. Moving the agent to another harness is a configuration change. Moving the sessions is a matter of pointing at the same drive.

What is missing is independent evidence. There is no published benchmark for task reliability, no third party security audit in the public record, and no long term data on how often the isolation boundary has been tested by real attacks. Those are reasonable things to want before an agent gets a browser that can reach production dashboards. This is where the numbers stop, and saying so is more useful than repeating a launch claim.

A rollout that does not hand over the keys

Treat the cloud computer as a shared office, not as a personal laptop. Start with a machine that can reach staging and nothing else. Connect one application, not thirty. Watch the first ten runs live rather than reading the history afterwards, because the first ten runs are where the interesting failures happen.

Give the agent its own account wherever the target system allows it, and reserve session sharing for tools that cannot issue a second identity. Least privilege is not a slogan here. It is the difference between an agent that can read a dashboard and an agent that can delete the rows behind it.

Write the operating procedure before the prompt. State what the agent may click, what it must ask about, and what it must never touch. Put the irreversible actions behind a human approval step, and test that step by asking the agent to do something destructive on purpose.

Set a canary. A page you control that contains a hidden instruction is the cheapest prompt injection test available, and it tells you more about your defences than any vendor claim. If the agent follows the hidden instruction, the browser is not ready for authenticated work.

The cloud computer is only as safe as the procedure around it. Review the alert threshold monthly. A trigger tuned for a quiet week will miss a busy one, and the cost of a false alarm is far lower than the cost of a missed deletion.

A checklist before you connect

  • Confirm where sessions and files are stored, and that the bucket or drive is governed by your organisation.
  • Decide which applications the agent may touch, at which permission level, and write it down.
  • Create a separate identity for the agent wherever the application supports one.
  • Put every irreversible action behind human approval.
  • Run the canary page test before the first real task.
  • Watch the first week live, then move to review.
  • Set a spending and storage limit you are willing to lose.
  • Agree who gets the alert, and who is allowed to press the switch.

Sources
Subscription Form