System 02 — identity

IAMGuru

IAM risk is not a list of bad policies. It is reachability: who can become administrator, through which chain, and how much breaks if they do. IAMGuru answers that question across AWS and GCP — including the AWS role that can quietly mint a GCP identity.

Role design + build, end to end Surface AWS (multi-account) + GCP (org) Core attack-path engine Run cost ~$8 / month

The problem

Most IAM tooling lists misconfigurations: a wildcard here, an old key there. That tells you what is untidy, not what is dangerous. Danger is a path — a benign-looking role that can pass a role, that can create a key, that ends at administrator — and paths cross account and cloud boundaries where checklist tools stop looking. The good commercial options that do model this are priced for large security budgets.

What I built

A platform built end to end: collectors, an analysis engine, a data-driven scoring layer, and a dashboard.

Collection — every AWS account in the organisation, reached through an assume-role chain; every service account across the GCP organisation.
Analysis — trust-policy parsing (external principals, wildcard conditions, root and federated trust), privilege-escalation path detection, blast radius per principal, and the binding analysis that maps which AWS roles can assume GCP identities through Workload Identity Federation.
Scoring as data — risk rules and thresholds live in the database, evaluated at scan time. The security team retunes severity without a code change or a deploy.
Dashboard — findings mapped to MITRE ATT&CK, scan history, run-to-run diffs, all behind private access.

  ┌────────────────────────────────┐     ┌────────────────────────────────────┐
  │ AWS  every account via         │     │ trust-policy parsing               │
  │      assume-role chain         │     │ priv-esc path detection            │
  │ GCP  org-wide service          │     │ blast radius per principal         │
  │      accounts                  │     │ AWS→GCP federation bindings        │
  └────────────────────────────────┘     │ MITRE ATT&CK mapping               │
                                         └────────────────────────────────────┘
                                         ┌────────────────────────────────────┐
                                         │ scoring (rules as data)            │
                                         │ thresholds tuned by the team       │
                                         │ without a deploy                   │
                                         └────────────────────────────────────┘

  dashboard · history · diffs · private access · ~$8 / month

iamguru — reachability across two clouds

Design decisions

Paths, not a checklist

IAM is modelled as a graph and the question asked of it is reachability: from this principal, what can it become, and through what steps. A linter finds untidy policies; a path engine finds the route to admin.

Trade-off meaningfully more engineering than a rules linter, and enumeration has to be careful — a missed edge is a missed path.

Cross-cloud trust is the real exposure

Single-cloud tools cannot see that an AWS role is one AssumeRoleWithWebIdentity away from a privileged GCP service account. The federation bindings are exactly where two well-governed clouds become one badly-governed trust boundary.

Trade-off two cloud identity models to understand and keep in sync; the payoff is the view almost nothing else gives you.

Risk scoring is configuration, not code

Severity rules are data the security team owns. They tighten or relax a threshold and the next scan reflects it. The tool does not gatekeep its own definition of risk behind an engineer.

Trade-off you build and validate a small rule-evaluation engine instead of hard-coding; worth it the first time a threshold needs to move at 5pm.

It runs for about eight dollars a month

A single small task on spot capacity with cheap, durable persistence. Cost is a design input, not an afterthought — a security tool nobody can justify keeping on is not a security tool.

Trade-off you accept occasional interruption and design the run to resume cleanly, in exchange for a price that never gets questioned.

Operating profile

Audits run on a schedule, each one diffed against the last so the question becomes "what changed and who changed it," not "read this whole report again." Access is private only — an IAM map is itself sensitive.

What I would change

For a much larger organisation the graph belongs in a store built for graph queries rather than computed per run. And the path explanations, while correct, could be more legible to someone who is not the person who built the engine — an attack path is only useful if the on-call reader believes it.