One view across all your governed agents.
Multi-agent fleet governance. Register agents, monitor health, aggregate audit trails, compare policies. Centralized visibility, distributed enforcement.
Each ZLAR-governed agent runs its own gate and writes its own audit trail. That's correct — enforcement is distributed. But visibility shouldn't be. When something goes wrong, you need one answer: is the fleet healthy? What did it do today? Are all agents running the same policy?
ZLAR-FL answers from a single CLI. Register your agents once. Query the fleet from anywhere.
| Command | What it does |
|---|---|
| init | Initialize the fleet registry on this machine |
| register | Add an agent to the fleet (name, framework, audit path, policy path) |
| deregister | Remove an agent from the fleet registry |
| list | List all registered agents with status and framework |
| status | Health check across the fleet — gate running, audit reachable, policy valid |
| audit | Aggregate audit events from all agents — filter by time, domain, action, agent |
| report | Generate fleet-wide summary or per-agent reports |
| policy | Compare policy versions and rule hashes across agents — detect drift |
| topology | Print fleet topology — agents, frameworks, locations, policy status |
| update | Update agent metadata in the registry |
$ zlar-fl topology
ZLAR Fleet Topology
═══════════════════════════════════════════════════
dev-machine (localhost)
├── bohm [openclaw] ● running policy: v1.1.0 ✓
├── codex [claude-code] ● running policy: v1.1.0 ✓
└── cursor-agent [cursor] ● running policy: v1.1.0 ✓
build-server (192.168.1.42)
├── ci-agent [claude-code] ● running policy: v1.0.9 ⚠ drift
└── deploy-agent [cursor] ○ stopped
Fleet: 5 registered 4 running 1 stopped 1 policy drift
Policy drift detection compares the SHA-256 hash of each agent's active policy. Agents with matching hashes have identical rule sets. Drift means one agent is running a different policy — worth investigating.
Local agents only for audit aggregation. Remote agents appear in topology but audit trail aggregation requires local file access. SSH-based remote audit is planned for v2.
No real-time monitoring. FL reads audit files at query time. It does not stream events or alert in real-time.
Policy sync is manual. FL detects drift but does not distribute policy updates. Deployment is a human action.
Agents don't know they're in a fleet. FL provides observability, not control. It reads agent data — it does not modify agent behaviour.
Registry is not encrypted. The fleet registry contains file paths and hostnames. Do not store secrets or credentials in agent metadata.
| Product | Platform | What it does |
|---|---|---|
| ZLAR-OC | OpenClaw | OS-level containment — user isolation, kernel sandbox, pf firewall, gate daemon, signed policy, audit trail |
| ZLAR-CC | Claude Code | Hook-based gate — tool-call interception, risk classification, signed policy, Telegram approval |
| ZLAR Gate | Claude Code + Cursor + Windsurf | Universal gate — one policy across multiple editors, framework-specific adapters |
| ZLAR-LT | Claude Code + Cursor + Windsurf | Zero-config governance — one command, instant protection, deny-heavy defaults |
| ZLAR-AU | ZLAR Gate audit trail | Compliance reporting — hash chain verification, framework mapping, Splunk export |
| ZLAR-NT | Cross-platform | Network egress policy — destination-aware, domain-level, gate-integrated |
| ZLAR-FL | Cross-platform | Fleet governance — registry, health monitoring, audit aggregation, policy comparison |
Built by Vincent Nijjar and ZLAR Inc.
Open source under Apache License 2.0. Free to use, modify, and distribute.