Local Guard

Free, local-only PDLSS verification for AI agents — YAML policy, adapters for Claude Code, CLI, Cursor, and browser agents.

A free, local-only verification layer for AI agents. Define what your agent can and cannot do in a simple YAML policy file, and Local Guard enforces it — no account, no cloud connection, no telemetry. When you outgrow local mode, one command upgrades you to cloud-connected verification.

Step 1: Create Your Policy

The proxy and IDE adapters below share one PDLSS policy file (local-policy.yaml). Create it once, then choose which adapter to run for your platform. (The Claude Code adapter manages its own .astrasync/policy.yaml — same schema, created for you at install.)

npm install @astrasyncai/verification-gateway

# Interactive wizard — creates local-policy.yaml
npx astrasync guard setup

The wizard asks plain-language questions about what your agent should be allowed to do and generates a local-policy.yaml file using the same PDLSS schema as the cloud — so upgrading later requires zero migration.

Step 2: Choose Your Adapter

Each adapter is a thin, platform-specific wrapper that intercepts agent actions and routes them through the shared PDLSS evaluation engine. The verification logic is identical across platforms — only the interception and enforcement mechanisms change.

Local Guard for Claude Code — Available

Native PreToolUse hook — no proxy. Every tool call (file, shell, web, and optionally MCP tools) is evaluated against your policy before it runs. One command installs the hook, a default policy, and guard settings.

# User-level (add --project for repo-scoped)
astrasync-guard install-claude-code

Local Guard for OpenClaw CLI — Available

HTTP proxy that sits between OpenClaw (or other CLI agents) and their tool servers. Intercepts tool call JSON, evaluates against your PDLSS policy, then blocks or forwards. (Claude Code users: prefer the native hook adapter — no proxy needed.)

# Start the CLI proxy (uses your local-policy.yaml)
npx astrasync guard start

Local Guard for Cursor — Available

VS Code extension that hooks into file create/delete/save, terminal open, and command execution events. Download the .vsix from GitHub releases and install directly.

# Download .vsix from GitHub releases, then:
code --install-extension astrasync-local-guard-2.0.0.vsix

Local Guard for OpenClaw Browser — Available

Chrome extension for the OpenClaw browser agent. Intercepts web requests and navigation before they execute, with synchronous local evaluation for zero-latency blocking.

# Download extension from GitHub releases, then:
# Chrome → Extensions → Developer mode → Load unpacked

CLI Commands

Postures & traces (all adapters)

Adapters that enforce inline (the Claude Code hook today) start in "posture": "passive": every decision is evaluated and written to a local JSONL trace under .astrasync/traces/, but nothing is blocked. Watch the traces until the policy looks right, then set "posture": "active" in guard.json to enforce — denies block the action with a reason, approval-band actions route to the platform's own permission prompt.

Safe by default: a machine with no policy file is a silent no-op, and a corrupt guard.json falls back to enforcing defaults rather than silently loosening the guard. Set "governMcp": true to govern MCP tools too (rules keyed as {server}.{tool}).

Fleet mode (organisations)

With Workforce Guard or Enterprise Governance, an organisation runs Local Guard on every developer machine under one central policy. Enrolled machines enforce the organisation's policy instead of any local policy.yaml or guard.json, and developers can't switch it off.

1. Publish a fleet policy. In the dashboard, open Enterprise Governance → Fleet policy, write the policy (same YAML schema as local mode) and choose the posture. Every change goes through a change request under your organisation's approval rule. Publishing the first policy also creates your organisation's own signing key.

2. Enrol machines. Create an enrolment token (confirmed with your passkey), then run on each machine. Two options:

# One user on this machine (default) — no administrator rights needed
npx @astrasyncai/verification-gateway guard enroll <token>

# The whole machine, every user — needs administrator rights (typically pushed by your MDM)
npx @astrasyncai/verification-gateway guard enroll <token> --system

3. Lock it in (recommended). Deploy the managed settings so the hook can't be removed or bypassed:

npx @astrasyncai/verification-gateway guard managed-settings --claude --codex --out ./mdm

What enrolled machines do:

• Enforce only the signed organisation policy. Local policy files, ASTRASYNC_GUARD_DISABLE, ASTRASYNC_GUARD_FAIL_OPEN and the passive default are ignored.
• Verify the policy's signature against your organisation's key, recorded when the machine enrolled. A policy signed for another organisation, edited on the machine, or older than the one already in force is refused.
• Fail closed: with no valid signed policy, tool calls are blocked, never allowed.
• Check in at most once per interval (never delaying a tool call), pick up new policy versions automatically, and keep enforcing the last good policy if the machine is revoked or offline.

Signing key. Your organisation has its own key; AstraSync keeps it in its vault and it is never shown. Admins can Rotate key in the Fleet policy tab (with a passkey): enrolled machines switch to the new key at their next check-in without re-enrolling, and stop trusting the old one. If you think a key was exposed, rotate it and check under Machines that every machine has checked in since.

Machines. The Fleet policy tab lists each enrolled machine with its policy version, posture and last check-in. Revoking a machine stops it receiving updates; machines that stop checking in or fall behind the current policy raise an alert.

Agents on enrolled machines. An enrolled machine's device credential also lets an agent running there sign in to its owner's dashboard (astrasync guard browse, see Agent Dashboard Sign-In) and route git through the checkpoint (astrasync guard git-route).

Workforce Guard checkpoint

With Workforce Guard, each agent can run through a checkpoint: a per-agent URL in your organisation's Workforce Guard that governs the agent's calls to the services you allow, and answers the agent's runtime challenges for calls made through it — no endpoint of the agent's own is needed.

Turning it on. When registering an agent, people seated in an organisation with Workforce Guard see Run this agent through Workforce Guard. The agent then belongs to that organisation (if you are in several, you choose which). The checkpoint follows the agent through an Upgrade, at the same URL.

Checkpoint URLs — one per allowed upstream, shaped by the upstream's type:

Treat the URL as a secret — anyone holding it can route calls through that agent's checkpoint. Calls authenticate with the connector's bearer token (Authorization: Bearer <token>, shown once when the connector is created), or, from a machine enrolled in your fleet, with its device credential. Calls without either are refused with 401.

On each connector in the dashboard:

• Challenge responder: working / not working — a self-test that sends a challenge to the checkpoint's public URL, the same path a real challenge takes. Test again re-runs it.
• Reset bearer token — issues a new token; the old one stops working straight away.

Calls the agent makes directly (not through the checkpoint) are challenged at the agent's own handler; an agent with no handler of its own fails the challenge on direct calls, because they bypassed governance.

Free vs Paid

Local Mode (Free — free forever)

• Local PDLSS policy evaluation (<1ms)
• Interactive setup wizard
• CLI, IDE, and browser platform support
• JSONL audit trace (local file)
• No account required, fully offline

Online / Hybrid Mode (Paid)

• Everything in Local Mode
• ASTRA-ID and trust score for your agent
• Cloud PDLSS boundaries with counterparty verification
• Runtime challenge/response (proves agent identity)
• Blockchain-secured audit trail
• Git push / PR trigger for enterprise governance

Enterprise: Git Push Trigger

In hybrid mode, Local Guard runs locally during development but automatically switches to cloud verification when code is pushed to a remote repository or a PR is created. This creates a governance boundary: local guardrails for development, full AstraSync verification for anything that reaches the remote codebase.

# Install git hooks for your repo
npx astrasync guard install-hooks

# Hooks auto-trigger on:
# - git push (pre-push hook)
# - git commit to protected branches (pre-commit hook)
# - Block or warn mode configurable per branch