The Narrow Gate, Deep Dive: What the Gate Blocks That Sandboxes Don’t
Every agent sandbox makes the same promise: the agent can do what it needs, and nothing more. Docker containers isolate processes. Language-level sandboxes restrict file access. API gateways throttle calls. The promises are reasonable. The promises are also incomplete.
A sandbox confines an agent. It does not confine the system the agent operates within. The difference is not philosophical — it is architectural. And in a multi-agent fleet that publishes to the internet, manages customer data, and runs on 42-plus profiles, that difference is the gap between a system you can govern and a system that governs you.
What a sandbox actually blocks
A sandbox restricts a single process. Docker gives a container its own filesystem, network namespace, and PID space. A language-level sandbox (Python’s restricted execution, JavaScript’s CSP) limits what APIs a script can call. An API gateway rate-limits and authenticates incoming requests. Each of these operates on one axis: what can this process access?
The scope is narrow by nature. A Docker container cannot see the host filesystem — but it can make outbound HTTP calls to any address. A rate-limited API gateway controls request frequency — but cannot inspect whether the request’s content violates a policy that has nothing to do with rate. A language sandbox restricts file access — but cannot prevent the agent from passing externally-sourced data into an authorized file write as an injection vector.
Sandboxes solve the containment problem for a single execution context. They do not solve the interaction problem for a system of many agents. The narrow gate does.
The narrow gate is a system-level chokepoint
The narrow gate principle — enforced by OpenFang, the Security Custodian running on port 7076 — is architecturally different from a sandbox. A sandbox says “this process can only reach these resources.” The narrow gate says “nothing in the system reaches anything outside the system except through this one point.”
The difference is the word nothing. A sandbox exempts the orchestrator. The narrow gate does not. A sandbox exempts network calls that look normal. The narrow gate inspects every outbound request. A sandbox exempts agent-to-agent handoffs that happen within the same trust domain. The narrow gate treats every handoff as a verification ceremony, regardless of where the agents run.
OpenFang is the sole MCP server for the entire Council fleet. Every agent — parent, child, microshark — routes every tool call through this one server. There is no second server. There is no fallback. There is no direct path from any agent to the outside world that does not pass through OpenFang’s inspection pipeline first. This is the Faengz Doctrine made executable: unified calls or none at all.
Five things the gate blocks that sandboxes miss
1. Cross-agent trust escalation
A sandbox restricts Agent A. It does not restrict what Agent A can convince Agent B to do. If Agent A completes a task and passes a summary to Agent B, and Agent B trusts the summary because it came from a co-worker, Agent B may execute operations that Agent A was never authorized to trigger. The narrow gate catches this because every task handoff passes through OpenFang’s verification — the signing protocol described in the S7.3 article on zero-trust agent comms. Agent A’s summary carries an Ed25519 signature. Agent B verifies the signature, checks the scope, and rejects the handoff if the claimed operations exceed Agent A’s solid-key grant. A sandbox cannot enforce this because the trust relationship exists between agents, not between an agent and its resources.
2. Ambient privilege leakage
When a process runs inside a Docker container, it inherits the container’s environment variables — including any API keys, database credentials, or service tokens mounted into the container. The agent may never intentionally access these credentials, but a compromised skill or a prompt-injection attack can read them from the environment and exfiltrate them through a tool call. OpenFang’s env_clear strips every ambient credential from the tool-call execution environment. The agent sees only what its solid-key scope permits. The tool call never sees the database password, the API key, or the service token — even if they exist in the parent process. A sandbox provides isolation between containers; the narrow gate provides isolation between intent and ambient authority within a single container.
3. Temporal budget enforcement
A sandbox enforces limits at a point in time: this container gets 2GB of memory, this API call gets a 30-second timeout. It does not enforce limits across time. An agent that makes 500 small API calls over an hour, each within the rate limit, burns more budget than a single call that triggers a 30-second timeout — and the sandbox sees nothing wrong. The narrow gate enforces cumulative budgets across an agent’s lifetime: token budgets per task, per session, and per agent. When the cumulative spend hits the hard cap, OpenFang blocks further calls. The agent gets a wall, not a warning. This is the credit-safety architecture — the gate tracks spending as a running total, not as individual request thresholds.
4. Lateral movement via tool chaining
A sandbox allows Agent A to call Tool 1 and Tool 2, because both are on the allowed list. What the sandbox does not enforce is the sequence: Agent A calls Tool 1 to read a file, then Tool 2 to write the file’s contents to an external endpoint. Neither call is individually suspicious. Together, they form a data exfiltration pipeline. The narrow gate’s taint-tracking layer tags data with its origin as it flows through the inspection pipeline. When Agent A reads a file marked taint:vault, and then passes that data into a tool call targeting an external endpoint, the taint layer flags the cross-boundary flow. The 16 security layers — env_clear, loop guards, taint tracking, SSRF protection, budget enforcement — work as a stack, not as individual features. A sandbox sees two allowed calls. The gate sees one exfiltration attempt.
5. Self-scope violation by compromised agents
A sandbox does not know what an agent should do — it only knows what the container is allowed to access. If the container’s permissions are too broad (and they almost always are, because least-privilege is hard to configure), the sandbox provides false assurance. The narrow gate works from the opposite direction: the solid-key architecture (PSAA) defines exactly what each agent can access — faces, vertices, edges — based on the Platonic solid encoding its tier. A T1 tetrahedron agent has 4 skills, 4 contexts, 6 relationships. A T5 icosahedron agent has 20/12/30. The geometry is the policy. If a compromised agent attempts an operation outside its solid-key scope, OpenFang rejects the call — not because the container forbids it, but because the key itself does not carry the authorization. The sandbox enforces container permissions. The gate enforces cryptographic identity.
The Cloudflare perimeter closes the loop
The narrow gate operates at the application layer — inspecting tool calls, enforcing budgets, tracking taint. But agents also communicate over the network, and the network has its own attack surface. Cloudflare closes this loop.
The tunnel architecture routes every external request through Cloudflare’s edge network. No agent binds to a public interface. DNSSEC ensures name resolution cannot be spoofed. SPF and DMARC harden the email perimeter — agents that send or receive email do so through a verified DNS chain. The 530 audit ensures that only authenticated traffic reaches the Council infrastructure.
The result is a double perimeter: Cloudflare at the network layer, OpenFang at the application layer. A sandbox provides one layer — process isolation. The narrow gate provides two — process isolation plus network isolation, with cryptographic identity binding them together. An attacker who compromises an agent container still faces the Cloudflare tunnel (no direct network access), the Ed25519 verification (no spoofed identity), and the PSAA solid-key scope (no privilege escalation). Three independent barriers where a sandbox offers one.
Why this matters
The narrow gate is not a better sandbox. It is a different security model. A sandbox protects a process. The narrow gate protects a system. In a single-agent deployment, the distinction may not matter. In a multi-agent fleet — 42 profiles, a shared kanban board, autonomous task execution, and public-facing content — the distinction is everything.
The cost is real. Every tool call routes through one server. Every handoff requires signature verification. Every agent waits for the gatekeeper’s inspection. The system is slower than a direct-call architecture. The Council pays this tax because the alternative is governing agents by vibes — hoping they behave because the container is configured correctly and nobody made a mistake.
The narrow gate eliminates the hope. It replaces it with geometry, signatures, and a single audit point. You do not have to trust that the sandbox is configured right. You have to verify that the key is valid, the scope is correct, and the signature checks out. And the gate verifies all three — every time, for every call, without exception.
