How Static Analysis Generates Least-Privilege IAM Policies

Learning Outcomes

After studying this material, you should be able to:

1. Explain why least-privilege IAM policies matter and the limitations of current approaches
2. Describe how static analysis can be used to automatically generate IAM policies from application code
3. Understand the three-phase pipeline of IAM Policy Autopilot (IPA)
4. Compare IPA against alternative policy generation methods
5. Evaluate trade-offs between security, accuracy, and automation in IAM policy generation

---

Step-by-Step Study Material

Step 1: Foundation — What is IAM and Why Does It Matter?

What is IAM?

Identity and Access Management (IAM) is AWS's system for controlling who can do what on AWS resources.

IAM Policy Example:
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-bucket/*"
}

This policy says: "Allow reading and writing objects in my-bucket only."

The Principle of Least Privilege

Give applications only the permissions they need — nothing more.

Why is this hard?

• Modern applications call dozens of AWS APIs
• Each API call requires specific IAM permissions
• Tracking all of them manually is tedious and error-prone

---

Step 2: The Problem Space — Current Approaches and Their Flaws

There are three existing approaches, each with significant drawbacks:

Approach 1: AWS Managed Policies

AWS provides pre-built policies like AmazonS3FullAccess.

AmazonS3FullAccess grants:
- s3:GetObject ✓ (you need this)
- s3:PutObject ✓ (you need this)
- s3:DeleteBucket ✗ (you DON'T need this)
- s3:DeleteObject ✗ (you DON'T need this)
- ... 50+ more permissions you don't need

Problem: Designed for common scenarios, not your specific use case → overpermissive

Approach 2: Hand-Crafted Least-Privilege Policies

A security expert manually reads your code and writes precise policies.

Problem:

• Requires deep IAM expertise
• Time-consuming
• Error-prone at scale
• Doesn't update automatically when code changes

Approach 3: AI Coding Assistants

Ask an AI: "What IAM permissions does my code need?"

Problems:

• Hallucinations — invents permissions that don't exist
• Lag — doesn't know about newly launched AWS services/APIs
• Nondeterministic — gives different answers each time
• Organizations distrust AI for security-critical artifacts

The Gap IPA Fills

Hand-crafted          IPA fills          Managed
Least-Privilege  ←——  this gap  ——→     Policies
(too hard)                              (too broad)

---

Step 3: The Solution — IAM Policy Autopilot (IPA)

Core Concept

IPA is a deterministic static-analysis tool that:

• Reads your source code (without running it)
• Identifies AWS SDK calls your application makes
• Maps those calls to required IAM permissions
• Generates a precise policy with full traceability

Key Properties

Supported Languages

• Python
• Java
• Go
• TypeScript / JavaScript

---

Step 4: The Three-Phase Pipeline (Core Mechanism)

This is the heart of IPA. Think of it as an assembly line:

Source Code
    ↓
[Phase 1: Parse]
    ↓
SDK Calls Identified
    ↓
[Phase 2: Map]
    ↓
Required Permissions
    ↓
[Phase 3: Synthesize]
    ↓
IAM Policy Document

---

Phase 1: Parse — Finding AWS SDK Calls

Technique: Abstract Syntax Tree (AST) Pattern Matching

What is an AST? When code is parsed, it becomes a tree structure representing its grammar.

# Your Python code:
s3_client.get_object(Bucket='my-bucket', Key='file.txt')

AST representation:
Call
├── Attribute: get_object
│   └── Name: s3_client
└── Arguments:
    ├── Bucket = 'my-bucket'
    └── Key = 'file.txt'

IPA scans this tree looking for patterns that match AWS SDK calls.

What it identifies:

• Which AWS service is being called (e.g., S3, DynamoDB, Lambda)
• Which operation is being performed (e.g., get_object, put_item)
• Where in the code it appears (file, line number)

---

Phase 2: Map — SDK Operations → IAM Permissions

Not every SDK call maps 1:1 to an IAM permission. IPA consults authoritative AWS service metadata to get the correct mapping.

SDK Call              →    IAM Permission Required
─────────────────────────────────────────────────
s3.get_object()       →    s3:GetObject
dynamodb.put_item()   →    dynamodb:PutItem
lambda.invoke()       →    lambda:InvokeFunction

Why this matters:

• Some SDK calls require multiple IAM permissions
• Permission names don't always match SDK method names exactly
• New services/APIs are added regularly — IPA uses current metadata

---

Phase 3: Synthesize — Building the Policy Document

IPA assembles all discovered permissions into a valid IAM policy document.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "dynamodb:PutItem",
        "lambda:InvokeFunction"
      ],
      "Resource": "*",
      "_provenance": {
        "s3:GetObject": "app.py:line 42",
        "dynamodb:PutItem": "app.py:line 87",
        "lambda:InvokeFunction": "handler.py:line 15"
      }
    }
  ]
}

Key feature — Provenance: Every permission is traced back to its origin in source code.

"Why does this policy have dynamodb:PutItem?" "Because of line 87 in app.py."

This makes the policy auditable and explainable.

---

Step 5: Evaluation — How Well Does IPA Work?

The researchers tested IPA in two settings:

Evaluation Setting 1: Synthetic Benchmarks

• 10 benchmark applications across all 4 supported languages
• Compared against 4 alternatives:

Evaluation Setting 2: Real-World Application

• Production-style multi-service chatbot in Python
• IPA-generated policies sufficient for 11/12 handlers

Key Metrics

Permission Count Comparison:
─────────────────────────────────────────────────────
Managed Policies (optimal selection):    ~100 permissions
Expert Developer-authored:               ~X permissions  
IPA-generated:                           ~0.6X permissions
─────────────────────────────────────────────────────

IPA vs Managed Policies:  ~10x fewer permissions ✓
IPA vs Expert-authored:   ~40% fewer permissions ✓

Interpretation:

• IPA generates significantly tighter policies than managed policies
• IPA generates tighter policies even than expert developers
• IPA is a strong starting point — not always perfect (1/10 and 1/12 failures)

---

Step 6: Putting It All Together — Mental Model

┌─────────────────────────────────────────────────────┐
│                  YOUR APPLICATION CODE               │
│  Python / Java / Go / TypeScript                    │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────┐
│              PHASE 1: PARSE (AST)                   │
│  Find all AWS SDK calls in the code                 │
│  → s3.get_object(), dynamodb.put_item(), ...        │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────┐
│              PHASE 2: MAP                           │
│  SDK calls → IAM permissions                        │
│  Using authoritative AWS metadata                   │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────┐
│              PHASE 3: SYNTHESIZE                    │
│  Build IAM policy document                          │
│  With provenance (source code tracing)              │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────┐
│           GENERATED IAM POLICY                      │
│  ✓ Deterministic  ✓ Least-privilege                 │
│  ✓ Traceable      ✓ Up-to-date                     │
└─────────────────────────────────────────────────────┘

---

Step 7: Limitations to Understand

IPA is not perfect. Understanding its limitations is important:

---

Summary Table

---

Self-Check Questions

1. Why are AWS managed policies considered a security risk?
2. What does "deterministic" mean in the context of IPA, and why does it matter for security?
3. What is an AST and how does IPA use it?
4. What is "provenance" in an IAM policy and why is it valuable?
5. Why might IPA fail to detect some required permissions?
6. How does IPA compare to AI-generated policies in terms of reliability and accuracy?