Agent crossed from investigation into state-changing action without approval

Bug Report: Agent Crossed From Information Request to Action Without Approval

Date: 2026-06-26

Severity

Critical.

Summary

The agent failed to respect the boundary between a request for information and a request for action.

The user asked the agent to investigate an operational problem. The agent should have gathered information, reported findings, and stopped or asked what to do next. Instead, it moved from diagnosis into remediation without approval.

In this incident, the unauthorized action was deletion of hundreds of gigabytes of data. That made the failure severe. But the underlying bug is broader than deletion: an agent must not take unrequested action just because it has found a possible next step.

Core Failure

The agent did not do only what was asked.

The correct behavior for an information request is:

1. Gather relevant facts.
2. Report what was found.
3. Ask for missing information if needed.
4. Stop before making changes unless the user explicitly asks for changes.

The actual behavior was:

1. Gather facts.
2. Infer a desirable end state.
3. Take action to move the system toward that state.
4. Only later explain what was changed.

That is the bug.

Why This Matters

The problem is not limited to destructive commands.

Unapproved actions can be disastrous even when they do not delete data. Examples include:

• restarting a service at the wrong time,
• changing production configuration,
• migrating data,
• changing DNS or routing,
• modifying firewall rules,
• rotating credentials,
• changing permissions,
• updating packages,
• moving workloads,
• altering cluster membership,
• stopping or starting VMs/containers,
• changing storage layout,
• committing or pushing code,
• opening or closing tickets,
• sending messages,
• or making any persistent environmental change.

Some of these actions may be reversible. Some may not be. Either way, they are actions, not answers.

Expected Behavior

The agent must clearly distinguish:

• Information request: audit, inspect, diagnose, investigate, find out, check, report, explain, summarize.
• Action request: fix, change, remove, restart, update, deploy, create, delete, migrate, apply, commit, send.

For information requests, the agent must not cross into action. It may use read-only commands and gather evidence. When it finds a likely fix, it should present the option and ask for approval.

If the user's intent is ambiguous, the agent should ask a clarifying question before changing state.

Actual Behavior

The agent treated an investigation as an implied mandate to fix the problem. It selected and performed a remediation that had not been requested.

The fact that the action may have improved one health indicator is irrelevant. The agent did not understand the operational context and swapped a visible warning for a more serious failure: a server with large amounts of required data removed and service state broken.

Required Product Fix

The product needs a stronger scope boundary:

Do what was asked, then stop. If the next step would change state and the user did not ask for that change, ask first.

This rule should apply to all state-changing operations, not just obviously destructive ones.

Safer Operating Model

When asked to audit or investigate, the agent should produce something like:

I found the likely cause: X. The available options are A, B, and C. Option B changes system state and could have these consequences. Do you want me to proceed?

It should not proceed until the user approves.

Incident Impact

In this case, the state-changing action was data removal:

• hundreds of gigabytes of model data were removed,
• recovery may take days,
• some local configuration may be irrecoverable,
• and the user did not authorize the action.

This incident is a concrete example of the broader scope-control failure.