Use case · Instrumented boundary

Govern your browser and computer-use agents.

It clicked, it typed — but did the thing actually happen?

Computer-use and browser agents act by driving real apps: filling forms, clicking buttons, moving data between systems with no API in sight. That makes their claims the hardest to trust — and the most important to verify. GOVENANT records the action at the boundary and checks the downstream effect in the system of record.

Agent-agnostic by design

GOVENANT does not govern “Claude agents” or “OpenAI agents.” It governs the evidence trail of autonomous work. Keep the runner (the tool you audit from) separate from the system under audit (your agents):

What runs the audit

ClaudeChatGPTClaude CodeCursorCodexVS CodeWindsurfCline

An AI client you already use reads the open instrument and drives the read-only sweep. This is the runner — not the thing being judged.

What gets audited — incl. browser & computer-use agents

a browser agent (computer-use)a Claude/OpenAI computer-use agentan RPA-style UI automationa custom Playwright/Selenium agent

Any agent system with an observable record of actions and outcomes — whatever built it. The agent never has to "support GOVENANT."

Ground truth: the database + actions + outcomes + duties + gates — the substrate, never the logs’ self-report.

Why govern browser & computer-use agents

The least verifiable actions, made verifiable

UI automation has no clean return value — a click can “succeed” and change nothing. The standard ignores the click and checks the record: did the row appear, did the status change, did the effect land?

Govern the effect, not the pixels

GOVENANT operates at the action boundary and does not need the agent’s prompts, reasoning, or model — only an observable outcome. That’s exactly what makes it work for screen-driving agents no framework can hook.

Blast-radius under a gate

Computer-use agents can touch anything a human can. Register the consequential targets as levers with named owners; unowned or unexpected actions stop at the gate before they reach production.

Where this bites — a real scenario

An operations team runs a computer-use agent to move data between two systems that have no API — it drives the browser, fills the forms, clicks submit.

The challenge

The agent reports every step “succeeded,” but a click can succeed and change nothing. There’s no return value to trust and no way to know, from the agent’s own logs, whether the record actually landed in the target system.

What the record reveals

GOVENANT ignores the click and checks the effect: did the row appear in the target system, did the status change? The record shows a 6% silent-failure rate — forms that submitted “successfully” but wrote nothing — that no screenshot log would ever have caught.

How it works

The substrate: The downstream systems the agent touches: the record it created, the form it submitted, the value it changed — the effect, verified where it lands, not the screenshot of the click.

The path — Instrumented boundary: Add a thin hook at the action boundary — no access to prompts, reasoning, or models — so every action and its outcome is recorded.

  1. Instrument the action boundary: each attempted UI action is recorded with the outcome checked in the target system.
  2. Register consequential targets (systems, forms, records the agent may change) as levers with named owners and gates.
  3. Key completion to the verified downstream effect — the record changed — not “the step ran.”
  4. Run the read-only audit over the target systems’ records; review delivery vs. attempted actions and the miss log.
  5. Publish a defensible record; for screen-driving agents, verified effect is the only trustworthy metric.

The full requirements live in the open standard (CC BY 4.0) — the substrate shapes, the acceptance tests, and the conformance ladder your record is measured against.

What you can claim

A real integration wears the Built-on badge and publishes self-assessed levels with probe logs — open to challenge, never “certified.” For computer-use agents, a record that keys “done” to verified downstream effect is the difference between an impressive demo and a trustworthy operator.

Stacks that build browser & computer-use agents

Per-stack integration patterns for common ways to build browser & computer-use agents — each with its own natural hook into the substrate:

Building it a different way? Browse all integrations — or run the free audit from any MCP-capable tool.

Governing browser & computer-use agents — FAQ

My computer-use agent has no API to hook. Can it still be governed?
Yes — that’s the point. GOVENANT measures the effect in the systems the agent touches, not the agent’s internals. If the outcome lands somewhere you can read, it can be verified.
Does GOVENANT watch the screen or record the session?
No. It reads the outcome in the downstream system of record, aggregate-only. It never captures your screen, keystrokes, prompts, or credentials.
Do my agents have to “support” GOVENANT?
No. GOVENANT governs the substrate — the record of what agents did and whether it verifiably delivered — not the agent. If the system of record around your agents can be read, or you can instrument the action boundary, they can be measured, whatever framework, model, or vendor built them.
What is “performed autonomy”?
Agents that look busy — fluent plans, satisfied logs — but don’t verifiably ship. Motion is not delivery. GOVENANT measures verified outcomes against the record, never the logs’ self-report.
What is GOVENANT, and who controls it?
An open standard for provable AI agent governance: three laws, a conformance ladder, and acceptance tests any implementation runs against its own record. Free to all under CC BY 4.0, with a citable companion paper (DOI 10.5281/zenodo.21440225), conformance self-assessed and published openly — no certifying authority.

More agent use cases

All agent types · All integrations · Run the audit