Stop Giving AI Full Access: Workflow Guide to Agent Permission Gates

Why Full‑Permission AI Is Dangerous

Developers quickly become accustomed to permission pop‑ups when using AI‑assisted programming tools: allowing file reads, code changes, dependency installation, network access, script execution, or publishing drafts. Initially this seems safe, but after repeated use the prompts become muscle memory, and teams may even switch to fully automatic mode, treating the permission system as a mere confirmation button. The risk then shifts from simple coding errors to the agent performing unintended actions such as reading, writing, deleting, or publishing without proper checks.

Three‑Layer Gate Model

The author separates access control into three distinct layers that must be applied in order:

Permission Gate : decides whether a specific action is allowed to execute. Common mechanisms include sandboxing, approval policies, allow/ask/deny decisions, and the PreToolUse hook.

Scope Gate : defines which parts of the project the action may touch. Implemented via AGENTS.md, task descriptions, worktree paths, and path‑rule definitions.

Verification Gate : checks whether the result of the action has been verified (e.g., tests, type‑checks, browser checks, verification receipts).

If the Permission Gate is missing, an agent can cross boundaries before any verification occurs. If the Verification Gate is missing, the agent may stay within bounds but still deliver unverified results.

Risk‑Based Action Classification

Read repository files – default: allow. Reason: most development tasks need it.

Write current task files – default: allow or ask. Reason: depends on task scope and worktree location.

Write config, permissions, CI, hooks – default: ask. Reason: can affect all subsequent tasks.

Download dependencies (network) – default: ask. Reason: introduces supply‑chain and reproducibility risks.

Call remote APIs or production data – default: ask or deny. Reason: impacts external systems and sensitive data.

Delete, migrate, reset history – default: deny (manual execution). Reason: high destructiveness, costly rollback.

Publish, deploy, send messages – default: ask with human review. Reason: actions affect users or public channels.

The table is a guideline, not a fixed standard; the key principle is to bind permissions to risk surfaces rather than to tool names.

Sandboxing and Approval Policies

OpenAI Codex’s approvals and security documentation splits security into two layers: a sandbox mode that defines what can be done technically, and an approval policy that determines when execution must pause for permission. By default the CLI/IDE has no network access and write permissions are limited to the active workspace. The sandbox defaults are workspace‑write plus on‑request, meaning the agent can work inside the current workspace but must request approval to cross boundaries.

Daily development does not need full access; it needs explainable over‑permission requests.

The danger‑full‑access mode removes file‑system and network boundaries entirely and should only be used for very limited, explicitly trusted scenarios, not as a project default.

Claude Code follows the same approach, exposing allow, ask, and deny settings and providing examples that deny reading .env, secrets/**, or credentials.* files.

Project‑Level Permission Definitions

Rather than reminding the agent in chat each time, the permission boundaries should be codified in project files such as AGENTS.md or CLAUDE.md. An example AGENTS.md snippet:

## Permission Gate
- Default: read/write only within the current workspace.
- Deny reading `.env*`, `secrets/**`, `credentials.*`.
- Require confirmation before modifying CI, deployment, permission, hook, or MCP configs.
- Require explicit action, scope, reason, risk, and rollback description before network access or dependency installation.
- Disallow automatic execution of delete, history reset, production migration, or public publishing.

Claude Code can also embed stricter boundaries in .claude/settings.json using allow, ask, and deny arrays that list specific Bash patterns.

Deny is not a lack of trust in the agent; it reduces the chance of accidental dangerous paths.

Human engineers use .gitignore, branch protection, production approvals, and least‑privilege tokens; AI agents should be subject to the same engineering controls.

Hooks for Project‑Specific Controls

Generic permission systems cannot know which commands are dangerous for a particular project. Hooks allow projects to define custom blocklists. For example, a minimal PreToolUse hook can block destructive commands and production‑related commands:

#!/usr/bin/env bash
set -euo pipefail
payload="$(cat)"
command="$(printf '%s' "$payload" | jq -r '.tool_input.command // empty')"
case "$command" in
  *"rm -rf"*|*"git reset --hard"*|*"git push --force"*)
    echo "Blocked: destructive command requires manual execution." >&2
    exit 2
    ;;
  *"prod"*|*"production"*|*"deploy"*)
    echo "Blocked: production/deploy command must be reviewed by a human." >&2
    exit 2
    ;;
esac
exit 0

This simple hook is not a full security system but stops the most common accidental destructive actions.

MCP Permissions

When an agent uses MCP (Model‑Connected‑Plugins) servers to reach filesystems, browsers, databases, GitHub, Slack, Notion, or cloud platforms, the permission surface expands dramatically. Permissions for MCP must answer additional questions such as read‑only vs read‑write mode, minimal token scopes, clear tool descriptions, required approval for write operations, logging requirements, and failure handling. The author lists these considerations as a checklist.

Any tool that can change the external world should never execute silently by default.

Read‑only actions like documentation lookup can be automated; creating PRs, modifying databases, sending messages, deploying, refunding, or deleting resources should go through an approval step.

Minimal Implementation Steps

Lower the default mode. For personal development, use workspace‑write + on‑request and switch to a more conservative mode only for high‑risk tasks.

Write a project‑level Permission Gate in AGENTS.md, CLAUDE.md, or a team rules file, specifying files that are never read, directories that can be written, actions that must be asked, actions that default to deny, and required fields for approval requests.

Add a minimal PreToolUse hook that blocks destructive, production, and permission‑relaxing commands.

Combine Permission Gate and Verification Gate so that final responses include both permission records and verification receipts.

Key Principles

“The goal of Permission Gates is not to make AI do less, but to let it do more within the correct boundaries.”

When teams no longer rely on constant manual monitoring or vague warnings, AI‑assisted programming moves from “can run” to “can be used sustainably over the long term.”