playbook

How to approve AI agents that can run terminal commands

A practical approval workflow for small engineering teams deciding when AI coding agents may run shell commands, install dependencies, or touch production-adjacent systems.

Bottom line

An AI agent that can run terminal commands is no longer just suggesting code. It can execute package managers, test runners, migrations, scripts, cloud CLIs, Git commands, and network requests. That makes terminal access a high-risk permission for small teams, especially when the repository is connected to production services or contains secrets.

The approval rule should be:

AI agents may run low-risk commands in approved development environments, but commands that mutate state, access secrets, install dependencies, contact external services, or affect deployment require explicit human approval.

Start by running the AI Tool Risk Checker for the agent workflow, then record the decision in the Small Team AI Security Checklist. Do not rely on the agent’s own explanation of a command. Review the actual command, working directory, environment, network access, and expected side effects.

Command risk tiers

Tier	Command examples	Default approval rule	Why it matters
Low	npm test, npm run build, pytest, rg, ls, git diff	Allow after repository owner approves the tool and scope.	These commands are mostly read-only or local verification, but output may still expose sensitive data.
Medium	npm install, pip install, npx, code generators, formatters that rewrite files	Require human approval before execution and diff review after execution.	Dependency and generated-code changes can introduce supply-chain, license, or broad code-change risk.
High	database migrations, terraform, kubectl, cloud CLIs, deploy scripts, file deletion, git history edits	Block by default unless a named owner approves the command and environment.	These commands can change infrastructure, data, releases, or recovery paths.
Critical	production credentials, payment systems, customer exports, secret rotation, destructive database commands	Do not allow AI agent execution in normal development workflows.	A single mistaken or injected command can cause data loss, exposure, outage, or account compromise.

Approval workflow

Use this workflow before enabling terminal command execution for any AI coding agent.

Step	Decision	Required evidence
1	Define the agent mode	Tool name, local/cloud mode, repository, branch, and whether terminal access is enabled.
2	Classify the repository	Public, internal, customer-data-adjacent, production-connected, regulated, or secret-heavy.
3	Set command tiers	Document which low, medium, high, and critical commands are allowed or blocked.
4	Limit environment access	Confirm no production credentials, customer exports, or unrestricted cloud tokens are present.
5	Review network access	Decide whether the agent can reach the public internet, package registries, internal services, or only allowlisted hosts.
6	Require logs	Preserve command text, working directory, output summary, resulting file diff, and reviewer decision.
7	Add PR gate	AI-generated changes require tests, secret scans, and human review before merge.
8	Revisit after pilot	Review command history after one or two weeks before expanding access.

Command review template

Paste this template into pull requests, issue comments, or the team’s AI tooling log.

AI agent command approval

Tool:
Repository:
Task:
Requested command:
Working directory:
Environment:
Network access:
Expected files changed:
Expected external systems touched:
Risk tier: Low / Medium / High / Critical
Approved by:
Approved until:
Rollback or cleanup:
Notes:

Do not accept summaries such as “run the tests” for medium or high-risk commands. Require the literal command string. For shell pipelines or scripts, review the script body too.

Default allowlist and blocklist

Category	Suggested default
Read-only inspection	Allow rg, git diff, git status, ls, cat, and language-specific read-only inspection commands when output is not secret-bearing.
Tests and builds	Allow project-specific test and build commands in a non-production environment.
Package installs	Require approval; review package name, version, registry, lockfile, and reason.
Network calls	Require approval unless the agent environment has a narrow allowlist.
Git commands	Allow git diff and git status; require approval for commit, push, rebase, reset, clean, tag, or history edits.
File deletion	Require approval for any recursive delete, generated file cleanup, or migration cleanup.
Databases and cloud	Block by default unless the environment is disposable and has no production credentials.
Deployment	Block by default; require a human release owner.

Evidence checked

• Cursor’s Agent Security documentation says Cursor Agent has tools for file reads, edits, terminal commands, and web search, and recommends reviewing commands before execution.
• Cursor’s Terminal documentation describes agent command execution in Cursor’s native terminal.
• Cursor’s CLI documentation describes command approval in CLI workflows.
• GitHub’s Copilot coding agent documentation describes sandboxed development, branch restrictions, security validation, and existing repository governance.
• GitHub’s Copilot cloud agent firewall documentation explains internet-access controls and warns that disabling the firewall increases exfiltration risk.
• OpenAI’s Codex agent internet access documentation notes that internet access is off by default because enabling it introduces risks such as prompt injection, code or secret exfiltration, malware, vulnerabilities, and license issues.
• OWASP’s Top 10 for LLM Applications and MCP Top 10 are useful references for excessive agency, sensitive information exposure, command injection, and overly broad tool permissions.

Two-week pilot policy

Start with one repository and one workflow.

Pilot day	Action	Exit condition
1	Approve the tool, repository, agent mode, and command tiers.	Written owner and policy exist.
2	Remove production secrets from the environment and confirm .env files are not exposed.	Agent cannot read production credentials.
3-5	Allow low-risk commands only.	Tests/builds work; command logs are reviewable.
6-8	Permit selected medium-risk commands with approval.	Lockfile and generated changes are reviewed.
9-10	Test blocked high-risk commands in the approval flow.	The team confirms the tool stops or asks before risky execution.
11-14	Review command logs and PRs.	Expand, restrict, or stop with a recorded decision.

FAQ

Can we let AI agents run tests automatically?

Usually yes, if the command is known, local, and does not contact production services. Treat test commands as low risk only after checking that the test suite does not use real credentials, customer data, or destructive fixtures.

Are package installs safe?

Not automatically. Package installs can change lockfiles, introduce vulnerable or malicious dependencies, run postinstall scripts, or add licensing risk. Require approval and review the dependency diff.

Is a cloud sandbox safer than a local terminal?

It can be safer when secrets are absent and network access is restricted, but it is not a complete control. Review the sandbox’s internet access, repository permissions, setup scripts, logs, and PR branch behavior.

What should always require a human?

Deployment, database changes, cloud infrastructure, secret handling, payment workflows, customer-data exports, destructive file operations, Git history edits, and any command that reaches production systems.

What is the minimum policy for a tiny team?

Use three rules: no production credentials in agent environments, explicit approval for medium/high-risk commands, and no merge without human review plus tests. Then add the tool to your Small Team AI Security Checklist so the decision is not lost.