IAM controls your cloud. Who controls IAM?
One Whocan query. Every principal that can actually perform the action — evaluated through every policy layer, every condition, every role chain.
15-min deploy Read-only access No agents
All policy layers
SCP · RCP · boundary · identity · resource · condition
Deep condition keys
MFA · IP · VPC · tags · encryption context
Up-to-date catalog
New services update indexed same day
who-can() factors in SCPs, RCPs, identity policies, permission boundaries, resource policies and 50+ conditions — the answer your cloud would give.
§ 01 — The problem
Five documented public breaches. Each began as a permission that was already in place.
Recent breach ledger
↓ each had one Whocan query that would have surfaced the gap
Full admin access, backdoor user created, GPU instances launched for LLMjacking
Sysdig, 2025 02536 Redshift tables, 53 secrets in plaintext, 3.9M records, .gov email users including federal judges
BleepingComputer, March 2026 032,000 files (~100 GB) encrypted in 1 minute 47 seconds
Rhino Security Labs, 2025 04100M+ records: names, addresses, credit scores, SSNs
Capital One, 2019 0510,000% increase in serverless token abuse, 305% increase in bulk downloads
Palo Alto Unit 42, 20256
SCPs, RCPs, identity policies, permission boundaries, resource policies, and session conditions. The intersection is non-linear and no human can audit it manually.
∞
AWS releases new actions every week. Each one is a potential escalation vector your service:* policy silently matches. Benchmarks catch up weeks later.
0
Shadow admins, cross-env leaks, open trust policies, and privilege-escalation chains accumulate silently. Alerts push noise — nobody ever gets to pull the truth.
§ 02 — How it works
Whocan returns the same authorization answer your cloud would — not a rule-pack approximation.
/ 01
Entitlements
Every permission a principal could exploit — assume-role chains, pass-role paths, escalation sequences, multi-hop cross-account access — laid out as a browsable graph, kept current with new attack patterns. The terrain of risk, ready before you ask.
users where self.Entitlements.Abilities includes "iam-admin"
/ 02
Data perimeter
Validates resource policies, cross-account trust, and condition gaps against your intended perimeter — continuously, not on the quarter.
who-can( action: "s3:GetObject" resource: prod-buckets )
/ 03
Who can?
The map shows what could go wrong. Whocan proves what would. Given an action, a resource, and the context you supply, which principals actually can — factored through every policy layer and every condition, deterministically, not heuristically.
who-can( action: "kms:Decrypt" resource: var:prod-kms )
/ 04
Full decision chain
SCPs at every OU level. RCPs. Permission boundaries. Resource policies. 50+ condition keys — MFA, IP, VPC, tags, time, encryption context. When Whocan says allowed, AWS agrees.
env: {
"aws:mfa": "true"
"aws:vpce": "vpce-abc"
}the promise
When Whocan says allowed, AWS agrees.
§ 03 — Watch the critical
Most tools scan all your assets and drown you in findings. Whocan inverts it: pick the assets that matter, and watch the paths to them.
/ 01 · One query
One watch who-can(...) around your critical server. That’s the whole setup. No rule packs, no asset inventory project, no severity triage backlog.
/ 02 · The graph, diffed
Policy edits, new roles, new cloud services — drift never stops. Daily, or triggered by your CI’s webhook on any change, the graph around your asset is recomputed and diffed against the last run.
/ 03 · Only new paths surface
Known, reviewed paths stay quiet. When a new path to your critical asset shows up — even an indirect one, three hops through a Lambda someone can rewrite and invoke — it surfaces with the full chain that allows it.
§ 04 — Inside the product
Four screens from the app. Each answers a question a human would actually ask. Click any card to open it full-size.
§ 05 — Impact
Cut access review time, reduce cost, and reveal invisible risks.
Traditional Access Review
With Whocan
§ 06 — Where Whocan fits
Most teams already run a posture tool. Whocan answers a different kind of question — the one a human would actually ask.
Conventional posture tools
Whocan
Capability matrix
conventional posture tools vs. Whocan
We’re not trying to win a feature checklist. These are the gaps our customers tell us they felt with whatever they had — and why they keep Whocan alongside it.
Integrations
API-first design, CI/CD integration, and multi-cloud support. Whocan meets you where you are.
Programmatic access with API tokens. Run queries, retrieve results, and automate security workflows.
Trigger Whocan project updates from your CI/CD pipeline on every infrastructure change.
AWS today — Azure and GCP on the roadmap. One IAM model across cloud providers.
Enterprise single sign-on with SAML or OIDC. Integrate with your identity provider.
Webhook-triggered updates
# GitHub Actions — trigger Whocan update after Terraform apply
- name: Update Whocan
run: |
curl -X POST https://api.whocan.cloud/v1/projects/${{ secrets.PROJECT_ID }}/update \
-H "Authorization: Bearer ${{ secrets.WHOCAN_TOKEN }}"Pre-built compliance queries
§ — Pricing
We’re in private beta, onboarding design partners 1:1. Join the waiting list and we’ll find the right plan together.
Startups & small teams
High-security & regulated teams
Single-account, self-serve