Computer-Use Browser Tools
A computer-use tool lets an agent drive a real web UI — navigate, click, type, scroll, screenshot — through a bounded, guarded, fully audited screenshot-step loop. Use it when the system your agent needs to operate has no clean API: an internal admin panel, a partner portal, a legacy back office. Endpoint paths below are relative; send them againsthttps://api.orbit.devotel.io. Endpoint schemas are not restated here — see
the agents endpoint reference for the full
request and response bodies.
There is no dedicated Computer-Use section in the dashboard yet — a
Computer-Use panel is planned but not shipped. Until it lands, manage tools,
dry-runs, and session reads through the API surface below.
1. What a computer-use tool is
An agent’s tool belt today composes four tool kinds:- Custom tools — named HTTP endpoints you register once and reference from any agent.
- MCP tools — capabilities exposed by an external MCP server.
- A2A — skills another agent exposes through the A2A federation surface.
- Computer-use tools — a bounded browser-operating loop that drives a web UI step by step.
- Bounded step budget —
max_stepscaps the loop (1–50, default 20). A run that exhausts its budget is forced to stop. - SSRF-pinned sandbox — the
sandbox_urlis validated at write time and re-pinned at every dispatch, so a tool can never be pointed at internal infrastructure. - Envelope-encrypted sandbox secret —
sandbox_secretis stored envelope-encrypted and never returned by any read. Responses expose only asandbox_secret_setflag. - Audit trail — every proposed action is recorded, whether it was allowed, denied, or gated on confirmation. A run can always be reconstructed later.
2. Create a computer-use tool
POST /api/v1/agents/{agentId}/computer-use-tools registers a tool on one
agent. Each tool is tenant-scoped and lives under
/api/v1/agents/{agentId}/computer-use-tools — full list / update / delete
CRUD alongside create.
Key fields on create:
The browser action vocabulary is a closed set:
navigate, click,
double_click, right_click, type, key, scroll, move, drag,
wait, screenshot, back, forward, refresh. navigate is the only
URL-bearing action — it is the one the domain allowlist gates.
Example:
201 with the created tool. Updates go through
PATCH /api/v1/agents/{agentId}/computer-use-tools/{toolId} — re-sending
sandbox_url re-validates it, sending sandbox_secret: null clears the
stored secret, and omitting it leaves the current secret untouched.
DELETE removes the tool. A 422 INVALID_SANDBOX_URL envelope names why the
sandbox URL failed safety validation (protocol, blocked host, internal
suffix, DNS, or private IP).
Node.js:
3. Validate guardrails with a dry-run
POST /api/v1/agents/{agentId}/computer-use-tools/{toolId}/dry-run evaluates
one proposed action against the tool’s guardrails before you let an agent
loose on it. Send {"dispatch": false} to check the guardrail verdict only,
or {"dispatch": true} (the default) to also forward the action to the
sandbox exactly once — marked as a test so the sandbox treats it accordingly.
decision—allow,deny, orrequire_confirmation.code— a machine-readable guardrail code on a non-allow verdict (see §5), anddone: truefrom a live run when the step budget is exhausted.result— the sandbox round-trip: HTTP status, duration, response body, and the error string when the sandbox rejected the action.
4. Audit every run
Every live run is reconstructable from the audit trail. There is no session table — reads group the per-step action records by run:GET /api/v1/agents/{agentId}/computer-use/sessions— one row per run: status, first/last step timing, step count, and the operator-supplied task. Filter with?status=all|active|completed|failed(defaultall) and?limit=1–100(default 25).GET /api/v1/agents/{agentId}/computer-use/sessions/{sessionId}— one run’s full ordered action trace: each step’s action kind, guardrail decision, sandbox status, and duration.
status reflects how the run ended (completed, failed,
cancelled) plus running / needs_input for runs still in flight.
Step-by-step records are keyed by run, so the trace survives restarts and is
the source of truth the dashboard session list will render.
5. Guardrail rules and runtime containment
Each proposed action passes through the tool’s guardrails before Orbit forwards it to the sandbox. The outcome is one of:
At runtime the loop is additionally contained by the
step_timeout_ms per-action timeout and by SSRF re-pinning on every single
dispatch — the sandbox URL is re-validated per call, not once at creation.
Access. Lists, session reads, and dry-runs require the agents:read
scope; create / update / delete require agents:write plus the owner,
admin, or developer role. All surfaces are tenant-scoped — an agent id
outside your organization resolves to a 404.
6. Where it fits with other tool kinds
Computer-use complements rather than replaces the other tool kinds:- Reach for a custom tool when the target system has an HTTP endpoint you can call.
- Reach for MCP / A2A when the capability is already exposed by a service or another agent.
- Reach for computer-use when the only interface is a rendered page — and accept the higher per-step cost in exchange for the closed action set, step budget, and full audit trail.