AI Agent Risk: The 7 Actions You Should Never Let Run Unattended

Not all AI agent actions carry the same risk. Some are low-stakes and reversible — writing code, running tests, reading documentation. Others are high-stakes and irreversible — deploying to production, deleting data, sending emails to thousands of users.

The difference matters. When an AI agent makes a mistake on a low-risk action, you fix it and move on. When it makes a mistake on a high-risk action, you're dealing with downtime, data loss, or reputational damage.

This guide identifies the seven categories of actions that should never run unattended — the ones that require explicit human approval before execution, every time.

Why These Seven Categories

These categories share three properties:

1. Irreversible or expensive to reverse. Once executed, the action can't be undone cleanly, or undoing it requires significant effort and time.
2. Consequences extend beyond local environment. The impact isn't contained to your development machine — it affects production systems, other developers, or external users.
3. Context-dependent risk. Whether the action is safe depends on details the agent might not have — which environment, which recipients, which branch, which database.

For each category below, we explain what makes it risky, show real examples of what goes wrong, and describe what a proper approval gate should look like.

1. Deployment and Infrastructure Changes

What it includes: Pushing code to production, triggering CI/CD pipelines, modifying deployment configurations, changing DNS settings, updating load balancer rules, scaling infrastructure resources.

Why it's risky: Deployment is the moment code becomes real. A bad deploy can take down your service, break integrations, or expose security vulnerabilities. And unlike code changes in a branch, a production deploy affects live users immediately.

Real example: A developer asked their AI agent to "make sure the deployment is ready." The agent interpreted this as permission to trigger the deploy pipeline — at 3am, while the developer was asleep. The untested build went to production and caused a four-hour outage.

What the approval gate should show:

• Target environment (production, staging, etc.)
• Branch and commit being deployed
• Services or components affected
• The exact command that will be executed

2. Database Writes in Production

What it includes: Any INSERT, UPDATE, DELETE, DROP, TRUNCATE, or ALTER statement that targets a production database. Also includes running migration scripts or data backfill operations.

Why it's risky: Production data is the source of truth for your application. Deleting or corrupting it means losing customer information, transaction history, or business-critical records. Backups help, but they're never as current as you need them to be, and restoring from backup means downtime.

Real example: A developer asked an AI agent to "remove the test data from the database." The agent ran a DELETE query — on the production database, because the environment variable was set to production. 25,000 customer records were deleted. The team spent two days restoring from an 18-hour-old backup.

What the approval gate should show:

• Database name and environment (production vs. staging)
• The exact SQL statement to be executed
• Estimated number of rows affected
• Whether a backup exists and how recent it is

3. Destructive Git Operations

What it includes: Force pushing (git push --force), deleting branches, rebasing or squashing commits on shared branches, resetting to a previous commit, rewriting history.

Why it's risky: Git is designed to preserve history. Destructive operations break that guarantee. When you force-push to a shared branch, other developers' local histories diverge from the remote, leading to merge conflicts and lost work. When you delete a branch someone else is working on, their work becomes orphaned.

Real example: A developer asked an AI agent to "clean up the commit history before we merge." The agent ran git rebase -i, squashed commits, and force-pushed to the shared branch. Three other developers had work based on that branch. Their local histories were now diverged, and two hours of merge conflict resolution followed.

What the approval gate should show:

• The branch being modified
• Whether the branch is shared (has other contributors or open PRs)
• The specific operation (force push, delete, rebase)
• Commits that will be affected or removed

4. Outbound Communication

What it includes: Sending emails, posting to Slack or other chat platforms, sending SMS messages, triggering webhooks to external services, posting to social media, creating or commenting on GitHub issues or pull requests.

Why it's risky: Once a message is sent, you can't unsend it. If the agent sends an email to the wrong recipients, or posts a half-finished message to a public channel, the damage to your reputation or customer relationships is immediate. And unlike code or data, there's no "undo" button for communication.

Real example: A developer was testing an email notification system. They asked their AI agent to "send a test email to verify the integration is working." The agent sent the email — to all 8,000 users on the production mailing list. The company spent the next week managing customer support tickets and reputation damage.

What the approval gate should show:

• The full message content
• All recipients (email addresses, Slack channels, webhook URLs)
• The sending account or service being used
• Whether this is a test environment or production

5. Credential and Secret Management

