Browser actions
Some of the systems your work depends on have no API — a supplier portal, a legacy admin console, a regulator's filing site, an internal tool nobody will ever build an integration for. A Trellaris agent can operate them the way a person does: it opens the page, reads what is there, fills the form and submits it. This is the browser tool — the agent's hands for the web — and, because acting on a real system is consequential, it is one of the most tightly governed things an agent can do.
Why it adds value
Agents already reach systems three ways: connectors for products with a governed API, knowledge for what is written down, and web search and fetch for the open, static web. The browser tool covers what those cannot: a site that renders behind JavaScript and a login, a multi-step UI, a form that has to be submitted, a report that only exists behind a session. It turns "we have a dozen web systems and none of them has an API" from a dead end into an agent task — and it does it under the same governance as everything else on the platform, rather than as a brittle script running outside it.
What the agent can do
The tool exposes a small, deliberate set of operations. Two are reads and run immediately; four are writes and change a real system, so they are gated. Two of the writes are marked destructive — the platform treats them with extra care.
| Operation | Kind | What it does |
|---|---|---|
navigate | Read | Open a page and return its text |
extract | Read | Read a page's content (a table, a status, a value) |
click | Write | Click a control |
type | Write | Enter text into a field |
submit | Write · destructive | Submit a form — the action that lands on the system |
download | Write · destructive | Pull a file down (an invoice, an evidence receipt) |
How a run is governed
Nothing about the browser tool is trusted by default. Every op passes through the same platform controls that govern any other tool, plus a few that exist only for it.
-
Default-deny egress — it can only reach where you allow
Before a single page loads, the target host is checked against a browser-egress policy. With no policy, nothing is reachable; an administrator allows the specific hosts an agent may open, and everything else comes backbrowser.egress_blockedbefore the browser is even started. The allowlist is the outer wall: an agent cannot wander off to an arbitrary site, whatever a page or a prompt tries to make it do. -
Reads flow, writes pause for a person
navigateandextractrun straight through. Every write —click,type,submit,download— routes through the approval gate: the run pauses, and a human sees the exact action ("submit the disable form for alice@…") before it touches the system. Approve, and it executes exactly once; the agent never claims a change is done before the approval comes back. How much pauses is set by the agent's autonomy level and your policies. -
DLP on everything read back
Whatever the agent reads off a page is passed through data-loss prevention before the model — or anyone — sees it, so a customer number or an SSN on an admin page is redacted just as it is everywhere else on the platform. -
Never a password
The agent operates an already-authenticated session; it does not sign in, does not type a password or a credential, and does not create accounts or reset passwords by entering new ones. Those are for a person. The session comes from your vault, never from the conversation. -
A recording of every step
Each op writes a durable record — the operation, the target, and the (redacted) result — attached to the run, and the whole sequence appears in the Observe timeline as spans with their timings. Optionally, the platform also captures a screenshot per op (see below). Nothing the agent does in a browser is invisible.
| Control | What it protects |
|---|---|
| Browser-egress allowlist | Where the agent may go — default-deny |
| Approval gate on writes | Nothing changes a system without a person |
| Autonomy level | How much an agent may do before it pauses |
| DLP on extracted text | Sensitive data never leaves the boundary un-redacted |
| Recording + trace | Every step is auditable after the fact |
| Credential boundary | The agent never types secrets; the session is vaulted |
See what the browser did
A browser run leaves three trails, so an operator can reconstruct exactly what happened without having watched it live:
- The Observe trace — every op as a span: which operation, which URL, how long it took, and the redacted content it read back. Reachable from any chat turn under Run info.
- Artifacts — a structured recording per op, and, when enabled, a screenshot per op so the Artifacts tab shows what each step looked like.
- Approvals — every pending write, previewed before it runs, and audited after.
Where it runs
In development and CI the tool drives a deterministic, offline browser, so tests are fast and repeatable and never touch the network. In a real deployment it drives headless Chromium, carried only in the worker that executes runs — the rest of the platform stays lean. Turning it on for an environment is configuration: choose the driver, allow the console's host, and the same agent that behaved in tests now acts on the real thing.
Reference agent
The IT Fulfilment Agent
The browser tool ships with a built-in agent that shows what it is for: the
IT Fulfilment Agent — the hands behind the IT service desk.
Where the ITHelp desk captures a
request ("my laptop won't start", "I need a licence"), the Fulfilment agent
carries it out in the admin console: assign or reclaim a licence,
reset MFA, add someone to a group, disable a leaver's account. It answers to
@it-fulfilment and lives in the org ring, visible from every
workspace.
How a fulfilment runs
-
Understand the change
It states plainly what it is about to do and to whom — "assign an M365-E3 licence to alice@contoso.test", "disable bob@contoso.test" — and asks one question rather than guessing if the person or the action is unclear. It never invents an email, a licence or a group the request did not name. -
Verify first (reads)
It opens the console and reads: does the user exist, are they already in that state, is a seat free before it assigns one. If the change is already done or would be wrong — no free seats, the account already disabled — it stops and says so rather than submitting anyway. -
Make the change (a write, through approval)
It submits the specific form, and the run pauses for a person to approve. One change per confirmation, so an approver is never asked to bless two actions at once. After approval the change runs exactly once. -
Confirm with evidence
It reads the resulting page back to confirm the new state and downloads the evidence receipt, so the ticket carries proof of exactly what changed. The report is two or three lines: what changed, for whom, who approved, and the new state.
Intake and fulfilment, joined
A request phrased as a question ("can you raise a ticket?") goes to the ITHelp desk for intake. A request phrased as an action in a system ("assign the licence and add them to Engineering") reaches the Fulfilment agent, because it is the only agent that holds the browser tool — the platform routes a step to the agent that can actually perform it. The two are a pair: one takes the request, the other does the work.
Try it
@it-fulfilment what's the status of bob@contoso.test? @it-fulfilment assign an M365-E3 licence to bob@contoso.test @it-fulfilment disable alice@contoso.test — she's left the company
The first answers straight away (a read). The others verify, then pause for your approval; approve in the inbox and the change lands, with a screenshot and an evidence receipt attached to the run.
Related: Approvals, Autonomy, DLP, Observability, Agents.