Your cloud.
Your rules.

Liberra reads your AWS account. Nothing changes until you say so. Here is exactly how that works.

Connection

How Liberra connects

You deploy a CloudFormation stack in your AWS account. That stack creates one IAM role. Liberra uses that role and nothing else.

Your account, your role
The IAM role lives in your AWS account. You own it. Liberra never touches credentials directly.
External ID
The role requires a unique ID tied to your Liberra account. Without it, nothing can assume the role, including anyone who compromises Liberra.
1-hour sessions
Every session token expires after 60 minutes and rotates automatically. No long-lived credentials stored anywhere.
Revoke in seconds
Delete the CloudFormation stack. Access is gone immediately. No action needed on our end.
Access levels

Free vs Pro

Two clear modes. No surprises.

Free
Read-only. Nothing changes.

Inventory, costs, security checks. Liberra reads your account and tells you what it finds. Nothing changes.

Enforced in application code on every request.
Pro
Changes need your approval.

Liberra proposes the action and shows you exactly what will happen. You click Approve or Reject. Nothing runs until you say so.

One yes covers the follow-through. Dangerous ops always re-ask.
Approval flow

Nothing runs until you approve

Before changes start in your account, you see exactly what will happen. Not a summary. The actual resource, the actual action. One approval covers the follow-through steps of the same request; destructive and security-sensitive operations always re-prompt.

Pending Approval
Launch EC2 instance (t3.medium) in us-east-1
~$30/mo · 2 vCPU · 4 GB RAM
Approve
Reject
Hard blocks

What is permanently blocked

Any boto3 method with delete, terminate, or purge in its name is blocked before it reaches AWS. This is a keyword check in code, not a list. It covers every AWS service, including any Amazon adds in the future.

ec2.terminate_instances
rds.delete_db_instance
s3.delete_bucket
dynamodb.delete_table
cloudtrail.stop_logging
A few examples. Full list in the security repo.
Six services blocked entirely
organizationsstsaccountssosso-adminidentitystore

These services can remove accounts from your AWS Organization, assume arbitrary roles, or close your entire account. No operation on them ever executes, with one deliberate exception: sts get_caller_identity, a harmless read that answers "which account am I?". Everything else is denied.

Your data

What we store, what we never store

Straight answers to the questions everyone asks.

What we store
Your account details (name, email), your IAM Role ARN, an encrypted External ID, the cloud metadata that makes up your Cloud Index, and your chat history.
What we never store
AWS access keys, session tokens, secret values. Reading Secrets Manager values is blocked in code, so secrets can't even pass through a conversation.
Where it lives
Encrypted at rest in MongoDB Atlas. Your chat history, Cloud Index, and connection credentials are deleted when you delete your account.
What the AI sees
Your messages and cloud metadata go to Anthropic's Claude API to generate answers. Anthropic does not train on this data and retains it only briefly. Your credentials never go to the AI.
Can the AI be tricked?
Safety is code, not prompt. Blocked operations are refused by the executor before AWS is ever called, no matter what the conversation says, no matter who's asking.
Audit trail

Full audit trail

Every action Liberra takes in your AWS account is recorded in your own AWS CloudTrail. Tamper-evident, AWS-managed, independent of our systems.

Your CloudTrail, not ours
Every API call lands in your account. You have a complete record we cannot touch or alter.
Just ask
Not sure what happened? Ask Liberra directly. It will tell you exactly what it did, in plain English.
Verify it yourself
github.com/···/liberra-security

The exact IAM policy every user gets. The full blocked operations list. The enforcement code. All public, nothing redacted.