What it includes: Creating, rotating, or deleting API keys, passwords, access tokens, SSH keys, or certificates. Also includes storing credentials in configuration files, environment variables, or secret management systems.

Why it's risky: Credentials are the keys to your infrastructure. If an agent commits an API key to a public repository, or deletes a credential that's still in use, the consequences range from service outages to security breaches. And credential leaks are often discovered by attackers before you notice them yourself.

Real example: A developer asked an AI agent to "set up the API integration and make sure it works." The agent wrote the integration code, added the API key to a config file, tested it, and committed everything to Git — including the API key in plaintext. The key was pushed to a public GitHub repository. Within hours, it was scraped and used to rack up $4,000 in API charges.

What the approval gate should show:

• The type of credential being created, modified, or deleted
• Where the credential will be stored
• What services or systems will have access to it
• Whether the credential is being committed to version control

6. File Deletion

What it includes: Deleting files from version control (git rm), removing files from production file systems, clearing directories, deleting build artifacts that might be needed for rollback.

Why it's risky: File deletion is often irreversible, especially in production environments. Even in version control, recovering a deleted file requires knowing it existed in the first place. And if the agent deletes the wrong file — a configuration file, a critical script, or a data file — the impact can be immediate service disruption.

Real example: An AI agent was asked to "clean up the old migration files." It deleted all migration files older than six months — including ones that were still referenced by the current database schema. The next deployment failed because the migration history was incomplete.

What the approval gate should show:

• The full path of each file being deleted
• The size and last modified date of each file
• Whether the file is in version control or a production system
• Whether the file is referenced by other parts of the codebase

7. Third-Party API Calls with Side Effects

What it includes: Any API call to an external service that modifies state — processing payments, creating or deleting user accounts, sending notifications through third-party services, modifying data in external systems (CRM, analytics, etc.).

Why it's risky: Third-party APIs often have rate limits, cost money per call, or trigger actions that affect real users. An agent that calls a payment API with the wrong parameters can charge customers incorrectly. An agent that calls a user management API can lock people out of their accounts. And unlike your own infrastructure, you can't just roll back a third-party API call.

Real example: An AI agent was asked to "test the payment integration." It called the payment API with what it thought were test credentials — but the credentials were for the production environment. Several test transactions went through, charging real customers. The refund process took days and required manual intervention.

What the approval gate should show:

• The API endpoint being called
• The full request payload
• Whether this is a test or production environment
• The expected side effects (charges, account changes, notifications)

How to Implement Approval Gates

An approval gate isn't just a confirmation dialog. It's a decision point where the human sees exactly what the agent is about to do and makes an informed choice.

A good approval gate has three properties:

1. Mandatory, not optional. The agent can't proceed without approval. There's no "skip" button, no timeout that auto-approves.
2. Specific, not generic. The prompt shows the exact command, the exact recipients, the exact environment — not just "deploy to production" but which service, which commit, which configuration.
3. Blocking, not advisory. The action doesn't happen until the human says yes. The agent waits, it doesn't proceed and notify you after the fact.

For each of the seven categories above, the approval gate should be triggered automatically based on the action type — not based on the agent's judgment of whether something is "risky."

What About Low-Risk Actions?

Not every action needs approval. The goal isn't to slow down the agent — it's to prevent irreversible mistakes.

Low-risk actions that should run freely:

• Writing or modifying code in a branch
• Running tests in a local or CI environment
• Reading files, documentation, or logs
• Installing dependencies or packages
• Creating new branches
• Committing changes to version control (but not pushing to shared branches)

These actions are reversible, contained to your local environment, and don't affect other developers or production systems. The agent should be able to do them autonomously — that's the whole point of having an agent.

The seven categories above are different. They're the actions where a mistake has consequences that extend beyond your local machine, and where "undo" isn't an option.

The Bottom Line

AI agents are powerful because they can execute tasks end-to-end. But that power comes with risk.

The solution isn't to limit what agents can do. It's to put mandatory approval gates on the actions that matter — the ones where a mistake is expensive or irreversible.

These seven categories cover the vast majority of high-risk actions in software development. If your AI agent can execute any of them without showing you exactly what it's about to do and waiting for approval, you're one ambiguous prompt away from an incident.

For more on how approval gates should work in practice, see our guide: Human-in-the-Loop AI: What It Actually Means in 2026.