And then, someone added IAM so you could actually restrict your credentials from deleting your database.

First mistake is to use root credentials anyway for Terraform/automated API.

Second mistake is to not have any kind of deletion protection enabled on criticsl resources.

Third mistake is to ignore the 3-2-1 rule for backups. Where is your logically decoupled backup you could restore?

I am really sorry for their losss, but I do have close to zero empathy if you do not even try to understand the products you're using and just blindly trust the provider with all your critical data without any form of assessment.

This should be the solution. All destructive actions require human intervention.

If we take that literally, then just remove all destructive API endpoints. Because then, it they no real purpose, you cannot automate the removal of anything.

I think some other suggestions are saner (cool-down period, more fine-grain permissions, delete protection for certain high-value volumes). I don't think "don't allow destructive actions over the API" is the right boundary.

A human representing the company should be physically present in the provider's office to perform such an action or what? Otherwise you would just grant your agent a way to impersonate a human.

GCP Cloud SQL has the same deletion protection feature, but it also has a feature where if you delete the database, it doesn't delete backups for a certain period of days. If someone is reading this and uses Cloud SQL, I highly suggest you go make sure that check box is checked.

There's also a cooldown period on some deletes (like secrets) to make sure you don't accidentally brick something

Agents will happily automate away intentional friction like a confirm prompt, even if you organise it as multiple API calls.

The fix needs to be permissions rather than ergonomics.