Preventing a Browser MCP Server from Submitting Forms or Making Purchases Without Approval
Enforce approval where the browser tool call executes, not in the prompt or the client prompt dialog. Classify each call by its effect (read, interact, submit, purchase, credential entry), allow only low-risk classes to run autonomously, and escalate everything else to a human. Bind each approval to one actor, one exact call, and one use, and keep a decision record for every allowed, blocked, or escalated call.
- {"title":"1. Classify the call","description":"Assign an action class from the call's parameters, target domain, and page context. Do not rely on server-supplied annotations. Verify the pinned tool definition hash first."}
- {"title":"2. Apply policy","description":"Use an allowlist of autonomous actions. Allow read-only and non-committing calls on approved domains. Block credential entry and out-of-scope domains by default. Escalate submits, purchases, account changes, and unclassified calls."}
- {"title":"3. Hold and present","description":"Pause execution and show the approver the domain, the action, the form fields or amount, and the agent session. Mask secret values."}
- {"title":"4. Verify the approver","description":"Require an authenticated human with authority for that action class. The agent's own session must never be able to approve."}
- {"title":"5. Bind and consume","description":"Tie the approval to the actor, the exact call, and its parameters. Check and consume it atomically just before execution. If the target or parameters change, require new approval."}
- {"title":"6. Record the outcome","description":"Write the decision, approver, and execution result to durable storage, including calls that were denied or timed out."}
- Timestamp, agent or session identity, and the MCP server and tool invoked
- Action class assigned and the policy rule that produced the decision
- Target domain and the parameters evaluated, with secrets redacted
- Decision: allowed, blocked, or escalated
- Approver identity, approval time, and outcome for escalated calls
- Tool definition hash at decision time and any change that forced re-approval
Layered controls compared
Client confirmation settings
Adds a prompt before some tool calls. Gap: behavior differs by client, users can auto-approve, and the prompt is not tied to a durable decision record.
Scoped, per-server credentials
Limits what a compromised or manipulated call can reach. Gap: it does not stop an in-scope submit or purchase from running unapproved.
Sandboxed browser profile
Keeps the agent away from personal sessions and saved logins. Gap: sandboxing alone does not restrict the server's file, network, or credential access, and it does not judge individual actions.
Domain restrictions
Narrows where the agent can act. Gap: a permitted domain can still host a checkout or an account change.
Separate servers for payment and auth
Keeps sensitive capabilities away from general browsing. Gap: the sensitive server still needs per-call approval.
Runtime policy in the execution path
Evaluates each call and returns allow, block, or escalate before it runs. Gap: it depends on good classification and a maintained policy.
Which browser tool calls carry side effects
A browser-capable MCP server gives an agent the same primitives a person uses: navigate, read the page, click, type, select, and submit. Most of these are harmless on their own. The risk sits in the subset that changes state in a live, often signed-in session: submitting a form, confirming a purchase, changing account settings, or entering credentials.
Classify by effect rather than by tool name. A click can be a scroll-like interaction on one page and the final confirmation of an order on the next. Tool names and descriptions rarely tell you which. The classifier needs the call's parameters and context, such as the target domain, the element being acted on, the form it belongs to, and whether the page is a checkout or account settings view.
A workable starting set of classes is: read-only navigation and inspection; non-committing interaction such as typing into a search box; form submission; purchase or payment confirmation; credential entry; and account or configuration change. The first two can usually run autonomously within a scoped domain list. The remaining four should be escalated or blocked. Anything the classifier cannot place should default to escalation.
Why client settings and prompts are not enough
Client-side confirmation prompts, tool allowlists, and system prompt instructions vary across clients and are easy to weaken. Users auto-approve tools to reduce friction, especially in multi-server setups. OWASP guidance is explicit that tool calls should never be auto-approved and that an available tool does not imply consent for a particular invocation.
Tool annotations are a weak foundation. Hints such as readOnlyHint and destructiveHint can change how a client handles approval, and a server can change them. A policy that trusts those flags inherits that weakness. Pin the full tool definition, including input schema, output schema, and annotations, and require re-approval when the hash changes. This also covers the pattern where a server behaves normally for several calls and then alters its metadata to steer the agent.
Page content is a second problem. A website is an indirect prompt injection channel, and tool output should be treated as untrusted data. A hidden instruction on a page can push the agent toward a submit or purchase click. OWASP states that prompt-level instructions alone are not a security boundary, so telling the model to ask first cannot be the control. The control has to sit in the component that performs the operation.
Where Trussed fits
Trussed enforces policy on MCP tool calls in the execution path. For a browser MCP server, that means each tool call is evaluated at runtime and can be allowed, redacted, blocked, rate limited, or escalated for human approval. Enforcement is at runtime, not reviewed after the fact. The scope is individual interactions and tool calls, which matches the approval gate described above. It does not provide transaction-level governance or end-to-end tracing of agentic workflows, so those needs call for separate controls.
Because the decisions are made by enforcement, the same mechanism generates audit-ready evidence of what was allowed, blocked, or escalated. Trussed is self-managed in the customer cloud, with configurable retention and data residency, which matters for a regulated enterprise that must keep that evidence under its own control.
The design in this guide holds whether or not you use Trussed. Start by classifying your browser calls by effect, pin tool definitions, and put the approval gate where the call executes. Then check that your enforcement point can bind approvals to the exact call and produce a record for every decision.
Approval path for a browser tool call
Label: Classify
Description: Label the call by effect, not by server-supplied hints.
Label: Decide
Description: Policy returns allow, block, or escalate.
Label: Approve
Description: A human approves the exact call, once.
Label: Execute
Description: The call runs only after an atomic approval check.
Label: Record
Description: Every decision is kept as evidence.
Put the approval gate in the execution path
See how policy on MCP tool calls can allow, block, or escalate browser actions and produce audit-ready evidence for each decision.
Request a DemoHow does your AI governance program compare?
See where your program has gaps in less than 2 minutes.