§ — A different question, not a better tool

They push alerts.
We answer questions.

Graph-based CNAPPs and native tools ingest your cloud, evaluate it against a catalog of rules, and push findings into a queue. We invert that. Authorization questions are answered with your parameters, against your definition of relevance.

See the scenarios →Jump to the matrix
The existing modelpush · catalog-driven

Ingest the cloud. Run ~1000 rules. Push findings.

Graph-based CNAPPs. The graph is built once on a cadence. Every rule match becomes a finding. You spend the rest of the week triaging 800 to find the 12.

scan→graph→rules→findings
Our modelpull · query-driven

Compute the answer. On demand. With your parameters.

Ask who-can — you get the authorization answer with the conditions you pin, scoped to what you actually asked about. Zero findings until you ask.

question→Whocan→full eval→answer

§ — The honest matrix

Category-level capabilities, not feature nitpicks. Read each row as an architectural question the tool can or cannot answer.

What each tool
is built to answer.

Architecture
Answers reflect your inputs, not a fixed rule set
You provide the parameters; the engine returns the principals that satisfy them.
Whocan✓
Graph-based CNAPPs—
Native Access Analyzer◐
All policy layers (Org · identity · boundary · resource · condition)
Not "most layers". Every layer, every path, every chain.
Whocan✓
Graph-based CNAPPs◐
Native Access Analyzer◐
Condition keys as evaluable parameters (env:)
Ask "what if MFA is absent?" — get an exact list, not a label.
Whocan✓
Graph-based CNAPPs—
Native Access Analyzer—
Hypothetical principals (Virtual Roles, pre-deploy)
Evaluate a role that does not exist yet. No deploy, no wait.
Whocan✓
Graph-based CNAPPs—
Native Access Analyzer—
Operating model
Pull — you ask, it answers
The default is silence. Precision beats volume.
Whocan✓
Graph-based CNAPPs—
Native Access Analyzer◐
Push — rule catalog generates findings
The flood everyone triages.
Whocan—
Graph-based CNAPPs✓
Native Access Analyzer◐
Query language as primitive (not filters on a dashboard)
The query surface expresses the invariant you actually care about.
Whocan✓
Graph-based CNAPPs—
Native Access Analyzer—
Save any query as a continuous invariant monitor
Alert only when the answer to YOUR question changes.
Whocan✓
Graph-based CNAPPs◐
Native Access Analyzer—
Data-plane access control
S3 object-tag isolation — exact answer
Competitors return "conditional access". We return the list.
Whocan✓
Graph-based CNAPPs◐
Native Access Analyzer—
DynamoDB row-level isolation
Multi-tenant isolation proof. Structural blind spot elsewhere.
Whocan✓
Graph-based CNAPPs—
Native Access Analyzer—
Per-tenant KMS decryption boundaries
Per-tenant decryption reach.
Whocan✓
Graph-based CNAPPs◐
Native Access Analyzer—
Perimeter & segmentation
Cross-env / cross-account isolation — proven, not inferred
Empty result = proof a dev principal cannot reach prod. Graphs infer a path exists; they do not prove the negative under conditions.
Whocan✓
Graph-based CNAPPs◐
Native Access Analyzer—
App-to-app segmentation by tag or account
Define each workload as a set; ask whether one can reach the other. One query.
Whocan✓
Graph-based CNAPPs◐
Native Access Analyzer—
Identity · resource · network perimeter, verified end to end
Each AWS data-perimeter boundary becomes a query whose empty result is the proof.
Whocan✓
Graph-based CNAPPs—
Native Access Analyzer—
Coverage cadence
New AWS IAM actions reflected within a day (Pro)
They wait for research teams. We read the catalog.
Whocan✓
Graph-based CNAPPs—
Native Access Analyzer◐
Reflects the environment as you ask, not as last scanned
Incident response does not care about 6-hour-old graphs.
Whocan✓
Graph-based CNAPPs—
Native Access Analyzer◐
✓ Supported ◐ Partial — Not supported

§ — Same question, three answers

Each scenario is a real question from a real role. Click through the tabs to see how each tool responds.

Ask the question.
Watch what they return.

Breach forensics/The pattern behind recent Fortune-500 secret leaks

“A React app on ECS is compromised. Its task role has secretsmanager:GetSecretValue account-wide. Which principals — including this one — can read our production secrets?”

The Whocan query
who-can(
  action: "secretsmanager:GetSecretValue"
  resource: secrets
)
Whocan412 ms
Exact list

Every principal that can read every secret, resolved through all 6 layers including the ECS task role's silent account-wide grant. The frontend role appears flagged. Fix one step to break the chain.

Result
  • arn:aws:iam::prod:role/ecs-task-frontendunexpected
  • arn:aws:iam::prod:role/secret-rotator
  • arn:aws:iam::prod:role/platform-admin
  • arn:aws:iam::prod:role/lambda-payments-read
  • arn:aws:iam::prod:user/break-glass-01
Graph-based CNAPPs—
Findings, not an answer

Graph-based platforms surface this as a "toxic combination" — if the rule fires. No single query returns the list. You open the bucket of secrets, traverse the graph per resource, and reconcile across rules scored by severity.

What you get instead
High — Exposed workload with broad secrets access1 of 847 open findings
Med — Secrets access via wildcard policyrule IAM-0042
Med — Attack path: workload → secretsseverity score: 9.1
Low — Container without egress policysuppressed x3
Native Access Analyzer—
Resource-policy only

Access Analyzer scans resource policies for external access. It does not enumerate principals that can reach a secret via identity policies, role chains, or conditions. Miss.

What you get instead
No external access foundanalyzer scope: account

§ — One sentence

Everyone in cloud security is solving the same problem. We’re the only ones starting from the question instead of the alert.

Back to product →