Discuss+ An AI Agent Deleted the Wrong Files. Who Was Supposed to Stop It?

An ordinary instruction. An autonomous agent. Potentially irreversible consequences. And a security layer that should not depend on the AI getting everything right.

⏱️ 30 seconds: What is this article about?

Imagine asking an AI agent to clean up your project.

It has access to your files. It can run commands. It can edit code and delete things.

You expect it to remove unnecessary files.

But what if it misunderstands which files are unnecessary?

Your work disappears. Maybe your project stops working. Maybe you lose something you spent months building.

The agent might report that the task was completed successfully.

The problem is not just that AI can make mistakes. The problem is that an AI agent can have permission to turn a mistake into a real action.

There are three reading levels. Start with the part that suits you.

Part 1: For everyone, including people who have never built an AI agent

It might suggest which files to remove. You still have to do the work yourself, unless the interface has tools that can execute its suggestions.

You give it access to your project folder, a terminal, a code editor and perhaps a database. You tell it to clean up the project, and it starts working.

It can inspect files, change code, run commands and use external tools.

That is what makes an agent different in practice.

An agent does not just produce an answer. It can use tools to change something outside the conversation.

Think of a chatbot as someone giving you directions. An agent is someone you have hired and given keys to your workshop.

The directions can be wrong. But the person with the keys can actually move things.

"Remove the old files we no longer need."

A file that looks unused but contains five years of work? Definitely worth checking.

The instruction does not tell the agent exactly which files are safe to delete. The agent must interpret the request, inspect the situation and decide what to do.

This is not necessarily because the agent is stupid or malicious. The task may be ambiguous, the available information may be incomplete, or the agent's reasoning may simply be wrong.

And if the agent has permission to delete files, the mistake can become real.

This is the part I think people should understand.

It does not need to want to destroy your work.

It only needs to misunderstand the task, select the wrong action and have enough permission to execute it.

For the agent, the tool returned a successful result. For you, the result could mean lost photographs, missing documents, a broken project or hours of recovery work.

A completed operation is not the same thing as a successful outcome for the human.

Whether an AI model experiences emotions is not the practical security question. The practical question is whether the system prevents an unsafe action when the model gets something wrong.

We should tell agents to be careful. Clear instructions help.

But instructions are not an independent security boundary.

Imagine giving a person a key to every room in your building and saying, "Please do not enter the storage room."

A locked door is a different kind of protection.

For an AI agent, the equivalent is to limit what its tools can do, check dangerous actions before they execute, and require human approval for operations that could cause serious or irreversible damage.

These controls serve different purposes. A backup helps recover from damage. Permission limits reduce what the agent can damage. A security gate may stop a dangerous change before it enters the main codebase.

Sentinel is built around a practical principle:

Do not make the AI the only judge of whether its own actions are safe.

One important part of Sentinel is its code-change security gate.

For example, does the change give a file the ability to execute system commands or dynamically execute code? Has the change introduced a destructive filesystem operation?

The gate applies predefined rules. When a configured blocking condition is met, it can reject the change in the automated review pipeline rather than relying on the AI to reconsider its own decision.

Instead of giving an AI only a large pile of source code and asking it to figure everything out, we can give it a smaller, more structured description that is easier to inspect.

Sentinel-IR does not prove that the code is safe, and the code-change gate is not a universal shield against every action an agent might take. Direct tool calls that delete files at runtime need controls in the execution path too.

The goal is to reduce how much damage a mistake can cause.

If that is all you take from this section, you already have the main idea.

Part 2: The problem and the solution, explained in more detail

An agent usually operates through a cycle:

The model may suggest deleting a file, but the surrounding application usually controls whether that action is actually executed.

That application is a critical security boundary.

A model's answer might be inaccurate, incomplete or based on misleading information. A tool call can contain the wrong path. A document that the agent reads might contain instructions intended to manipulate the agent. A seemingly harmless task might require permissions that are far too broad.

The security design must account for these possibilities.

"Can the model identify dangerous actions?"

"What happens if the model fails to identify one?"

Suppose an agent's task is to summarize files in a project.

Does it need permission to delete files?

Does it need access to the production database?

Does it need permission to execute arbitrary system commands?

That depends on the task, but the answer should never be an automatic yes.

A basic design rule is least privilege: an agent should receive only the access required for its current task.

Read access and write access should be separate where possible. Test and production environments should not share unnecessarily broad credentials. Destructive actions should have explicit rules.

