Remote Permission Approval: Why Your AI Agent Shouldn't Have Root Access

AI coding agents need permissions to be useful. They need to read files, run commands, and sometimes modify your codebase. The question is not whether to grant permissions, but how to control what gets approved and maintain visibility into what the agent is doing when you are not watching.

The Problem With Blanket Approval

Some developers run agents with all permissions enabled to avoid constant approval interruptions. This is understandable. Being asked to approve every cat and ls command is tedious and breaks flow. But blanket approval means the agent can do anything, and agents do request surprising things.

Here are real examples from production sessions:

• rm -rf node_modules && rm -rf .git when asked to "clean up the project"
• curl -X POST to an external API with request body containing source code
• chmod 777 on a directory containing credentials
• Writing to ~/.ssh/config when asked to set up a deploy script
• Installing npm packages with known vulnerabilities as transitive dependencies

None of these are the agent being malicious. They are the agent interpreting instructions literally without understanding security context. An agent told to "clean up" does not distinguish between removing build artifacts and deleting version control history.

How Remote Approval Works

Styrby's remote approval routes permission requests to your mobile device. The flow:

1. The agent requests permission to run a command (e.g., rm -rf dist/).
2. Styrby's CLI intercepts the request before it executes.
3. The request is classified by risk level and sent to your phone as a push notification.
4. You see the exact command, the risk classification, and the project context.
5. You approve or deny. The decision is logged in the audit trail.
6. The CLI relays your decision to the agent.

Risk Classification

Not all permissions require the same level of scrutiny. Styrby classifies requests into three risk levels:

The classification is based on pattern matching against the command. Commands containing rm, curl, wget, chmod, or writes to paths outside the project directory are flagged as high risk. You can customize these rules.

Blocked Tool Lists

Beyond risk classification, you can maintain a blocked tool list. Commands on this list are automatically denied without sending a notification:

# Block specific dangerous patterns
styrby config blocked-tools add "rm -rf /"
styrby config blocked-tools add "chmod 777"
styrby config blocked-tools add "curl * -d *"

# View current blocked list
styrby config blocked-tools list

Blocked tools act as a hard safety net. Even if you accidentally approve something in a rush, the blocked list catches it.

The Audit Trail

Every permission request, approval, and denial is logged with:

• Timestamp
• Agent that made the request
• Exact command requested
• Risk classification
• Your decision (approved, denied, auto-approved)
• Which device you responded from
• Response latency

This log serves two purposes. First, it helps you review what happened in a session after the fact. Second, it provides compliance documentation for teams that need to demonstrate access controls over AI-generated code changes.

Practical Configuration

The goal is to minimize interruptions while maintaining security. A reasonable starting configuration:

# Auto-approve read operations and test runs
styrby config auto-approve "Read *"
styrby config auto-approve "Bash(npm run test)"
styrby config auto-approve "Bash(npm run build)"
styrby config auto-approve "Bash(npx tsc --noEmit)"

# Require approval for writes and network
styrby config require-approval "Write *"
styrby config require-approval "Bash(curl *)"
styrby config require-approval "Bash(npm install *)"

# Block dangerous patterns
styrby config blocked-tools add "Bash(rm -rf /)"
styrby config blocked-tools add "Bash(chmod 777 *)"
styrby config blocked-tools add "Bash(* > ~/.ssh/*)"
styrby config blocked-tools add "Bash(* > ~/.aws/*)"

Start with more approvals required and loosen over time as you build confidence in which operations are safe for your specific workflow.

Latency Considerations

Remote approval adds 2-5 seconds of latency per permission request. For interactive sessions where you are actively working with the agent, this can feel slow. The solution: use auto-approve for low-risk operations during active sessions and switch to full remote approval when running agents unattended.