Hello, I’m Mathias 👋

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.

Why Sandbox an AI Coding Agent?#

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 :

This is my first howto in english. As I will release in some days, my project name pyfreebilling (wholesale voip platefom based on Freeswitch, PostgeSQL and Django), i write the first installation step : howto compile and install freeswitch / odbc and postgresql on debian wheezy.

Prerequisites#

You need to install these packages :

apt-get install git-core build-essential autoconf automake libtool libncurses5 libncurses5-dev gawk libjpeg-dev zlib1g-dev pkg-config libssl-dev libpq-dev unixodbc-dev odbc-postgresql postgresql postgresql-client

Configuration#

You download freeswitch using git :