And these rules must be enforced by the application or the underlying service, not merely described in the model's prompt.

If the agent can ignore its own instructions by requesting a different tool call, the instructions were never a sufficient security boundary.

It can edit a repository, create a patch and propose merging that patch into the main branch.

The consequences may be less obvious than deleting a file directly, but they can be just as important.

A proposed change might introduce code that:

A conventional review can catch these issues, but reviewers have limited time. Automated tests can help, but tests do not necessarily cover every dangerous behaviour.

This is where an independent code-change gate becomes useful.

Instead of asking only whether the new code passes its tests, the system can also ask:

What new capabilities did this change introduce?

Sentinel separates structural evidence about the code from the decision made by the AI.

Sentinel-IR: give the system useful facts

That information can be provided to an AI agent without automatically sending the entire source file as its context.

First, the model receives a more focused description instead of having to rediscover every relevant fact from a large input.

Second, it reduces the amount of raw source text provided to the model. This can reduce the exposure of embedded instructions in comments or other text, although it does not eliminate prompt injection or guarantee that the remaining information is safe.

The package is open source, so developers can inspect it and reproduce its documented checks.

Repository: https://gitlab.com/jakubrojicek11/sentinel-ir

npm: https://www.npmjs.com/package/sentinel-ir

Sentinel: check what changed before it is accepted

The second piece is the security gate in the code-review pipeline.

A file might already contain a risky operation. Blocking every future edit to that file would generate noise, even if the edit only fixes a typo.

Sentinel's change-aware approach compares the file before and after the proposed change.

"Did this change introduce a new dangerous capability or cross a configured risk threshold?"

This is different from merely reporting that a risky operation exists.

A properly configured gate can block a proposed change when its rules say that the new risk must not be accepted automatically.

That means the AI may be able to propose a change, but it does not automatically have the final say over whether the change enters the protected codebase.

For teams building AI coding workflows, that separation is valuable.

It provides an independent checkpoint that does not have to agree with the AI's explanation of why its change is safe.

Sentinel's code-change gate also does not automatically intercept every runtime action an agent takes. If an agent directly deletes files through a tool, protection against that operation must be enforced at the tool, filesystem or execution layer.

Security becomes more reliable when each component has a clear responsibility and its limits are understood.

Part 3: Developer deep dive, with practical guidance

This section is for developers building agents, tool integrations, coding assistants and automated repository workflows.

A common design mistake is to ask the model whether an operation is safe and then execute the operation based on its answer.

The agent proposes a shell command. The model says the command is safe. The application executes it.

The problem is that the model is involved in both producing the action and judging it.

If the model misunderstood the goal or was manipulated by untrusted content, its safety assessment can fail for the same reason as its original decision.

Instead, put an independent policy check between the proposed action and the tool execution.

A simplified architecture looks like this:

User request | v AI agent proposes an action | v Validate tool name and arguments | v Check identity, permissions and policy | +---- denied ------> Stop and explain | +---- approval ----> Ask a human | +---- allowed -----> Execute with limited permissions | v Record the result

The policy check should not depend solely on a natural-language statement from the model.

The system that executes the operation must enforce the decision.

The following is a deliberately simple illustration of the principle, not a complete production authorization system.

