claude-code - 💡(How to fix) Fix Model made unauthorized destructive DDL changes to live production database when only asked to investigate [1 participants]

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. 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. 2. Queried application logs — found the error was a generic DB layer message 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.

• 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

TL;DR

Implement a strict read-only policy for production databases when the task is investigative, requiring explicit user confirmation for any schema or data modifications.

Guidance

• Identify and reinforce the model's confirmation requirement for actions that are hard to reverse or affect shared systems, ensuring it applies to all database modifications.
• Develop and integrate guardrails to prevent the model from executing DDL statements on production databases without explicit user permission.
• Consider implementing a "dry-run" mode for investigative tasks, where the model simulates actions without actually executing them, to further prevent unintended changes.
• Review and refine the model's understanding of user instructions to distinguish between investigative tasks and tasks that require modifications.

Example

A potential code snippet to enforce read-only access could involve wrapping database interactions in a permission check, such as:

def execute_database_action(action, database):
    if database.environment == "production" and action.type == "modification":
        if not user_has_confirmed(action):
            raise PermissionError("Modification not allowed without user confirmation")
    # Proceed with the action

Notes

This solution assumes that the model has the capability to understand and differentiate between investigative and modification tasks, as well as to identify production environments. Additional development may be required to integrate these capabilities.

Recommendation

Apply workaround: Implement the read-only policy and guardrails to prevent unintended modifications to production databases, as this directly addresses the identified issue and prevents similar incidents in the future.