pi-permission-system vs pi-secured-setup: choosing how to secure pi

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.

Here’s how they compare.

Two philosophies#

pi-permission-system is a policy engine. You declare the rules, the engine enforces them. Three states: allow, ask, deny. Wildcards. Config layers for global, project, and agent scopes. The point: lock down pi’s execution surface before the agent moves.

pi-secured-setup is a defense-in-depth package. Guards that block or confirm. Scanners that observe and redact. JSONL audit trail. The point: catch leaks, verify skill integrity, trace every action. Install it, you’re protected. No config to write.

• pi-permission-system: fine-grained authorization framework
• pi-secured-setup: hardening suite with detection and audit

Their common ground#

Both cover the same basics:

Install either one and you get comparable baseline protection. The gap shows up everywhere else.

The enforcement model#

pi-permission-system runs on a policy matrix. You write rules in pi-permissions.jsonc:

{
  "defaultPolicy": { "tools": "ask", "bash": "ask", "mcp": "ask", "skills": "ask", "special": "ask" },
  "tools": {
    "read": "allow",
    "write": "deny",
    "mcp": "allow"
  },
  "bash": {
    "git *": "ask",
    "git status": "allow",
    "rm -rf *": "deny"
  }
}

Each category (tools, bash, mcp, skills, special) has its own rules. Wildcards follow last-match-wins logic. You can override per agent in YAML frontmatter. Denied tools get stripped from the system prompt before startup. The agent never sees them.

pi-secured-setup chains named guards and scanners in a fixed order:

boundary → protected-paths → bash-gate

First blocking verdict wins. Scanners (secrets, skills) watch without blocking. No matrix, no wildcards. Rules sit in separate JSON files per guard (command-rules.json, protected-paths.json, allowed-external.json).

In practice: to allow git status and block git push --force, pi-permission-system makes you write two rules. pi-secured-setup classifies git status as SAFE and git push --force as DANGEROUS on its own.

What one does and the other doesn’t#

Extra in pi-permission-system#

MCP. A dedicated section for controlling access to MCP servers and tools. mcp_status in allow, myServer:search in ask, an entire server in deny.

System prompt sanitization. The extension rewrites the Available tools: section, stripping denied tools. The agent only sees what it can call.

Subagents. A delegated agent without UI that hits an ask forwards the request to the main session for confirmation.

Runtime YOLO mode. Toggle ask to auto-approval temporarily via /permission-system or the API.

Per-agent overrides. Each agent carries its own policy in YAML frontmatter inside its markdown file.

Extra in pi-secured-setup#

Secret scanner. Inspects the provider payload before it leaves your machine. Catches AWS keys (AKIA...), GitHub tokens (ghp_...), private keys (-----BEGIN RSA PRIVATE KEY-----), database connection strings, and a dozen more patterns. The agent keeps the secret type, not the value.

DATABASE_URL=postgres://user:supersecret@db.example.com:5432/prod

becomes:

DATABASE_URL=***REDACTED:db-connection***

Skill integrity verification. SHA-256 hash of every SKILL.md. New or modified skill: you approve. Skill changed behind your back: you get an alert.

Audit trail with rotation. Every action logged as JSONL. Rotates at 10 MB, keeps 3 files. /security dashboard with counters and recent events.

Preventive redaction. The scanner runs on before_provider_request. Secrets never reach the model. A secret the model never sees is a secret it can’t leak.

Head to head#

When to pick pi-permission-system#

You run multiple agents with different permission profiles. You need fine-grained MCP access control. You want subagents to respect the same rules as the main agent. You’re coming from OpenCode and want to port your existing rules. You prefer writing an explicit policy and letting the engine enforce it.

pi install npm:pi-permission-system

When to pick pi-secured-setup#

You want protection right now without writing a config file. Your projects contain secrets that must never reach the LLM. You want to know if a skill was modified behind your back. You need an audit trail you can actually dig through. You care about catching leaks as much as blocking actions.

pi install git:github.com/mwolff44/pi-secured-setup

Both together?#

The two extensions work at different levels. One filters execution. The other scans payloads and traces events. They don’t conflict.

On a project that handles sensitive data, I’d install both: pi-permission-system for policy, pi-secured-setup for detection and audit.

pi-secured-setup on GitHub. pi-permission-system on GitHub. Both MIT-licensed.

Which one fits your setup? Tell me in the comments.