The rule that stops uslives in your account.
Not our promise. Your cloud's.
Every claim below is one you can check yourself, in sixty seconds.
What it cannot do
- Can it delete my stuff?
- No. delete, terminate and purge are refused before the call leaves our servers. All three clouds, every service, including ones that do not exist yet.
- What if you get breached?
- It still cannot delete. An attacker inside our servers can skip our code. They cannot skip your cloud. That is why the rule is written into your account, not ours.
- Can it act without asking?
- No. Every write stops on a card naming the exact resource and action. Reads run free.
- Do you keep my keys?
- Never. On AWS we hold a token that dies in an hour. On Azure and GCP we hold nothing at all.
Three clouds. Who does the refusing.
The role in your account denies 332 destructive actions, derived from AWS’s own service definitions. In IAM, a deny beats every allow, including your own admin’s.
- You grant
- One CloudFormation stack.
- You revoke
- Delete the stack.
Liberra never issues an ARM DELETE. Azure cannot be told to refuse one for us. This is the weakest of the three and we would rather you knew.
- You grant
- One Lighthouse delegation.
- You revoke
- Remove the delegation.
An optional second paste at setup adds a deny policy over 60 permission groups. It covers permissions Google has not shipped yet.
- You grant
- One IAM binding.
- You revoke
- Remove the binding.
Don't take our word. Ask your cloud.
If an answer here ever contradicts this page, the answer is right.
aws iam get-role-policy --role-name <your-liberra-role> --policy-name LiberraStandardPolicy
aws iam simulate-principal-policy --policy-source-arn <your-liberra-role-arn> --action-names ec2:TerminateInstances s3:DeleteBucket
Both come back explicitDeny. That is AWS answering about our access, not us.
az managedservices assignment list
A built in Azure role, scoped to the one subscription you picked.
gcloud iam policies describe liberra-no-destroy --attachment-point=cloudresourcemanager.googleapis.com/projects/<project-id> --kind=denypolicies
Google lists what it will refuse us.
Every role we generate is stamped with the version it was built from.
aws iam list-role-tags --role-name <your-liberra-role>
Compare PolicyVersion against the policy published in the repo. If they match, the file you read is the rule you are living under.
What we actually have of yours
- Cloud access keys
- None. They do not exist in our system.
- Session tokens
- AWS only, in memory, one hour. Never written to disk.
- Secret values
- Never. Reading one is blocked in code on AWS and GCP.
- Your chat history
- Stored as plain text. Deleted with your account.
- Your Cloud Index
- Stored as plain text. Resource names, ports, relationships: a map of your infrastructure. Deleted with your account.
- External ID, Terraform state
- Stored, encrypted under a key kept apart from the database.
- What the AI is sent
- Your messages and cloud metadata go to Anthropic. Deleted within 30 days, never used to train a model. Credentials are never sent.
The two marked rows are answered below.
What we have not solved
Not by us, not by anyone. Text from your own cloud reaches the model and a crafted string can try to steer it. Our answer is not that the model cannot be fooled. It is that a fooled model still cannot delete, and still cannot write without your click.
We checked all four routes and Lighthouse allows none of them. On AWS and GCP the cloud refuses us. On Azure only our code does, and that is a weaker guarantee.
They sit in an encrypted database, but without the extra layer we put on your External ID and Terraform state. On a bad day that index is worth more to an attacker than a one hour token. It is on the list. It is not done.
That phrase means nothing. What we have instead is this page: public enforcement code, the rule in your account, every claim checkable without asking us. We start SOC 2 when a real deal turns on it.