A policy-based firewall gateway guarding the boundary between AI agents and production systems.
Honmoon is a security gateway that intercepts an AI agent's network traffic (e.g. Claude Code, automated workflows) and applies policy before requests reach their destination.
It unifies two layers of protection:
- Egress domain filtering — restrict outbound HTTP/HTTPS traffic with a domain allowlist/denylist (the gh-aw-firewall approach)
- Protocol-aware policy engine — parse protocols such as SQL, Kubernetes, and HTTP at the wire
level to apply fine-grained rules (
deny/approve) (the clawpatrol approach)
Honmoon (혼문, 魂門) borrows from Korean lore popularized by KPop Demon Hunters: a protective barrier woven to seal the human world off from the demon world. The metaphor fits — Honmoon is the barrier you raise between your AI agents and production systems, letting only what your policy permits cross over.
AI agents run shell commands, call APIs, and access databases. That power is also a risk —
a single bad inference can trigger unintended data exfiltration, destructive queries (DROP TABLE),
unauthorized Kubernetes resource deletion, or tokens sent to a private endpoint.
Honmoon runs the agent inside an isolated network boundary and inspects, allows, blocks, or holds every outbound connection according to declarative policy.
┌─────────────┐ ┌──────────────────────┐ ┌─────────────────┐
│ AI Agent │─────▶│ Honmoon Gateway │─────▶│ External World │
│ (sandboxed) │ │ policy engine + CEL │ │ APIs / DB / K8s │
└─────────────┘ └──────────┬───────────┘ └─────────────────┘
│
allow / deny / pause(approval)
│
audit log ──▶ dashboard
- Declarative policy — domain allow/deny in YAML, validated by JSON Schema
- CEL conditions — fine-grained rules over protocol facts (SQL verb/table, K8s resource/namespace, HTTP method/path)
- Three verdicts —
allow·deny·pause(wait for human approval) - Protocol-aware parsing — extract protocol facts at the wire level without decryption
- Flexible isolation modes — process wrapper / gateway / tunnel join
- Audit log & dashboard — record every verdict, with an approval workflow UI
- API credential isolation (optional) — a sidecar that keeps LLM API keys away from the agent process
Honmoon is a monorepo that separates languages by responsibility.
| Layer | Language | Responsibility |
|---|---|---|
| Data plane | Rust | Wire-level proxy, protocol parsers, TLS (rustls), CEL evaluation — performance & safety critical |
| Control plane | TypeScript (Bun) | honmoon CLI, policy compiler/validation, management & audit API |
| Dashboard | React + Vite + Tailwind (Bun) | Audit log viewer, policy editor, approval workflow UI — embedded into the Rust binary |
| Egress backend (optional) | Squid (Docker) | Alternate backend when a battle-tested HTTP proxy + SSL Bump is required |
The TypeScript side (control plane + dashboard) standardizes on Bun as runtime and package manager. The dashboard is built with Vite and statically embedded into the data-plane binary via
rust-embed, served directly by the management API. (Mirrors clawpatrol's React dashboard setup.)
| Mode | Command | Description |
|---|---|---|
| Process Wrapper | honmoon run -- <command> |
Isolate a single process in a network namespace (Linux netns / macOS NetworkExtension) |
| Gateway | honmoon gateway |
Central proxy that loads policy and accepts client connections |
| Join | honmoon join |
Route all host traffic to the gateway through a tunnel |
honmoon-mono/
├── crates/ # Rust — data plane
│ ├── honmoon-core/ # policy engine, CEL evaluator, facts model, audit log
│ ├── honmoon-proxy/ # wire-level proxy, protocol parsers, approval registry
│ ├── honmoon-mgmt/ # management API (axum) + embedded dashboard (rust-embed)
│ └── honmoon-cli/ # `honmoon` binary (run / gateway / join)
├── packages/ # TypeScript (Bun) — control plane
│ ├── policy/ # policy schema, JSON Schema, runtime decision model
│ ├── cli/ # Bun-distributable wrapper CLI
│ └── api/ # durable JSONL audit-log query API
├── apps/
│ └── dashboard/ # React + Vite + Tailwind SPA (Bun) — embedded into Rust
├── deploy/
│ └── squid/ # optional Squid egress backend (Docker Compose)
├── policies/ # example policies
└── docs/ # design docs, policy reference
A simple egress allowlist (the common case):
# policies/agent.yaml
version: 1
egress:
default: deny
allow:
- github.com
- '*.githubusercontent.com'
- api.anthropic.com
deny:
- '*.internal.corp'Protocol-aware rules using CEL:
rules:
- name: k8s-no-secret-delete
endpoint: k8s-prod
condition: "k8s.resource == 'secrets' && k8s.verb == 'delete'"
verdict: deny
- name: sql-no-prod-drop
endpoint: postgres-prod
condition: "sql.verb == 'DROP' || sql.verb == 'TRUNCATE'"
verdict: pause # requires human approval
- name: http-block-large-upload
endpoint: '*'
condition: "http.method == 'POST' && http.body_size > 10485760"
verdict: deny# Run a single command in isolation — only allowed domains are reachable
honmoon run --policy policies/agent.yaml -- curl https://api.github.com
# Run the gateway: egress proxy on :8443, management API + dashboard on :8444
honmoon gateway --config policies/agent.yaml --audit-log honmoon-audit.jsonl
# proxy: http://127.0.0.1:8443 (point https_proxy here)
# dashboard: http://127.0.0.1:8444 (audit log, approval queue, policy)
# Join a gateway from a client (routes all host traffic)
honmoon join --gateway honmoon.internal:8443When a request hits a pause rule the gateway holds the connection and surfaces it
on the dashboard's approval queue; approving it lets the request through, denying
it returns 403. Every verdict is recorded in the audit log.
⚠️ Early design stage. The following describes the target workflow.
Prerequisites
- Rust (stable)
- Bun 1.x
- (optional) Docker 20.10+ & Compose v2
# Rust data plane
cargo build --workspace
cargo test --workspace
# TypeScript control plane + dashboard
bun install
bun run build # build dashboard (Vite) + control plane
bun test
# Dashboard dev server (HMR) — proxies /api to a local gateway on :8444
cd apps/dashboard && bun run devThe dashboard is embedded into the
honmoonbinary viarust-embed, so build it (bun run --filter @honmoon/dashboard build) before a releasecargo build. A barecargo buildwithout a dashboard build still succeeds —honmoon-mgmt'sbuild.rsdrops in a placeholder so the binary always links.
Full phased roadmap (OSS / paid boundary, exit criteria): docs/roadmap.md.
- Scaffold the Rust data plane (
crates/) - Phase 1 — HTTP egress MVP: terminating CONNECT proxy + domain allowlist (ADR-0002)
- Phase 2 — CEL evaluator + HTTP facts
- Phase 3 — SQL / Kubernetes protocol parsers
- Phase 4 —
pauseapproval workflow + audit log + dashboard - Phase 5 — content-aware PII / DLP: body inspection + Korean-first PII detection (benchmark goals)
- Phase 6 — isolation modes (
run/gateway/join) - Phase 7 — team control plane (paid)
- Phase 8 — hosted SaaS & intelligence (paid)
Honmoon unifies the approaches of two projects:
- github/gh-aw-firewall — Squid-based egress domain filtering
- denoland/clawpatrol — wire-level, protocol-aware policy gateway
TBD