Soup Wall: open-source security for AI agents and model traffic. Local Agent, Gateway, self-hosted Console. Apache-2.0.
FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: 开源项目. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository SoupTeam/soup-wall;first catalogued 2026-10-10;last seen 2026-10-10。There is no official certification or quality rating here — we record sources and dates only.
Soup Wall
以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →
**Open-source protection for AI apps and agents.** Soup Wall inspects model traffic and the actions an agent takes, applies local policy, and records decisions for review. The complete source for the agent, gateway, and self-hosted control plane is available under Apache-2.0.
Choose where to start
Joining the development team? Start with the development guide, then read CONTRIBUTING.md. The documentation index links setup, architecture, operator procedures, and verification evidence.
Development starts from the baseline/team-handoff source tag. The product roadmap orders work by dependencies and acceptance criteria, with one final release after the complete product passes its gates. The canonical repository is SoupTeam/soup-wall.
| Surface | What it does | Runs as |
| --- | --- | --- |
| **Soup Wall Agent** | Reviews tool calls, tool results, MCP manifests, and subagent authority. Starts in shadow mode. | agentfw daemon and CLI |
| **Soup Wall Gateway** | Inspects OpenAI Chat Completions and Responses, and Anthropic Messages traffic before and after provider calls. | llm-firewall HTTP binary |
| **Soup Wall Console** | Manages self-hosted tenants, tokens, policy, audit, identity, and usage. | Built into the Gateway when tenant_store is enabled |
The llm-firewall binary and LLM_FW_* settings retain their established names for compatibility; release archives also provide a soup-wall-gateway binary name. They are part of Soup Wall; no paid license or Soup Wall account is required to build or self-host them. The local Agent does not send telemetry to Soup Wall. The Gateway contacts the model providers you configure, and optional features can contact your PostgreSQL, Redis, identity provider, or webhook destination.
Build
Install the current stable Rust toolchain with rustfmt and clippy, a platform C/C++ build toolchain, and Python 3.10+ for integration tests. See the platform prerequisites, then run from the repository root:
The checked-in firewall.yaml loads policies/default.yaml at runtime, and a shipped-policy test expects that path at the repository root. Optional ML features need model assets fetched separately; the default build uses signatures and heuristics.
Agent: protect a local Claude Code session
install creates the local daemon token and prints the hook block and instructions to add to Claude Code's settings.json; apply that printed block before starting a session. In the shell that launches Claude Code, export the token as the printed instructions show (for example, export AGENTFW_TOKEN="$(cat ~/.agentfw/token)"). Keep serve running. In another terminal, check the daemon:
The default ~/.agentfw/config.yaml posture is **shadow mode**: verdicts are written to ~/.agentfw/audit.jsonl, but the hook does not block tools. After reviewing real sessions with agentfw replay, gate any policy changes against the reviewed corpus:
Then set enforce: true in ~/.agentfw/config.yaml, restart the daemon, and confirm with agentfw preflight --require-enforce. The replay command requires at least 500 events across 20 sessions before it recommends enforcement; a human still has to review interruptions. See Agent enforcement and limitations.
On Windows, install prints a PowerShell token command and uses %USERPROFILE%\.agentfw. See Windows Agent installation and acceptance for native setup and a disposable check of installation, ACLs, shadow/enforcement decisions, audit, and offline preflight.
Explicitly installed constrained MCP profiles provide Windows document reads and Windows create-only files on local NTFS through native handles. These are separate reviewed operation profiles; ordinary MCP child processes retain their host permissions.