Forms in partner portals, filled without the retyping
Dealer registrations, warranty claims, subsidy applications: the data is already in your system and the form is in someone else’s portal. An agent task types it in, and the submit button is treated as what it is.
Three controls sit between the agent and the submit button
A form that sends money or a legal statement is not a page to automate casually. These are the parts of the runtime that exist for exactly this case.
Effect gates classify the element, not the instruction
Before an action runs, the control it targets is classified: a submit, a payment, a deletion. The classification comes from the element and its context, so an instruction phrased innocently cannot sneak past it.
The destination is resolved before it is used
A link or button that would leave the portal is resolved in the page first. A run pinned to its start site refuses a control that leads elsewhere, which is how an injected page fails to redirect the agent.
A separate reviewer decides whether it is done
The agent never certifies its own success. A second call reads the page again and judges the claim; a form that still shows the submit button is evidence that it was not submitted.
A typical claim flow
Run it as an agent task for forms that vary, or as a workflow for forms that do not.
-
Vault the portal login
Create a credential for the partner portal. The task references it by id and the sign-in happens without the password passing through any model.
-
Give the agent the data and the boundary
The task text carries the field values from your system. Pin the run to the portal’s site so a stray link cannot take it elsewhere, and choose the effect policy that fits: refuse irreversible actions, or require confirmation.
-
Let a person handle the last click
Open the live view and take over for the final review and submit. The takeover lease guarantees a single writer, so the agent and the person never fight over the mouse.
-
Keep the record
Every action lands in the hash-chained log with the task id. When the partner disputes what was entered, the export shows what the browser did and when.
An agent task pinned to the portal
import { Browserberg } from '@browserberg/sdk';
const bb = new Browserberg({
apiKey: process.env.BROWSERBERG_API_KEY,
baseUrl: 'https://browserberg.com',
});
const session = await bb.sessions.create({ ttlSeconds: 1800 });
const run = await session.runTask({
task: 'Open the warranty claim form and fill it in: serial number 4711-AX, ' +
'purchase date 2026-03-12, fault "display flickers after 10 minutes". ' +
'Stop before submitting and report what the form shows.',
startUrl: 'https://partners.manufacturer.example/claims/new',
pinToStartSite: true,
});
console.log(run.status, run.answer);
// completed / terminated / failed -- and the reviewer's verdict in run.verification
Behaviour on the risky parts
| Submit, pay, delete | Classified by the element; refused or held for confirmation according to your policy |
|---|---|
| Leaving the portal | A pinned run refuses controls whose destination resolves off-site |
| Success claims | Judged by a separate reviewer against the re-read page |
| Human hand-off | Live view with a single-writer takeover lease; the session stays alive while a person holds it |
| Credentials | Vault reference only; released on the portal’s own site at typing time |
| Record | Signed, hash-chained action log per run, exportable |
As of 2026-09-04
Questions compliance asks
Will the agent ever submit on its own?
Only if your policy allows it. The default classifies a submit as an effect and refuses it; you can allow confirmation instead, or keep the last click for a person through the live view.
What does the reviewer actually see?
The page after the last action, re-read from the browser, plus the record of what was clicked. It does not see the agent’s own account of its work, which is the point.
Can the partner tell it was an agent?
It is a normal Chromium session signed in with the account you hold, with no fingerprint games. Whether the partner permits automation is a question for your agreement with them, not something the product hides.
What if the form has a CAPTCHA?
Then a person solves it in the live view. Browserberg does not ship CAPTCHA solving; on a partner portal that asks for one, a human hand-off is the honest answer.
Automate the typing, keep the decision
Five browser hours, no card. Bring one form that somebody fills in by hand every week.