Agent Tool Governance: MCP, Browser/Computer Use, and Verifiable Security Boundaries

Once an agent is connected to tools, the dangerous mistake is to equate “it can discover and call a tool” with “it is correctly authorized and safely completed the task.” MCP, Browser Use, Computer Use, terminals, and internal APIs move a model from text answers to external side effects. Protocols, tokens, prompts, approvals, sandboxes, and verifiers solve different problems. A credible agent environment needs to express those boundaries as an executable contract that can be accepted under normal tasks, attacks, and faults alike.

1. Five Layers That Are Easy to Conflate and Must Stay Separate

The MCP Tools specification defines tools that models can discover and call, while advising hosts to obtain user consent, treat arbitrary code execution as high risk, and regard tool descriptions from untrusted servers as untrusted. MCP’s Authorization specification defines HTTP-transport flows including resource metadata discovery, token-audience validation, and binding to the target resource. These are important foundations, but neither proves that a particular business action ought to occur.

2. Three Missing Gates Between Protocol Connection and Real Execution

A. Tool Metadata Is Not a Trusted Instruction

Tool names, descriptions, schemas, returned text, and web content all enter an agent’s observation space. They can help planning, but may also carry instructions to call a different tool, escalate parameters, or exfiltrate data. MCP security guidance names token passthrough as an anti-pattern and requires a server to accept only tokens issued for it; that resolves token-audience and proxy-confusion problems, not a malicious tool response. MCP Security Bench places name collisions, description injection, out-of-scope parameters, and tool transfer into an end-to-end tool pipeline. It is preprint evidence that planning, invocation, and response handling should be evaluated separately.

Environment implication. Each observation should carry a source label: user_instruction, trusted_policy, tool_metadata, tool_output, web_content, file_content, or agent_memory. A label is not a line of prompt advice; it is a field readable by a policy engine, logged, and rejectable. The agent may read untrusted content without that content gaining authority to set a new goal, permission, or credential.

B. A Valid Token Is Not Approval of a Business Action

MCP authorization requires a token for the intended audience. Its security guidance also covers confused deputies, SSRF, scope minimization, and minimum privilege for local servers. These rules constrain who reaches a resource; they do not decide whether transferring money, deleting a file, or sending an email serves the user’s present intent.

An agent host therefore needs an action-layer permit binding task id + principal + tool version + parameter digest + requested capability + expiry + approval state. High-risk or irreversible calls cannot rely only on a model’s natural-language judgment. They should wait for explicit confirmation, use short-lived narrow-scope capability, and write the grant plus result to a trace. Browser Use’s human-in-the-loop documentation demonstrates handoff in a live browser session. It shows that approval can be part of a workflow; it does not show that one click covers every later side effect.

C. Tool Success Is Not Backend Completion

A 200 OK, browser screenshot, visible toast, or changed URL may only say that a frontend path was reached. Alone, it does not prove that a backend write, account state, amount, permission, inventory, or file satisfies the task postcondition. For web and computer tasks, an action trace should be distinct from sidecar evidence: the sidecar checks a declared server-side postcondition read-only, in a domain the candidate cannot write.

This is also why prompt injection cannot be reduced to “does the model obey?” AgentSecBench separates instruction integrity, retrieval confidentiality, and capability integrity in controlled experiments, distinguishing policy projection, capability restriction, and output validation from prompt annotation alone. Its narrow result is that text can describe a boundary; enforcement needs mechanisms outside model generation.

3. An Implementable Tool-Governance Contract

This is not a claim about capabilities already shipped by an existing system. It is a minimum contract that ClawBench V2, WebsiteBench, or any self-hosted agent environment can adopt.

For local MCP servers, security guidance also requires sandboxing and minimum file, network, and process authority. For remote OAuth discovery, the host must account for SSRF and redirect risk. These belong in the environment image and launch policy, not a footnote. The OWASP AI Agent Security Cheat Sheet consolidates untrusted input, least privilege, memory isolation, action confirmation, and adversarial testing as deployment advice. It is a threat checklist, not evidence that any benchmark is already secure.

4. Make Security a Decidable Task, Not One Guard Score

Every normal task should have a paired adversarial control. A minimal evaluation matrix follows.

Report normal-task success, attack success, false blocks, cost per verified success, and maximum side-effect scope together. A guard detection score omits normal work that it blocks and backend harm after an agent bypasses it. Conversely, business success alone makes a safety policy look like mere friction instead of an independent correctness condition.

5. Three Baselines That Must Not Be Blended

To study a governance design, compare under the same model, harness, task, budget, and tool set:

1. No-governance baseline: only for measuring raw behavior; it must never reach a real sensitive service, and every effect stays in a rollback-capable sandbox.
2. Prompt-only baseline: rules exist only in system prompts or tool descriptions, exposing both the limits of textual reminders and the cost to normal tasks.
3. Enforced-policy system: host-side capability grants, parameter validation, network/file sandboxing, pre-commit interception, and a sidecar verifier are all enabled.

Only when the third system reports a benefit on held-out normal and adversarial distributions can one discuss the net effect of governance. In training, policy version, refusal traces, blocked observations, and action masks belong to the rollout distribution. Changing them is not “only adding a guard.”

6. How It Returns to the Core Five

This note pairs with Agent Research Environments: the environment note defines task, harness, sandbox, and verifier; this one joins tool discovery, authorization, runtime authority, browser/computer side effects, and independent acceptance into one control chain. For long-run checkpoints and recovery, see Long-horizon agents; for the 32-lane adjacent-direction map, see Hot Agent Directions.