TL;DR: Web and browser agents can appear successful while clicking the wrong element, stopping early, or extracting values that never appeared on page, so Braintrust argues evaluation must score trajectory, state changes, and final output together. The underlying issue is not just response quality but grounded browser behaviour, which is now a governance problem for agentic AI systems.
At a glance
What this is: This guide explains how to evaluate web and browser agents by tracing actions, page state, and outcomes rather than judging only the final response.
Why it matters: It matters to IAM and agentic AI teams because browser agents can misuse delegated access, mis-ground page elements, and create false completion signals that hide control failures.
By the numbers:
- The average success-rate decrease was 31.6% from easy to medium tasks, followed by a further 15.4% decrease from medium to hard tasks.
- WebJudge variants reported overall precision of 73.7%, 75.7%, and 82.0% in AgentRewardBench.
👉 Read Braintrust's guide to evaluating web and browser agents
Context
Web and browser agents introduce a governance gap that response-only evaluation cannot close. A task can end with a convincing answer even when the agent clicked the wrong control, repeated steps, or extracted a value that was never grounded in the page state. For IAM and agentic AI programmes, that creates a familiar identity problem: delegated access exists, but the system that exercises it may not be acting on the intended resource or data.
The article is primarily about evaluation design, but the security implication is broader. Once an AI agent can navigate a browser, its behaviour depends on how well the organisation traces the action chain behind each outcome. That makes page state, grounding, and step-level evidence part of the control surface, not just the model output. In practice, this is typical for browser-based automation and should be expected wherever agents operate across changing web interfaces.
Key questions
Q: How should teams evaluate browser agents that can complete a task with the wrong click path?
A: Use a contract that scores both the end state and the trajectory that produced it. A passing result should show the agent selected the right element, changed the right page state, and reached a verifiable outcome. Otherwise, a plausible response can hide a grounding error that will reappear in production.
Q: Why do web agents create more governance risk than standard LLM outputs?
A: Because they act on a live interface, not just on text. The browser session can change state, consume delegated access, or trigger side effects even when the final response looks correct. That means governance must cover action tracing, page evidence, and completion verification, not only output quality.
Q: What breaks when browser-agent traces do not include page state and action history?
A: You lose the ability to tell whether a failure came from the model, the website, or the execution layer. Without step-level evidence, stalled runs, wrong-element clicks, and silent no-ops all look similar. That makes debugging slower and lets brittle automation pass evaluation.
Q: How should organisations validate browser-agent success before production release?
A: Require an independently verifiable end state such as a confirmation number, final URL, or written record, and compare it with the trace. If the run only looks successful in the response text, it should fail. That prevents false completion claims from entering release criteria.
Technical breakdown
Why browser grounding changes evaluation
A browser agent does not just generate text. It interprets screenshots, DOM snapshots, or accessibility trees, then chooses clicks, typing, and navigation actions that change the next state it can observe. That makes evaluation different from standard LLM scoring, because the quality of the final response depends on whether the agent grounded the correct page element and preserved task state across steps. Site markup can change between runs, so the same prompt may reach different outcomes even when the model is unchanged.
Practical implication: score the action chain and the resulting page state, not only the final answer.
Trace evidence and step-level scoring
Reliable evaluation needs enough trace data to reconstruct what the agent saw, what it selected, and what changed after execution. That usually means recording the observation boundary, the action boundary, the post-action state, and any browser error. Step-level scoring can then separate wrong-element clicks, stale selectors, loops, partial completion, and extraction errors. When those signals are combined, teams can tell whether a failure came from the model, the page, or the execution environment.
Practical implication: capture screenshots or DOM snapshots together with structured action metadata and post-action results.
Loop detection, trajectory efficiency, and verified completion
A long trajectory is not automatically a failure, but repeated navigation without progress, dead waiting, or oscillating between pages usually indicates a control issue. Completion should be verified with evidence the agent does not invent, such as a confirmation number, a final URL, or a written record in a test system. That matters because a browser agent can claim success while the underlying task remains incomplete. Good scoring therefore distinguishes efficient completion from merely plausible completion.
Practical implication: require an externally verifiable end state before passing the run.
NHI Mgmt Group analysis
Browser agents create a delegated-access problem, not just an evaluation problem. When an agent can click through a live interface, the security question becomes whether the system grounded the right action against the right page object. That is close to an identity governance issue because the agent is operating with borrowed authority inside a browser session. If the trajectory is not traced, the organisation cannot prove that the delegated action matched the intended control boundary.
Action-level traceability is the control concept that matters here. The strongest insight in this guide is that a final response can be correct while the browser behaviour is wrong, which means response-only metrics miss a real failure mode. In practice, that is a governance blind spot for agentic AI programmes that rely on task completion as the only success signal. Teams should treat trace evidence as part of the control plane, not as optional observability.
Trajectory efficiency is becoming a named risk area for agentic systems. Repeated steps, stalled execution, and environment drift all raise cost and exposure while masking whether the agent actually understood the task. That matters across IAM and broader automation because a weak evaluation contract can approve brittle behaviour that later reaches production. The practitioner takeaway is simple: measure the path as carefully as the destination.
Browser agent evaluation should be aligned with identity and access governance wherever tasks touch authenticated systems. If a web agent can submit forms, change records, or extract data through a logged-in session, its actions sit inside the same risk perimeter as other privileged workflows. This is where agentic AI security intersects with IAM, because the organisation must govern what the agent may do, how it is traced, and when a run is considered valid. Practitioners should connect evaluation design to access policy and audit expectations.
Grounding failures are the browser equivalent of false confidence in automation. A system that reports completion without verifying the page state can create a stable-looking but incorrect control outcome. That is especially important for enterprises building regression datasets from production failures, because the dataset only improves governance if each failure is classified against the real browser behaviour. The field needs more than benchmark scores; it needs reproducible evidence.
What this signals
Trajectory evidence is becoming a governance control, not a debugging convenience. As browser agents move deeper into business workflows, teams will need to decide whether an action path was acceptable, not just whether an answer looked right. That makes evaluation design part of access governance for AI systems that operate inside authenticated sessions.
The practical signal for IAM and AI security teams is that agent behaviour must be measured against page state, output state, and verified completion. Where browser automation touches sensitive systems, traceability becomes the bridge between agent testing and audit readiness. For broader context on machine identity and delegated access, see the Ultimate Guide to NHIs.
Action-level grounding will define the next generation of agent controls. If organisations cannot show what the agent observed, what it chose, and what changed after execution, they cannot reliably govern browser-based AI. That is especially true when OWASP Agentic AI Top 10 risks such as tool misuse and agent hijacking are in scope.
For practitioners
- Score the full browser trajectory Record the task, every observation, each selected action, and the resulting page state so you can separate grounding failures from execution failures and response hallucinations.
- Require external completion evidence Pass runs only when the final URL, confirmation number, database row, or other independently verifiable signal proves the task reached the intended end state.
- Separate action correctness from element grounding Check whether the action type was right first, then verify that the chosen element, typed value, or selection matched the intended target in the trace.
- Treat page drift as an evaluation variable Version browser fixtures and re-run failed cases against pinned environments so you can distinguish model regression from site markup changes or A/B test drift.
- Build regression sets from verified failures Promote only confirmed failures into the dataset, then label them by wrong click, stale selector, loop, partial completion, or wrong extraction to improve scoring precision.
Key takeaways
- Browser agents can appear successful while taking the wrong action path, which makes response-only evaluation insufficient.
- Step-level traces, page state, and external completion evidence are the minimum requirements for reliable agent governance.
- For IAM and agentic AI teams, evaluation now doubles as an access-control problem because browser agents act inside delegated sessions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Browser agents face grounding, tool misuse, and trajectory risks covered by agentic AI guidance. | |
| NIST AI RMF | MEASURE | The article is fundamentally about measuring and validating AI system behaviour. |
| NIST CSF 2.0 | GV.OC-01 | Evaluation quality affects how the organisation defines and governs the AI operating context. |
| NIST SP 800-53 Rev 5 | AU-6 | Audit-style evidence and review are central to reconstructing browser-agent actions. |
| MITRE ATT&CK | TA0007 , Discovery; TA0006 , Credential Access | Browser agents operate in environments where wrong actions and credentialed sessions affect attack surface. |
Document browser-agent use cases, success criteria, and failure tolerances in governance and oversight processes.
Key terms
- Browser Agent: A browser agent is software that can navigate websites and complete browser-based tasks on behalf of a person or system. In identity terms, it is an execution identity that may inherit access, session state, and trust boundaries that were previously assumed to belong only to humans.
- Agent Grounding: Agent grounding is the process of giving an AI agent enough trusted context to choose and execute actions safely. In practice, it depends on accurate metadata about meaning, freshness, sensitivity and permitted use, so the agent does not improvise from incomplete information.
- Trajectory Efficiency: Trajectory efficiency measures whether the agent reached the required end state without unnecessary repetition, detours, or stalled execution. It helps teams distinguish a successful route from a brittle one and exposes cases where the model appears functional but wastes steps or loops without progress.
- Verified Completion: Verified completion is the requirement that a browser-agent run proves task success through external evidence, not just a confident response. Common evidence includes a confirmation number, a final URL, or a record written to a controlled system, which prevents false success claims from passing evaluation.
What's in the full article
Braintrust's full guide covers the operational detail this post intentionally leaves for the source:
- Code examples for action-type and action-value scorers used in browser-agent evaluation
- Trace structuring patterns for screenshots, DOM snapshots, and browser execution spans
- Browserbase and Browser Use instrumentation details for production-style agent traces
- Dataset and regression workflow examples for turning confirmed failures into repeatable eval cases
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management with a practitioner focus. It helps identity and security teams build stronger control thinking for delegated systems, including agentic AI workflows.
Published by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org