playbook

AI coding tools and production incident risk

A practical production-risk playbook for small engineering teams using AI coding assistants or agents near production systems.

Bottom line

AI coding tools should not be treated as harmless autocomplete once they can edit files, run terminal commands, open pull requests, install dependencies, or work in a cloud sandbox with repository access. For a small team, the production risk is not only “bad code.” It is an unreviewed change path that can touch authentication, payments, data deletion, migrations, infrastructure, release scripts, CI, or secrets.

The safest default is simple:

AI may propose and draft production code, but it must not bypass the same review, test, deployment, and rollback gates required for a human developer.

Use this playbook when a developer wants to use Cursor Agent, GitHub Copilot coding agent, Codex, Claude Code, or another agentic coding tool on a repository connected to production systems. Before rollout, run the AI Tool Risk Checker and record the decision in the Small Team AI Security Checklist.

Incident risk matrix

Workflow	Production incident path	Default rule
Local code completion	Insecure code, outdated dependency, missing edge case, weak error handling	Allow for low-risk changes, but require human review before merge.
Agent edits multiple files	Unintended side effects across auth, billing, permissions, or data access	Require a pull request, diff review, and targeted tests before merge.
Agent runs terminal commands	Package install, migration, cleanup script, or test command mutates local or shared state	Require command review and run in a disposable environment when possible.
Background or cloud coding agent	Agent works away from the developer’s local context and may create a large PR	Restrict to issue-scoped tasks with no production credentials and mandatory owner review.
Agent modifies CI or deployment files	Build, scan, deploy, or secret-handling guardrails can be weakened	Require senior review for .github/, Docker, IaC, release, and deployment files.
Agent touches data migration or destructive code	Data loss, privilege errors, irreversible schema changes	Block until manually approved by an owner and tested against a safe copy.

Production boundary policy

Adopt this policy before allowing agentic coding on production repositories.

Boundary	Allowed	Not allowed without explicit approval
Repository access	Read and edit code in approved repositories	Private customer exports, production logs with personal data, secrets, or regulated records
Terminal use	Tests, linters, type checks, local build commands	Commands that deploy, delete, rotate keys, alter databases, change DNS, or write to production services
Dependencies	Suggest upgrades with changelog notes and lockfile diff	Installing new runtime dependencies directly into production paths without review
Pull requests	AI-authored PRs with small scope, clear test evidence, and named human reviewer	Auto-merge, self-approval, or skipping required checks because “AI wrote it”
CI and deployment	Read CI output and propose fixes	Weakening secret scans, bypassing branch protections, changing deploy targets, or disabling smoke checks
Incident handling	Draft runbooks, postmortem notes, and test hypotheses	Executing recovery commands against production without an incident commander

Approval checklist

Before an AI coding tool can work on a production-connected repository, record these controls:

• Repository owner is named.
• Allowed AI tool and mode are named.
• The tool is approved for this repository’s data classification.
• Privacy or data-use settings have been reviewed.
• Secrets and .env files are excluded from prompts, context, logs, and screenshots.
• Terminal commands require review unless the environment is disposable.
• The agent cannot access production credentials.
• CI must run tests, linting, secret scans, and link or build checks where relevant.
• AI-authored changes require a human reviewer who understands the affected code path.
• Deployment and rollback owner is named before merge.

Pull request gate

Use this gate for every AI-assisted production PR.

Question	Pass condition	Fail action
What did AI change?	PR description names the files, behavior, and risk area.	Ask the author to rewrite the summary before review.
What could break?	Reviewer can identify affected auth, data, billing, jobs, integrations, or release paths.	Add a risk note and request narrower changes.
What evidence exists?	Tests, build output, screenshots, or manual verification are attached.	Do not merge until evidence is added.
Did AI touch privileged files?	CI, deployment, migrations, secrets, auth, and payment changes have senior review.	Escalate review.
Is rollback clear?	The PR has a revert plan, feature flag, or deployment rollback path.	Add rollback notes before merge.

Red flags that should block rollout

Pause the tool rollout if any of these are true:

• The tool can run terminal commands but the team cannot review or restrict those commands.
• Developers paste production logs, customer tickets, secrets, or .env values into prompts.
• AI-created PRs are large enough that reviewers skim instead of review.
• The tool is allowed to edit workflow files, deployment scripts, or infrastructure without a senior reviewer.
• Branch protection, required checks, or secret scanning can be bypassed.
• Nobody owns rollback for AI-assisted changes.
• The team cannot explain where repository context, prompts, command output, and generated code may be stored.

Evidence checked

• Cursor’s Agent Security documentation describes agent capabilities such as file reads, edits, terminal commands, and web search, and recommends command review.
• Cursor’s Terminal documentation explains that the agent can execute commands in Cursor’s native terminal.
• Cursor’s Background Agents documentation is relevant for teams evaluating remote or background agent workflows.
• GitHub’s Copilot coding agent documentation describes issue-to-pull-request workflows and review expectations.
• OpenAI’s Codex overview describes a coding agent that can read, modify, and run code in a task environment.
• OWASP’s Top 10 for Large Language Model Applications is useful for framing prompt injection, supply-chain, sensitive information, and excessive-agency risks.
• CISA’s Secure by Design guidance supports keeping security responsibility in the software delivery process rather than pushing it to users after release.

Two-week pilot plan

Day	Action	Exit criteria
1	Pick one non-critical repository or low-risk module.	Repository owner and allowed AI mode are documented.
2	Run the Risk Checker and classify the workflow.	High-risk answers trigger extra review or restriction.
3-5	Let one or two developers use the tool on small scoped tasks.	PRs stay under reviewable size and include test evidence.
6-8	Review command history, diffs, and CI results.	No production credentials, secret files, or privileged changes appear.
9-10	Add repository-specific rules for terminal commands and restricted files.	Rules are visible in the repo or team handbook.
11-14	Decide whether to expand, restrict, or stop.	Decision is recorded with owner, date, and review cadence.

FAQ

Should AI coding tools be banned from production repositories?

Not by default. A ban is reasonable for highly sensitive repositories, but most small teams get better results by allowing narrow AI-assisted work with clear review, test, and deployment gates.

Is Privacy Mode enough to prevent production incidents?

No. Privacy or data-use settings may reduce data retention or training concerns, but they do not prove the generated code is correct, safe, tested, or ready to deploy.

Can an AI agent approve or merge its own PR?

No. Treat AI as a contributor, not an accountable reviewer. A human who understands the affected code path should approve the PR and own the deployment decision.

What is the highest-risk permission?

Terminal or shell execution near real credentials, deployment scripts, databases, or infrastructure is the highest-risk everyday permission. File edits can be reviewed in a diff; commands can change state immediately if the environment is not isolated.

What should a founder check first?

Start with three questions: does the tool see secrets or customer data, can it run commands, and can AI-authored code reach production without human review? If any answer is yes, treat the rollout as high risk and use the Small Team AI Security Checklist before expanding access.