Physix FrontierBuilding a Security Gate for Local Agents
As someone new to local agent architectures like EvoMind, I tried its introductory approach. Local-first can be understood as keeping data on your own machine as much as possible; cognitive architecture means giving AI a workflow of planning, recording, and then executing; runtime safety gates are exactly that—intercepting actions like deleting files, connecting to the internet, or changing configurations before execution.
What I wanted to verify is whether agents can be confined to observable, rollback-able small environments. The method involves Python scripts, SQLite for state storage, model-generated plans, plus gates to judge executability.
Day 1: Building the skeleton. Created a folder evomind-lite, typed mkdir db logs in the terminal to create two directories, then created state.db, which is an SQLite database file, like a lightweight ledger. Typed sqlite3 state.db, and seeing the sqlite> prompt meant it opened successfully. The table creation statement was CREATE TABLE events(id, type, payload, status);. Typed .quit to exit.
Expected outcome: Directories contain db, logs, and state.db. Common beginner mistakes with paths. I ran it in a VM, and when relative directories changed, it threw unable to open database file. Switching to absolute paths stabilized it.
Day 3: Connecting models and gates. Models generate plans; gates decide whether to execute. I used Qwen3.8-Max to generate plans, outputting fixed JSON (structured text easy for machines to read). Created plan.py, inputting tasks like "organize download directory." Let the model return only action, target, and reason. Created gate.py, allowing only move_file and read_file, rejecting delete_file and send_email. Checked if target was within the user directory; blocked if the path contained 。. Results were written to events, with status set to planned or blocked.
When running the "organize download directory" task, the model wanted to move installers to packages. The gate blocked it the first time because the path wasn't in the whitelist. This showed the boundary was effective.
One week later: Running real tasks. The task changed to generating a weekly report draft. Expected outcome: The agent couldn't touch email or calendar directly, only reading file lists first. Gates allowed read-only, required confirmation for writing files, and rejected external network access.
A safer way to say it is that things like this are still experimental local cognitive runtimes today; don't treat them as finished products.
I check logs, databases, and failed reruns. Logs are in logs/agent.log; for the database, run SELECT * FROM events;. Recent entries showing blocked indicate the gates are working.
Also, there are three pitfalls: 1) Models output extra explanatory text, so in code, extract from { to } before parsing; 2) ~/downloads and absolute paths weren't unified, causing gate misjudgments; 3) Danger primarily comes from tool calls. If the model speaks incorrectly, we can retry; if files are deleted incorrectly, they're gone.
From a compiler perspective, this is like a pass in IR optimization space, intercepting dangerous operations before generating machine code. Compiler folks are used to asking "was this operator fused?"; now they have to ask "was the tool call blocked?" Local runs also face memory bandwidth bottlenecks. If the model is large and the chain long, waiting tens of seconds ruins the experience. So, keep actions small, log everything, and narrow permissions.
Next steps could upgrade whitelists to permission tags, labeling each tool with read/write, network, latency, and reversibility. The value of local agents mainly depends on whether every step can be seen, blocked, and replayed.
📌 This article is compiled from Hacker News. Original source: https://zenodo.org/records/20580153
Copyright belongs to the original authors. This is a compilation and independent analysis based on public reports.
