AWS · Identity · Principal Security Engineering

AWS Principal Identity Track

A curated executive-grade learning path for deterministic AWS identity risk: cross-account trust, iam:PassRole privilege escalation, and role chaining.

Track Status Active

Principal LABs 3

Aegis Signal IDENTITY_DRIFT_DETECTED

Authority OPA

Overview

This track teaches how AWS identity configuration creates deterministic privilege paths without requiring malware, credential theft, or software exploitation.

Read-only Deterministic Shield-linked Aegis Runtime-linked Executive-ready

Curriculum Ladder

The AWS Principal Identity Track is designed as a progressive learning path. Learners should understand IAM concepts first, then policy evaluation, then advanced deterministic identity paths.

L1 — AWS IAM Basics Foundation: principals, policies, roles, and identity vocabulary. L2 — AWS IAM Policy Evaluation Intermediate: effective permissions, explicit deny, boundaries, SCPs, and decision reasoning.

L3 — AWS Principal Identity Track Principal: cross-account trust, iam:PassRole, and role chaining escalation paths.

L1: AWS IAM Basics
    ↓
L2: AWS IAM Policy Evaluation
    ↓
L3: AWS Principal Identity Track

Concept Deep Dives

These explanations help students, interns, mentors, and executives understand why the Principal track matters.

What is a Principal LAB?

A Principal LAB models advanced identity risk with deterministic evidence. It is not a toy example and it does not require live exploitation. It shows how real cloud authorization paths can create risk.

Why does identity create blast radius?

Identity controls define what can be done, by whom, and against which resources. When trust, role passing, or role chaining is over-permissive, the reachable blast radius expands.

What should a CISO take away?

Cloud identity risk should be explained as a decision path: principal, permission, trust, runtime signal, and governance boundary. The track provides evidence-backed language for that review.

How does L2 prepare learners for L3?

L2 teaches effective permission and explicit deny reasoning. L3 then applies that reasoning to cross-account escalation, PassRole paths, and chained role assumptions.

Audience Fit

Students / Interns

Learn AWS IAM attack-path reasoning through structured, visual, non-destructive labs.

Mentors / YouTube Teaching

Use the track as a guided lesson plan: concept, path, detection, runtime meaning, and governance boundary.

CSO / CISO / Executives

Demonstrate deterministic cloud security modeling, risk explanation, evidence discipline, and platform engineering maturity.

Security Engineers

Map IAM relationships into Shield findings and Aegis Runtime identity integrity signals without relying on guesswork.

Principal LABs

1. Cross-Account Role Escalation Trust policy reachability through sts:AssumeRole into a privileged account role. 2. iam:PassRole Privilege Escalation Binding a higher-privilege execution role to a compute service through PassRole. 3. Role Chaining Escalation Transitive privilege expansion through chained sts:AssumeRole paths.

Next Candidate Service-linked roles, federated identity drift, or permission boundary bypass modeling.

Platform Loop

Each Principal LAB follows the same evidence-driven platform loop:

LAB artifact
    →
Shield deterministic finding
    →
Aegis Runtime identity signal
    →
OPA authority boundary
    →
Evidence record
    →
Executive / student explanation

Evidence Records

Phase 13 Evidence PassRole Principal LAB locked with runtime and Intelligence Core evidence.

Phase 14 Evidence Cross-account Principal LAB parity and UI polish recorded.

Phase 15 Evidence Role chaining Principal LAB locked with deployed Shield endpoint verification.

Runtime Tests Aegis identity integrity tests passed with all Principal LAB mappings.

Governance Boundary

This track is read-only, deterministic, and designed for learning, platform demonstration, and executive security explanation.

Runtime = source of truth
OPA = decision authority
Aegis = bounded intelligence
Frontend = rendering only

Does not exploit AWS
Does not mutate customer infrastructure
Does not deploy live infrastructure
Does not execute remediation
Does not override OPA
Does not treat Aegis as enforcement authority