Agents, Automation, and the API
A container is not only for a person at a keyboard. The same machine can be driven by an AI agent that browses the web, operates a desktop, and runs code, or by a script through the public API. This guide teaches how an agent gets a browser that is already logged in, when to reach for page-level versus desktop-level control, how untrusted model-generated code is contained, why the page tools never type a password, and how to drive the whole lifecycle over REST. After this page you will be able to put an agent to work in a container with a clear view of what it can reach and what keeps it safe.
Every capability here rides the platform's Model Context Protocol (MCP) surface and its public REST API, and runs under your organization's roles and permissions. An agent can never exceed the access of the identity behind it.
A Browser That Logs Itself In
After this section you will understand why an agent skips the login step. The single biggest friction in agent browser automation is getting the browser signed into your workspace without a human pasting credentials. A Backbuild container solves this at the source. When it is launched with a browser, the Backbuild browser extension is already installed and authenticates itself as the session's own user through managed policy. The agent opens the app and it is simply already signed in. There is no login form to fill, no token to hand the model, and no credential for the agent to fumble.
Other sites are different. The page tools refuse to type into a password or one-time-code field, and no tool hands the agent a password from your vault, so the agent is not the one that signs in to them. When a task needs a third-party site that requires a login, a person signs in to it in the container's browser, and the agent carries on in the signed-in session. Never paste a password into an agent's instructions: whatever is in its prompt, it can type.
How does the agent's browser log in without a human? The container's browser authenticates itself as the session's user through managed policy, so it is already signed into your workspace with no login step. For other sites, the page tools refuse to type into password and one-time-code fields, so a person signs in and the agent continues from there.
Page Control and Desktop Control
After this section you will know which tool set to use for which task. An agent drives a container through two complementary families of tools, and the distinction matters because each reaches a different layer.
| Tool family | What it drives | Reaches |
|---|---|---|
| Page control | The content of the web page: navigate, read the elements on the page with their positions, click, type, list tabs, and capture the page. | Everything that is page content, driven through the browser. |
| Desktop control | The whole desktop: take a screenshot, move and click the mouse, type, press keys, and scroll, by screen position. | Anything on screen, including browser chrome, native windows, and operating-system dialogs that a page tool cannot touch. |
Use page control for work inside a web page, it is precise and reads the page's real structure. Use desktop control when the target is not page content: the browser's own address bar and tabs, a file-picker or permission dialog the operating system shows, or any native application window. The desktop path is what lets an agent finish a task that a page-only tool would stall on. Both are pinned to the agent's own container session, so an agent drives its container and no one else's.
Can the agent do things a web page cannot reach, like an OS dialog? Yes. Page-control tools drive page content; desktop-control tools drive the whole screen by position, so they can operate browser chrome, native windows, and operating-system dialogs that page tools cannot.
How mature is the control surface? It is the same MCP surface the platform uses in production, reached the standard way through the MCP tools, and the container lifecycle is also fully drivable over the REST API. It is built to be driven, not demonstrated.
Running Untrusted Code Safely
After this section you will be able to answer, for a security review, whether it is safe to run model-generated code in a container. Every time an agent runs code it wrote, that is software you did not write, so a container is built to contain it by default rather than to trust it. The user-facing posture:
- Per-session and per-organization isolation. A container belongs to one session in one organization. It cannot reach another container, and a request that crosses the organization boundary is treated as not found.
- Least-privilege execution. Code runs without root and with reduced privileges, so a process cannot help itself to the machine.
- Fenced outbound network. A container can reach the public internet, because package installs, git, and AI providers need it, but it cannot reach other containers, private network ranges, or the cloud metadata service. Treat anything a container can read as something code inside it could send to a public host, and give a container only the data and credentials its task needs.
- No platform secrets. The cloud metadata endpoint an escaped process would probe for credentials is unreachable, and a container holds no access to Backbuild's own data stores or platform secrets.
- Disposable. Each session is its own machine and is torn down after use. Only your home folder, and coding-agent access restored from your vault, carry into the next session; running processes and anything outside the home folder do not.
- Attributable. Container operations are audit-logged with the identity that performed them.
Sandbox Execution, the API-first agent surface, follows a different model: its outbound network is limited to a fixed list of package and source registries, and its own isolation posture is described on that page. The platform's wider posture is in Security and Compliance.
What stops an agent exfiltrating data or being hijacked by a malicious page? Not the network alone: a container can reach the public internet, so the protection is in what it holds. Each session is isolated from every other container, the page tools never type a password or a one-time code, and an agent can never act beyond the access of the identity behind it. Give a container only the data its task needs.
Can a container reach our internal systems or another tenant? It cannot reach another container or private network ranges, and any request across the organization boundary is treated as not found. It can reach whatever you expose on the public internet, the same as any other internet client.
Driving the Lifecycle Over REST
After this section you will know how to provision and drive containers from your own code. The entire container lifecycle, listing the sizes your policy allows, launching a session, checking its status, connecting to it, and closing it, is available over the public REST API, under the same authentication and the same organization-scoped policy as the app. An agent orchestrator or a CI job can therefore launch a container, do its work, and tear it down without a person involved, and every call is governed by the caller's permissions.
# Base URL
https://api.backbuild.ai/v1
# Example: list your organizations
curl -H "Authorization: Bearer $TOKEN" \
https://api.backbuild.ai/v1/organizationsSee the Containers API reference for the complete request and response documentation, the MCP Server guide for driving containers as tools, and Authentication and API Keys for how to authenticate a script or an agent.
Where to Next
- Virtual Workers: a governed, autonomous AI worker that operates a container for you under your roles, vault, and audit trail.
- Sandbox Execution: the API-first, disposable code-execution model with git clone and artifact download.
- Password and Secrets Vault: where your organization keeps the credentials its people and workers use.
- Containers API Reference: the endpoints for the whole lifecycle.