ICfirewall Adds Internet Identity Controls on September 30

On September 30, 2026, ICfirewall’s author announced an update adding Internet Identity login and PID-based administration to the local AI relay. Developers experimenting with local models can review the code and run it on a local replica, but should inspect its authentication and prompt filters before sending it real work.

What changed in the September 30 update

ICfirewall is a canister-based relay between a client, such as a web interface or Apple Shortcut, and a local model runner. The canister receives prompts, applies filtering rules, and places approved requests in a queue; a local Python process polls the queue, sends the prompt to a model, and returns the response. That design connects a locally hosted inference process to an Internet Computer canister, which stores and processes the relay’s state.

In the September 23 forum post, the author described “3 modes of off,medium and on” and said users could access the relay through Apple Shortcuts or the frontend chat box. The September 30 update added Internet Identity login. The author says users copy their PID into poll_llm.py to become the master PID, add admins, and change limits; “master pid is the only one who can change modes.” The frontend also now displays both prompt and response.

The update was prompted by interest in the repository: the author wrote, “over 300 clones.” That figure is the author’s report, not a repository download count verified by GitHub. The project README describes three modes—Off, Medium, and On—and lists a canister, a local daemon, and a web interface as its main parts. The project repository currently lists dfx v0.15.0 or higher, Python 3.10+, and a local LLM runner such as Ollama or LM Studio.

Who should care, and what the design means

ICfirewall is aimed at developers who want to keep inference on a local model while routing prompt submission through a canister-managed relay. A central relay can make it easier to inspect and control what enters a model, and its three modes offer different filtering choices. That can be useful for experiments where prompts arrive through multiple clients or where an operator wants to restrict certain inputs.

But the relay does not make local inference safe by itself. Its protection depends on the code that checks prompts, the correctness of identity and permissions, and the way the daemon handles queued work. A commenter pointed out that a regular expression can miss command variants; the author agreed that the rules need improvement and described the project as a sample rather than a bulletproof system. The author also said an AI agent reported that it did not work and that they still needed to test it themselves.

There is a practical configuration mismatch to check: the forum describes the newer Internet Identity and PID flow, while the repository README still documents a bearer-token setup for its Shortcut and daemon. Review the current code and configuration before treating the forum’s update as a complete security change. Prompts and responses also pass through the canister in this architecture, so consider what data you are willing to route through it.

This is relevant to the broader problem of AI coding systems producing unsafe or fabricated outputs. ICfirewall focuses on filtering prompts and model responses, but it should be evaluated as one control in a larger review process.

How to evaluate it locally

The repository’s quick start gives these commands for a local deployment. It lists dfx v0.15.0 or higher and Python 3.10+ as prerequisites; use a local model runner as well. The official dfx deploy reference explains that deployment creates, builds, and installs the canisters defined by the project.

git clone https://github.com/iTechBod/ICfirewall.git
cd ICfirewall
dfx start --background
dfx deploy

Before connecting a model, review the project’s current setup rather than copying old configuration values blindly. The repository README has instructions for setting a canister ID in main.js and starting scripts/poll_llm.py with ODYSSEUS_SESSION_ID; compare those steps with the newer PID flow described in the forum update. Do not deploy to mainnet until you understand which canister methods are public, how administrators are authorized, and what prompt and response data the canister stores.

A useful evaluation checklist is:

1. Run the project against a local replica and a disposable local model.
2. Inspect the canister’s authorization checks and confirm that a non-admin PID cannot change limits or modes.
3. Test benign prompts, malformed input, and prompt-injection attempts against each mode; review both the accepted prompt and returned response.
4. Confirm how the daemon authenticates, polls, and handles errors before connecting it to a model or client you depend on.

The README describes the intended workflow, while the forum thread records the author’s update and acknowledged limitations. Treat both as implementation claims to verify in code, not as evidence that the filter blocks attacks reliably.