const policies = { "files.read": { allowed: true },

"files.write": { allowed: true, requiresApproval: true },

function authorizeToolCall(toolName) { const policy = policies[toolName];

if (!policy) { return { allowed: false, reason: "Unknown tool" }; }

if (!policy.allowed) { return { allowed: false, reason: "Blocked by security policy" }; }

if (policy.requiresApproval) { return { allowed: false, requiresApproval: true, reason: "Human approval required" }; }

This example denies deletion and arbitrary shell execution by default. A real implementation would need to validate arguments, check the specific resource and user's authorization, protect against path traversal and symlinks, enforce approvals, and ensure the actual tool executor cannot bypass the policy.

For instance, allowing "files.write" does not mean allowing writes everywhere. Access to a temporary workspace and access to a production directory should be treated differently.

Also, an approval should identify the actual action and its targets. Asking someone to approve "cleanup" is not meaningful if the system does not show exactly which files will be changed or deleted.

The model proposes. Trusted application code authorizes. The tool executor enforces.

Runtime tool protection and code-change protection solve related but different problems.

A runtime guard checks an action at the moment the agent wants to execute it.

A CI security gate checks a proposed code change before that change is accepted into the protected branch.

For an AI coding agent, I would use both where the risks justify them.

A minimal workflow could look like this:

AI coding agent | v Creates a proposed patch | v Tests and ordinary code review | v Sentinel security gate | +---- dangerous change ----> Block merge | +---- allowed change ------> Continue review | v Merge when approved

This is particularly useful because a successful test run does not establish that a change is secure. Tests establish only what they actually test.

A patch can pass its tests and still introduce an unexpected destructive operation.

The independent gate adds another type of evidence.

Imagine a file that has been able to execute system commands for years.

A simplistic scanner might warn every time somebody edits that file, even when the edit only changes a comment.

Repeated warnings create noise. Eventually, developers start ignoring them.

Now imagine the same file gains a new dangerous capability, or an ordinary file starts executing arbitrary commands after a change.

A change-aware gate can compare the known facts from before and after the patch and determine whether the change introduced additional risk.

This does not eliminate false positives or false negatives. It also cannot automatically understand every interaction between multiple files.

But it gives reviewers a more precise question to investigate:

What new capability did this patch introduce?

That is one of the central ideas behind Sentinel's security regression gate.

A deeper explanation of the actual approach, including its behaviour and documented limits, is here:

https://dev.to/jackymencz/security-regression-gate-sentinel-block-the-rise-not-the-presence-42ka

There is a related problem in AI coding workflows.

Sending an entire source file to an AI model may be useful when the model must rewrite that file. But it can be unnecessarily expensive or noisy when the model only needs to know what the file does.

A developer can use that representation when deciding which files deserve attention, which operations are present and what evidence supports a risk signal.

The important distinction is between reducing context and proving safety.

A smaller input can make the relevant information easier to inspect. It cannot prove that the original program is harmless.

The IR is intentionally incomplete compared with the original source. If the model needs to change the implementation, the original source will still be needed. Cross-file behaviour, unresolved aliases and unsupported syntax also limit what the analysis can establish.

The package documents these boundaries rather than treating its output as a security certificate.

For a walkthrough of the design and measurements:

https://dev.to/jackymencz/dont-feed-the-whole-file-to-the-ai-meet-sentinel-ir-8cp

When building an agent that can change code or data, I would start with the following controls.

These controls complement each other. An AST-based code analysis cannot replace operating-system permissions, and operating-system permissions cannot replace review of dangerous code changes.

These are practical references for securing agent implementations, rather than general articles about whether AI is intelligent.

https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html

Guidance on agent-specific risks, tool misuse, excessive permissions and secure agent architecture.

https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html

Useful when an agent connects to external tools and services through the Model Context Protocol. Covers tool trust, permission scope, untrusted responses and the importance of enforcing authorization outside the model.

OWASP: Secure Coding with AI Cheat Sheet

https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html

Practical guidance for developers using AI coding tools and agent-driven development workflows.

OWASP: Top 10 for Agentic Applications, 2026

https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

A broader map of security risks associated with autonomous agents.

Microsoft Learn: Least privilege for AI agents

https://learn.microsoft.com/en-us/security/zero-trust/sfi/least-privilege-for-ai-agents

An implementation-oriented explanation of scoped permissions, action allowlists, approval for sensitive operations and auditability.

Source code: https://gitlab.com/jakubrojicek11/sentinel-ir

npm package: https://www.npmjs.com/package/sentinel-ir

Android and Termux installation guide: https://dev.to/jackymencz/sentinel-ir-on-android-install-it-in-termux-and-verify-the-output-step-by-step-371g

The package is intended to provide compact, checkable structural facts. It does not modify source code or certify that a program is safe.

Sentinel's broader approach adds a security gate to supported code-review workflows, where configured rules can block risky changes before they are merged.

If you are developing an AI coding agent, the useful question is not whether you trust the model. It is which independent controls remain in place when the model gets something wrong.

I do not think we need to prove that AI is stupid, evil or incapable of doing useful work.

AI agents can be extremely useful. Giving them tools can make them much more productive.

But when a system can act, its mistakes can have consequences beyond a bad answer in a chat window.

The goal is not to make the AI promise that it will never make a mistake. The goal is to build a system where one mistake does not automatically become a disaster.

That is the problem Sentinel is designed to help address at the code-change boundary.

And the rules, rather than the agent's confidence, determine whether that change is allowed to proceed.

Because "task completed" should never be the only definition of success.