What AgentGuard proves today.
AgentGuard separates current compatibility telemetry from the stronger executor-owned broker proof it is designed to earn. A same-UID configured intercept exists for one named GitHub file write; see the named-action proof. Capability isolation and firewall results are not claimed, and no GO decision has been recorded.
Firewall proof
This tier is eligible only when an executor-owned MCP-stdio broker alone holds the raw capability. OpenClaw must see only the mediated proxy tool, while the broker owns policy evaluation, one-use permits, dispatch, replay state, and durable decision and outcome evidence.
This proof is pending. It requires current, dated evidence for the exact broker artifact, host topology, action, and bypass probes before AgentGuard can publish a scoped firewall-proof result. It would not prove that every possible process or path on a host was unable to act.
Compatibility
The current OpenClaw before_tool_call hook, TypeScript and Python in-process integrations, and MCP HTTP/in-process adapters are compatibility telemetry. They can evaluate policy and record a decision, but they do not own the raw capability and can be disabled or bypassed by a caller that retains another route.
Current published packages are TypeScript @the-bot-club/agentguard@0.11.2 and Python agentguard-tech==0.11.2. strict: false allow-on-error is a hard startup error. OpenClaw plugin metadata is 1.0.0 using /v1/openclaw/intercept; the MCP compatibility route is /v1/mcp/intercept. These are compatibility artifacts, not executor-owned broker proof.
Boundary limits
- Attacker and host. The intended proof covers an unprivileged OpenClaw identity with no raw credential, client, or alternate unmediated path. It does not cover a malicious administrator, physical compromise, or full-host compromise.
- Outcome. A receipt states only what the named broker dispatcher did or did not dispatch. It is not a universal claim that no other host path executed an action.
- Keys. The V1 contract requires broker-only OS custody, bounded file permissions, and key-bound verification. That custody is a later implementation requirement; hardware, tamper, admin, and physical protection are not claimed.
Failure and recovery
Missing, invalid, stale, revoked, timed-out, replayed, or unwritable policy and evidence states deny permit issuance and broker dispatch. In V1, require_approval records a blocked result and does not continue to dispatch. Missing or unknown outcome evidence cannot authorize an automatic retry.
Normal recovery has no ordinary off mode. It uses a current verified last-known-good artifact or scoped emergency deny. Any exceptional bypass is expiring, dual-controlled, audited, limited to known low/medium read-only operations, and excluded from proof.
Contract sources
Review the checked-in assurance tiers, key lifecycle, failure matrix, and rollback states. These contracts define intended V1 behavior; they do not by themselves establish that the broker topology is implemented or proven.