​
Overview

Cloudlvl works similarly to Terraform when it comes to AWS permissions. The AI agent needs specific permissions to create, update, or delete AWS resources on your behalf. You control exactly what the AI can do by configuring the appropriate IAM permissions.
Key Principle: The AI agent only gets the permissions you explicitly grant. If you don’t give it permission to create EC2 instances, it won’t be able to create them, even if you ask it to.

​
How Permissions Work

​
The Terraform Analogy

Just like Terraform, Cloudlvl:
  1. Indexes your current infrastructure (no permissions needed - done during deployment)
  2. Plans changes based on your requests using the indexed data
  3. Applies changes to AWS resources (requires write permissions)
  4. Manages state and tracks what it has created
Important: When you ask “List my EC2 instances”, the AI agent doesn’t query AWS directly. It uses its indexed knowledge of your infrastructure from the last deployment. This means no read permissions are required for viewing your current resources.

​
Permission Levels

You only need to configure permissions for actions that modify your infrastructure:

Service-Level

Grant access to entire AWS services (e.g., all EC2 operations)

Action-Level

Grant specific actions (e.g., only create and describe instances)

Resource-Level

Limit access to specific resources (e.g., only instances with certain tags)

Condition-Based

Add conditions like time, IP, or MFA requirements

​
Common Permission Scenarios

​
Scenario 1: Web Application Infrastructure

What you want to build: A typical web app with EC2, RDS, and Load Balancer Required permissions: 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:RunInstances",
        "ec2:DescribeInstances",
        "ec2:TerminateInstances",
        "ec2:CreateSecurityGroup",
        "ec2:DescribeSecurityGroups",
        "ec2:AuthorizeSecurityGroupIngress",
        "rds:CreateDBInstance",
        "rds:DescribeDBInstances",
        "rds:DeleteDBInstance",
        "elasticloadbalancing:CreateLoadBalancer",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DeleteLoadBalancer"
      ],
      "Resource": "*"
    }
  ]
}
Example AI commands this enables:
  • “Create a web server with a MySQL database”
  • “Add a load balancer to distribute traffic”
  • “Scale up to 3 web servers”

​
Scenario 2: Serverless Application

What you want to build: Lambda functions, API Gateway, and DynamoDB Required permissions: 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "lambda:CreateFunction",
        "lambda:UpdateFunctionCode",
        "lambda:DeleteFunction",
        "lambda:ListFunctions",
        "apigateway:*",
        "dynamodb:CreateTable",
        "dynamodb:DescribeTable",
        "dynamodb:DeleteTable",
        "iam:CreateRole",
        "iam:AttachRolePolicy",
        "iam:PassRole"
      ],
      "Resource": "*"
    }
  ]
}
Example AI commands this enables:
  • “Create a REST API with Lambda backend”
  • “Add a DynamoDB table for user data”
  • “Set up CRUD operations for my API”
What this restricts:
  • Only allows t2 and t3 instance types (cost control)
  • Limits to specific regions
  • Perfect for development workloads

​
AWS Managed Policies

For quick setup, you can use AWS managed policies:

PowerUserAccess

Best for: Most production use cases
Includes: All services except IAM user management

AdministratorAccess

Best for: Full control scenarios
Includes: Everything (including IAM)

EC2FullAccess

Best for: Compute-focused workloads
Includes: Complete EC2 management

Custom Policy

Best for: Specific requirements
Includes: Only what you define

​
Creating Custom Policies

​
Step-by-Step Policy Creation

  1. Identify what you want to build
    • List the AWS services you’ll need
    • Think about the lifecycle (create, update, delete)
  2. Find the required actions
    • Use AWS documentation to find action names
    • Consider both primary and supporting actions
  3. Test with minimal permissions
    • Start restrictive and add permissions as needed
    • Monitor CloudTrail logs for denied actions

​
Example: Building a Custom Policy

Let’s say you want the AI agent to manage S3 buckets and CloudFront distributions: 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3Management",
      "Effect": "Allow",
      "Action": [
        "s3:CreateBucket",
        "s3:DeleteBucket",
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:PutBucketPolicy",
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": ["arn:aws:s3:::cloudlvl-*", "arn:aws:s3:::cloudlvl-*/*"]
    },
    {
      "Sid": "CloudFrontManagement",
      "Effect": "Allow",
      "Action": [
        "cloudfront:CreateDistribution",
        "cloudfront:GetDistribution",
        "cloudfront:UpdateDistribution",
        "cloudfront:DeleteDistribution",
        "cloudfront:ListDistributions"
      ],
      "Resource": "*"
    }
  ]
}
This policy allows:
  • ✅ Managing S3 buckets that start with “cloudlvl-”
  • ✅ Full CloudFront distribution management
  • ❌ Cannot access other S3 buckets
  • ❌ Cannot manage other AWS services

​
Permission Testing

​
How to Test Your Permissions

  1. Start with a simple request (no permissions needed) 
    "List my current EC2 instances"
    This works immediately as it uses indexed data
  2. Try creating something small (requires permissions) 
    "Create a small test S3 bucket"
    This requires s3:CreateBucket permission
  3. Test modifications (requires permissions) 
    "Add a lifecycle policy to that bucket"
    This requires s3:PutBucketLifecycleConfiguration permission
  4. Test cleanup (requires permissions) 
    "Delete the test bucket"
    This requires s3:DeleteBucket permission

​
Common Permission Errors

AccessDenied: The AI agent doesn’t have permission for the requested modification action - Solution: Add the missing permission to your policy - Note: This only happens when trying to create/update/delete resources
InvalidUserID.NotFound: The AI agent can’t assume the role - Solution: Check your trust policy configuration
UnauthorizedOperation: Specific action is blocked - Solution: Review resource-level restrictions in your policy

​
Best Practices

​
Security Best Practices

  1. Start with least privilege
    • Begin with minimal permissions
    • Add permissions as needed
  2. Use resource restrictions
    • Limit access to specific resource patterns
    • Use tags to control access
  3. Rotate credentials
    • For IAM users, rotate access keys regularly
    • For roles, monitor usage patterns

​
Getting Help

If you’re having permission issues:
  1. Check the error message - it usually indicates the missing permission
  2. Review AWS documentation for the service you’re trying to use
  3. Test with AWS CLI using the same credentials
  4. Use AWS Policy Simulator to test your policies

Still Need help ?

Contact our support team for assistance with complex permission scenarios hello@cloudlvl.com