Autonomous app walker

The autonomous walker explores a bounded portion of a web application’s UI in a managed tester VM. It records states, transitions, screenshots, console and network diagnostics, and deduplicated findings. It is useful for discovery; it is not proof that every route or behavior was tested.

Availability: the walker data plane, reports, authenticated profiles, bounded mechanical/AI/hybrid/task modes, safety controls, and scenario mining are implemented. A walk can still miss behavior because of its limits, dynamic UI, inaccessible labels, unavailable credentials, or model/parser error. Review its coverage before relying on the result.

Start safely

Use a non-production environment and a dedicated test account. Obtain a tester VM, then start with the default mechanical policy:


ensure_tester_vm(app="my-app", app_url="https://staging.example.com")

walk_app(
  app_name="my-app",
  app_url="https://staging.example.com",
  vm_name="<tester-vm>",
  max_states=40,
  max_depth=5,
  max_wall_seconds=600,
  destructive_allowed=false
)

walk_app returns immediately. Keep its walk_id, then poll get_app_walk(walk_id=...); call stop_app_walk if the run should end early.

Exploration modes

Mode	Behavior
`mechanical`	Bounded DOM-order traversal; no model ranking
`ai`	A model ranks candidate actions, then falls back when its call cap is reached
`hybrid`	Model ranking for the first configured states, then mechanical traversal
`cot`	Task-directed search with a decision cap and optional output schema

AI and hybrid modes fall back to mechanical when no supported model backend is available. Task-directed mode fails instead. Model-ranked actions remain subject to the same origin and destructive-action policy.

Safety controls

Destructive actions are skipped by default.
destructive_allowed=true permits only the guarded class; high-stakes labels remain blocked unless explicitly allowlisted.
Task-directed mode never accepts destructive_allowed=true.
Form filling avoids sensitive fields and blocks transactional submits.
Navigation is origin-limited; task mode may add an explicit bounded origin allowlist.
Authentication configuration contains secret variable names, not literal credentials. The scenario runner resolves values from the owner’s keystore.

An allowlist is an operator authorization decision. Use narrow literal labels, review the target environment, and prefer test data that can be discarded.

Reading the result

A completed walk reports what it actually observed:

visited UI states and transitions;
screenshots and interactive-element fingerprints;
console and meaningful network errors;
findings with severity, category, evidence, and a deduplication key; and
the configured state, depth, action, time, model, and safety limits.

completed means the frontier ended or a configured limit was reached without an internal error. It does not mean the application passed. Review blocker and major findings, skipped actions, authentication status, and coverage totals.

Authenticated walks

Prefer an encrypted browser profile when available. The legacy username/password flow accepts only keystore variable names. If sign-in fails or the expected post-login content is absent, the run records an authentication failure; do not interpret a walk of the login page as coverage of the product.

Turn discovery into regression tests

After reviewing a finding, save a deterministic app scenario for the affected flow. A mined scenario can be low-confidence unless the verification checkpoint passed, so inspect its steps before adopting it as a release gate.