Beginner

Agent Permission Models

Understanding how AI coding agents handle permissions is the foundation of agent safety. Each agent has a different approach to controlling what actions it can take — and knowing these models helps you configure the right level of protection.

How Different Agents Handle Permissions

AI coding agents vary significantly in how they manage the boundary between "suggest" and "execute." Here's a comparison of the major agents:

AgentPermission ModelConfirmation Required?Configurable?
Claude CodeTool-level allow/deny with CLAUDE.md restrictionsYes, per tool call (unless allow-listed)Highly configurable
Codex CLIThree modes: suggest, auto-edit, full-autoDepends on modeYes, via mode selection
GitHub CopilotIDE-integrated with inline accept/rejectYes, for terminal commandsLimited
CursorIDE agent with diff review before applyYes, for file changesModerate
WindsurfCascade flow with step-by-step confirmationYes, at each stepLimited
AiderAuto-commit with git integrationOptional (--yes flag)Yes, via flags

Claude Code's Permission System

Claude Code has the most sophisticated permission model among current AI coding agents. It operates on a tool-level allow/deny system:

Tool Categories

Claude Code Tool Categories
# Read-only tools (low risk - can be auto-allowed)
- Read files
- List directory contents
- Search/grep codebase
- View git log/status/diff

# Write tools (medium risk - require confirmation by default)
- Edit/write files
- Create directories

# Execute tools (high risk - always require confirmation)
- Run bash commands
- Execute shell scripts
- Run arbitrary programs

# Dangerous patterns (should be denied or require extra caution)
- Commands containing: rm -rf, drop database, terraform destroy
- Force pushes: git push --force
- Credential access: cat ~/.aws/credentials

CLAUDE.md Restrictions

The CLAUDE.md file at your project root can define safety rules that Claude Code will follow:

CLAUDE.md (Safety Section)
# Safety Rules

## Forbidden Commands
- NEVER run `terraform destroy` or `terraform apply` without plan
- NEVER run `kubectl delete namespace` on production contexts
- NEVER run `git push --force` to main or master branches
- NEVER run `rm -rf /` or any recursive delete on root paths
- NEVER run `docker system prune -af` without confirmation
- NEVER access or display credentials, secrets, or API keys

## Required Patterns
- ALWAYS run `terraform plan` before `terraform apply`
- ALWAYS use `--dry-run` flag when available
- ALWAYS create a backup before modifying databases
- ALWAYS work on feature branches, never directly on main

## Infrastructure Rules
- Only interact with the dev/staging AWS account (123456789012)
- Never modify resources tagged with `env:production`
- Use read-only credentials for cloud exploration
Best practice: Every project that uses AI coding agents should have a CLAUDE.md (or equivalent configuration) that explicitly defines forbidden commands and required safety patterns. This is your first line of defense.

GitHub Copilot Agent Mode Safeguards

GitHub Copilot's agent mode in VS Code operates with several built-in safeguards:

  • Terminal command confirmation: Every terminal command the agent wants to run is shown to the user for approval before execution
  • Diff preview: File changes are shown as diffs that the user can accept or reject
  • Workspace scope: The agent operates within the current workspace, limiting its reach
  • Extension sandboxing: Runs within VS Code's extension sandbox, limiting system access
💡
Limitation: Copilot's agent mode doesn't have a CLAUDE.md-equivalent for defining project-specific safety rules. Safety depends entirely on the developer reviewing each action.

The Principle of Least Privilege for AI Agents

Just as you wouldn't give a junior developer admin access on day one, AI agents should operate with the minimum permissions needed for their task:

  1. Identify the Task Scope

    Before starting an agent session, define what the agent needs to do. "Fix the CSS bug in the login page" doesn't need AWS credentials or database access.

  2. Create Task-Specific Credentials

    Use short-lived, scoped credentials for each agent session rather than your personal admin credentials.

  3. Restrict Tool Access

    If the agent only needs to edit files, disable shell execution. If it needs to run tests, allow only specific test commands.

  4. Set Environment Boundaries

    Point the agent at development environments, not production. Use separate kubeconfig contexts, AWS profiles, and database connections.

Bash - Scoped AWS Profile for Agent Use
#!/bin/bash
# Create a restricted AWS profile for AI agent sessions

# ~/.aws/config
[profile agent-readonly]
role_arn = arn:aws:iam::123456789012:role/AgentReadOnly
source_profile = default
region = us-east-1
duration_seconds = 3600  # 1-hour session max

# Before starting an agent session:
export AWS_PROFILE=agent-readonly
export AWS_DEFAULT_REGION=us-east-1

# Verify the agent sees only read-only permissions
aws sts get-caller-identity
# Should show the AgentReadOnly role, not your admin identity

Configuring Confirmation for Destructive Commands

Most agents allow you to configure which commands require human confirmation. Here's how to set this up:

JSON - Agent Permission Configuration Example
{
  "permissions": {
    "auto_allow": [
      "read_file",
      "list_directory",
      "search_codebase",
      "git_status",
      "git_diff",
      "git_log"
    ],
    "require_confirmation": [
      "write_file",
      "execute_command",
      "git_commit",
      "git_push"
    ],
    "always_deny": [
      "commands_matching: rm -rf /",
      "commands_matching: terraform destroy",
      "commands_matching: kubectl delete namespace",
      "commands_matching: git push.*--force.*main",
      "commands_matching: DROP DATABASE",
      "commands_matching: aws .* delete-"
    ]
  }
}

Sandboxed vs Unsandboxed Execution

AI agents can operate in different execution modes that fundamentally change their risk profile:

ModeDescriptionRisk LevelUse Case
Fully SandboxedAgent runs in a container with no network access and ephemeral filesystemVery LowCode generation, refactoring
Network SandboxedAgent can modify local files but cannot reach external servicesLowLocal development, testing
Scoped AccessAgent has network access but limited to specific services/accountsMediumIntegration testing, staging deploys
Full AccessAgent has the same access as the developerHighOnly with comprehensive guardrails
Bash - Running an Agent in Docker Sandbox
#!/bin/bash
# Run your AI agent inside a sandboxed Docker container

docker run --rm -it \
  --name agent-sandbox \
  --network none \               # No network access
  --read-only \                   # Read-only root filesystem
  --tmpfs /tmp:rw,size=100m \     # Writable temp space
  -v $(pwd):/workspace:rw \       # Mount only the project dir
  -w /workspace \
  --memory 2g \                   # Limit memory
  --cpus 2 \                      # Limit CPU
  node:20-slim \
  bash
Important: Sandboxing an agent's execution environment is one of the most effective safety measures. Even if the agent tries to run a destructive command, the sandbox prevents it from reaching real infrastructure. We cover this in depth in Lesson 4: Sandbox Environments.

Key Takeaways

  • Every AI coding agent has a different permission model — understand yours
  • Use CLAUDE.md or equivalent config to define project-specific safety rules
  • Apply the principle of least privilege: agents should only have what they need
  • Create task-specific, time-limited credentials for agent sessions
  • Prefer sandboxed execution modes when the task doesn't require real infrastructure access
  • Configure destructive commands to always require human confirmation