Take a look at my latest blog posts below. 👇
Two releases on the same day, twenty minutes apart: v1.0.1 then v1.0.2. Both do the same job — harden pi-secured-setup itself. This is a short post to explain what changed and why it matters, because a security tool that ships its own vulnerabilities loses all credibility.
If you’re new to the project, the introductory article covers the basics: Guards, Scanners, the audit trail.
Three threads:
pi in YOLO mode gives you full filesystem access, unrestricted command execution, zero guardrails. The creator made that choice deliberately. But when your project contains .env files, SSH keys, or a production.yaml, that choice puts you at risk.
I covered pi-secured-setup a few days ago. Guards, Scanners, audit trail, wired into the agent. Since then I looked at another extension: pi-permission-system by MasuRii. Both secure pi. Not the same way.
In the previous article, I introduced pi-secured-setup — a pi extension that adds Guards, Scanners, and an audit trail to your AI coding agent. It ships with sensible defaults: boundary enforcement, protected path globbing, bash command classification, secret redaction, skill verification.
But every project has unique risks. A Terraform shop needs different rules than a Node.js monorepo. A team with strict compliance requirements needs different audit granularity than a solo developer.
A few days ago, I covered Greywall — a kernel-level sandbox that contains pi with a deny-by-default approach. That’s your outer wall. But what about threats inside the boundary? The agent that accidentally writes to the wrong project, the .env file that ends up in the LLM context, the skill whose SKILL.md was silently modified. That’s a different problem, and it needs a different tool.
Today I’m releasing pi-secured-setup — a pi extension that adds Guards, Scanners, and an audit trail directly inside the agent. No kernel modules, no containers, no external dependencies. Just a pi install and you’re protected.
AI coding agents like pi have become essential daily companions. But by default, pi runs in YOLO mode: full filesystem access, unrestricted command execution, no permissions. It’s a deliberate design choice by its creator, but this freedom comes with real risks. Today, let’s explore Greywall, a tool that sandboxes pi using a deny-by-default approach at the kernel level.
pi in YOLO mode is convenient but risky. Without restrictions, the agent can:
With the standard Makefile configuration delivered form git, you can’t compile cdr_pg_csv. You need top edit theMakefile file of cdr_pg_csv module. The file si located here : src/mod/event_handlers/mod_cdr_pg_csv/Makefile . Copy and past the following code :
UNAME := $(shell uname -s)
ifeq ($(UNAME),SunOS)
ISA64 := $(shell isainfo -n)
LOCAL_CFLAGS=-I/usr/include/postgresql
ifneq (,$(findstring m64,$(CFLAGS)))
LOCAL_LDFLAGS=-L/usr/pgsql-9.1/lib/$(ISA64) -R/usr/pgsql-9.1/lib/$(ISA64) -lpq -static
else
LOCAL_LDFLAGS=-L/usr/pgsql-9.1/lib -R/usr/pgsql-9.1/lib -lpq -static
endif
else
LOCAL_CFLAGS=-I/usr/include/postgresql
LOCAL_LDFLAGS=-L/usr/pgsql-9.1/lib -lpq -static
endif
include ../../../../build/modmake.rules
Now, we are ready for make, so do :