OpenFang: The Gatekeeper and the Narrow Gate
Draft — S5.3 · series: CONTENT-ROADMAP-99 S5 (The Council System) · status: DRAFT · grounding: wiki openfang + narrow-gate-principle + council-of-three + the-9-orders + multi-profile-agent-architecture + concepts credit-safe-architecture + faengz-doctrine + skills (moses-governance, kanban-orchestrator) · tags: ai-agents, security, openfang, narrow-gate, council-system, digital-architecture, autonomous-operations, mcp-protocol, gatekeeper, tool-routing Publish path: new post → lucidhive.com → tag + bridge.
The previous article described how a single kanban board coordinates 42-plus profiles without zombie processes or lost handoffs. But coordination without security is just organized chaos. The question that remains is: when an agent reaches for a tool — a web search, a file write, an API call — what stops it from doing something the Council never authorized?
The answer is OpenFang. The Cube. The Earth core. Order 2 in the 9 Orders of the Council. It is the security guardian that every tool call in the fleet must pass through, and it enforces a principle the Council calls the narrow gate: unified calls or none at all.
What OpenFang is
OpenFang is a Rust-based process running on port 7076. Within the Council hierarchy, it occupies Layer 1 — the same layer as OpenClaw and ZeroClaw, the three specialist parent agents beneath Hermes. But OpenFang’s role is different from its siblings. Where OpenClaw creates and ZeroClaw builds, OpenFang permits. It is the sole MCP server for the entire Council. Every agent in the fleet — parent, child, and microshark — routes every tool call through this one server. There is no second server. There is no fallback. There is no direct path from an agent to the outside world that does not pass through OpenFang’s policy checks first.
This is not an implementation preference. It is a doctrinal requirement. The Faengz Doctrine — the manifesto that governs the Council — declares that unified calls or none at all. OpenFang is the concrete expression of that declaration: the place where doctrine becomes executable code, and where every tool request is inspected before it is allowed to proceed.
The narrow gate principle
The narrow gate is the architectural principle that nothing touches the outside world except by the gatekeeper’s leave. In practice, this means every tool call — file_read, web_search, browser_automate, security_scan — must be routed through OpenFang’s MCP endpoint. The agent asks; OpenFang inspects; OpenFang decides.
The gate is narrow by design. A wide gate — one that lets agents call tools directly, or that provides fallback servers for “reliability” — fragments the security boundary. Agent A talks to Server 1; Agent B talks to Server 2. Server 1 enforces budget caps. Server 2 doesn’t. Agent B burns credits while Server 1’s dashboard shows green. The Council cannot govern what it cannot see, and visibility requires singularity.
The narrow gate solves this by making OpenFang the single audit point. When MOSES — the governance layer — needs to enforce a policy, it injects that policy into OpenFang’s request pipeline. One check point means one enforcement point. One enforcement point means the Council can answer a question most agent architectures cannot: what is every agent in the fleet doing right now, and who authorized it?
The 16 security layers
OpenFang does not simply forward tool calls. It inspects them through a stack of security mechanisms that agents never see but always experience:
- env_clear. Every tool call executes in a sanitized environment. Credentials, API keys, and ambient variables from the parent process are stripped. An agent cannot leak secrets through a tool call because the tool call never sees them.
- Loop guards. A 60-second timeout kills any tool call that runs too long. Infinite loops — the most common failure mode in autonomous agents — are caught at the gate, not after they’ve consumed a budget.
- Taint tracking. Data flowing through OpenFang is tagged with its origin. If an agent passes externally-sourced input into a file write, the taint layer knows. This prevents injection attacks that skip the agent’s own reasoning.
- SSRF protection. Requests to internal network addresses — localhost, private ranges, cloud metadata endpoints — are blocked. An agent cannot use a tool call to reach services it was never authorized to touch.
- Budget enforcement. Hard token limits per task, per agent, and per session are enforced at the gate. When a budget is exhausted, OpenFang blocks further calls. The agent does not get a warning; it gets a wall.
These are not features bolted on after the fact. They are the reason the gate exists. An agent that can call tools directly is an agent that can burn credits, leak credentials, or attack internal services — and the operator finds out after the damage is done. An agent that calls through OpenFang is an agent whose every tool request is inspected, logged, and governed before execution.
Blocking tasks, not just logging threats
The deepest capability of the narrow gate is not passive inspection — it is active intervention. When OpenFang detects a security threat during a tool call, it does not merely log the event and let the call proceed. It blocks the kanban task. The worker’s task is moved to blocked status, the threat is logged to the openfang_agents ChromaDB collection for pattern analysis, and the operator is notified.
This is what separates the narrow gate from a firewall. A firewall logs and alerts. The narrow gate acts. It interrupts the execution of a running task, preserves the audit trail, and forces a human decision before the work can resume. The agent does not get to finish its call and hope nobody noticed. The gate noticed. The gate acted. The gate is still watching.
This active blocking is possible because OpenFang sits at the MCP layer — the protocol boundary between agent reasoning and tool execution. By controlling the protocol boundary, OpenFang controls the execution boundary. An agent can reason about anything; it can only do things through the gate. And the gate can say no.
The dual solid
In the Platonic geometry of the Council, OpenFang is the Cube — the solid of Earth, stability, and constraint. Its dual solid is the Octahedron: ZeroClaw, the DevOps core that builds infrastructure. Duality means mutual constraint. ZeroClaw builds, but every tool call ZeroClaw makes passes through OpenFang. The builder is constrained by the gatekeeper. This is not a flaw in the architecture — it is the architecture. A builder without a gatekeeper is a builder that can deploy unauthorized changes, access unrestricted resources, or burn unbounded credits. The Cube and the Octahedron check each other, just as the Dodecahedron (Hermes) and the Icosahedron (microsharks) check each other. Every layer in the 9 Orders has a dual. Every dual is a constraint. No parent runs unchecked.
Why the gate is narrow, honestly
The cost of a narrow gate is real. Every tool call incurs routing overhead. Every agent waits for the gatekeeper’s inspection. The system is slower than an architecture where agents call tools directly. The Council pays this tax willingly, because the alternative is blindness.
Without the narrow gate, you cannot answer: what tools did that agent call? What data did it access? How much did it spend? Did it try to reach an internal service? You are governing agents by vibes — hoping they behave because you asked nicely. With the narrow gate, every tool call is visible, every budget is enforced, every threat is logged, and every blocked task has a record that outlives the process that triggered it.
The gate is narrow because visibility requires it. A wide gate admits everything and sees nothing. A narrow gate admits only what passes inspection, and inspects everything that passes. That is the difference between a system you can govern and a system that governs you.
The takeaway
If you are building a multi-agent system where agents call tools, the first question is not which tools — it is who controls the calls. The Council’s answer: one gatekeeper, one gate, one audit point. OpenFang is that gatekeeper. The narrow gate is that principle. Together, they ensure that every tool call in the fleet is visible, governed, and reversible — and that no agent, however specialized, runs outside the boundary the Council drew.
The narrow gate is not a restriction on agents. It is a restriction on chaos. And chaos, left unchecked, is the only thing in a multi-agent system that scales without effort.
Grounded in the wiki entities openfang and concepts narrow-gate-principle, credit-safe-architecture, faengz-doctrine, the-9-orders, and multi-profile-agent-architecture, cross-referenced to the moses-governance and kanban-orchestrator skills. Continues the S5 series on the Council System after S5.2’s coverage of the shared kanban board. Design notes on a running system, not a sales pitch.
