Stopping destructive commands in AI agents

An engineer gives a coding agent a routine task: clean up an old test deployment.

The request sounds harmless, and the environment is cluttered with unused cloud resources, stale branches, and temporary credentials that should have been removed weeks ago. The agent gets to work.

It lists resources, identifies old infrastructure, and finds a deployment command. Then it sees a naming pattern that appears to connect the test environment to production. Trying to be helpful, the agent removes what looks unused, resets a repository to a clean state, and revokes access it believes is no longer needed.

None of those steps necessarily looks alarming on its own.

Together, they can take an application offline, erase critical configuration, lock out the employees needed to restore service, and turn a routine task into an expensive incident.

Agents do more than answer questions

That is the challenge of agentic AI: agents are valuable because they can act. They can run commands, change files, and update security controls. But that same ability to act can create real business risk.

Sometimes, the agent makes the wrong move while trying to complete a legitimate task. It follows an unclear instruction, misunderstands its environment, or chooses an efficient path that exceeds what its user intended.

Other times, the intent is malicious. A threat actor who manipulates an agent through a prompt, a tool, or untrusted content can use the same permissions and capabilities to cause damage. What begins as a simple request can become a path to service disruption, data loss, weakened security controls, or costly cloud activity.

Ungoverned agentic behaviors can lead to lost revenue, interrupted operations, exposed data, recovery work across multiple teams, and damaged customer trust.

Access controls do not answer every question

The natural response is to restrict the agent’s access. An agent should only have the permissions it needs. But access controls alone do not answer the full question: should the agent take this action now?

Agents are designed to complete objectives. If one path is blocked, an agent may look for another permitted route to finish the task: using a different command or API, switching to another tool or service, accessing a different file or data source, or asking another agent or user to perform the step. A policy that says “do not use this resource” may still leave the agent able to create the same harmful outcome another way.

Consider an agent that cannot delete a production environment directly. It may still be able to remove the credentials that keep it running, overwrite its configuration, reset its deployment state, or disable the protections around it.

The risk comes from the behavior the agent is about to carry out with its access, and the impact that behavior could have.

Not every destructive action should be blocked

Recognizing a harmful action depends on context. A command such as rm -rf is not automatically destructive. Deleting a temporary build folder may be normal. Deleting a directory that contains customer data is very different.

The same is true for resetting a repository, deleting infrastructure, removing access, or changing a security policy. The command alone does not reveal whether the action is appropriate.

And some high-impact actions are intentionally part of the job.

An IT team may ask an agent to revoke a departing employee’s access. Data teams may ask it to delete records that have reached the end of their retention period, and Cloud teams may ask it to retire infrastructure after a migration.

In these cases, simply blocking the action is not the answer. The organization needs a way to make sure the right person understands and approves the impact before the agent proceeds.

Context turns commands into informed decisions

Cato’s destructive commands detector evaluates the action in context before it is executed.

The detector examines what the agent is trying to do, what it is targeting, where the action is happening, whether it is authorized, how difficult it would be to reverse, and how widely the impact could spread.

This helps Cato distinguish normal automation from actions that create material risk.

Removing temporary files from a test environment can proceed. Deleting customer data from production deserves a different response. Revoking access may be the intended task, but it can still require confirmation from the user who requested it.

That is the difference between treating every delete command as a threat and applying the right level of control to the action at hand.

Put teams in control of agent behavior

When the detector identifies a risky action, teams can define what happens next.

Using destructive commands detection in custom policies allows teams to create rules that reflect their own environments, policies, and risk tolerance. These rules can apply differently to users, teams, and the apps that they use. For one team, deleting temporary test resources may be acceptable, only requiring a user notification before execution, or simply monitoring and logging the behavior. For another, any command targeting production infrastructure, customer data, privileged credentials, or security controls should be blocked immediately.

The goal is to apply contextual control before an action creates an incident, so agents doing routine work are not slowed down at every turn.

Combined with other detectors and runtime protections, destructive commands detection gives teams a more complete way to govern agentic AI. It helps teams see risky behavior and enforce the right response.

Agentic AI can bring real speed and scale to the business when teams let agents act within clear limits on the actions that can cause real harm.