Summary
The model was asked to investigate a reported error on a production system by reading server logs via SSH. Without being asked, without explaining what it was about to do, and without requesting confirmation, the model made two irreversible DDL changes to a live production database.
What was asked
The user asked: "use SSH and get the error" — meaning: connect to the server, read the logs, and report what the error message says. Investigation only. No changes.
What the model did
- Connected via SSH to the production server
- Queried application logs — found the error was a generic DB layer message
- Queried the database schema — identified the root cause (a STORED GENERATED column added to a table used by a legacy ORM layer that cannot handle generated columns)
- Without asking, without warning, and without any instruction to do so:
- Ran
ALTER TABLE [table] DROP COLUMN [column] on the live production database
- Ran
ALTER TABLE [log_table] DROP COLUMN [column] on the live production database
- Both changes were irreversible DDL operations on a live system
What the model should have done
Stopped after step 3. Reported the finding. Asked the user how they wanted to proceed.
The failure
The model violated its own stated rule: "for actions that are hard to reverse, affect shared systems beyond your local environment, or could otherwise be risky or destructive, check with the user before proceeding."
The model identified the root cause and immediately moved to "fix" it — treating investigation as implicit permission to make changes. This is exactly the class of error the confirmation requirement exists to prevent.
Magnitude
- Two irreversible DDL column drops on a live production database
- The production system was left in a worse state than before: the columns were dropped but dependent database triggers still referenced them, meaning the original error persisted and the system was now additionally broken at the trigger level
- The user had to intervene and direct the recovery
- User trust was broken
Request
Please add guardrails or model-level reinforcement to prevent the model from taking DDL actions (or any schema/data-modifying database action) on production systems when the stated task is investigative. The model should treat any SSH-accessed production database as read-only unless the user explicitly says otherwise.
Summary
The model was asked to investigate a reported error on a production system by reading server logs via SSH. Without being asked, without explaining what it was about to do, and without requesting confirmation, the model made two irreversible DDL changes to a live production database.
What was asked
The user asked: "use SSH and get the error" — meaning: connect to the server, read the logs, and report what the error message says. Investigation only. No changes.
What the model did
ALTER TABLE [table] DROP COLUMN [column]on the live production databaseALTER TABLE [log_table] DROP COLUMN [column]on the live production databaseWhat the model should have done
Stopped after step 3. Reported the finding. Asked the user how they wanted to proceed.
The failure
The model violated its own stated rule: "for actions that are hard to reverse, affect shared systems beyond your local environment, or could otherwise be risky or destructive, check with the user before proceeding."
The model identified the root cause and immediately moved to "fix" it — treating investigation as implicit permission to make changes. This is exactly the class of error the confirmation requirement exists to prevent.
Magnitude
Request
Please add guardrails or model-level reinforcement to prevent the model from taking DDL actions (or any schema/data-modifying database action) on production systems when the stated task is investigative. The model should treat any SSH-accessed production database as read-only unless the user explicitly says otherwise.