CP001
IAM Access Review
Identity, trust, permission, ownership, and access relationships.
Cloud & Digital Infrastructure
Cloud Infrastructure Assurance at the Level of Real Topology, State, and Evidence
Available for real client use. Validation and refinement continue as part of the normal product lifecycle.
stoiXDome investigates cloud environments as connected operational systems in which identities, trust, workloads, permissions, resources, runtime dependencies, topology, state history, and evidence must be understood together.
It carries a bounded engineering case from observed state through investigation and qualified change to an independently verified result, while preserving provider-native semantics across AWS, Azure, and GCP.
Operating model
Dome is not a set of unrelated scanners. Its strongest product object is a bounded Case that preserves evidence, uncertainty, reasoning, authority, action, and outcome together.
What Dome investigates
Identity, policy, role, permission, ownership, and trust analysis with relationship context rather than isolated configuration checks.
Execution paths, authentication, retries, timeouts, concurrency, secrets, logging, and workload dependencies.
Coverage, retention, correlation, provenance, and the ability to reconstruct a significant event.
Service accounts, workload identities, CI/CD roles, ownership, privileges, actual use, and dependency context.
Topology
Risk exists in relationships, not only in individual settings.
Dome connects identities, roles, workloads, resources, trust relationships, and cross-account or cross-provider dependencies into a topology.
This makes transitive privilege and hidden access paths visible and allows a finding to be evaluated in the context of what it can actually reach.
State through time
Configuration changes, trust changes, incidents, evidence acquisition, and remediation attempts become part of a single state history.
Dome can reason about what existed, what changed, when it changed, what evidence was available, and what happened after an action.
Unknown cause
Ambiguous cloud Cases are treated through competing hypotheses, evidence-gap identification, and bounded recommendations rather than premature certainty.
Missing evidence remains missing evidence. It is not silently converted into a confident conclusion.
Before change
A candidate change is evaluated together with dependency impact, constraints, rollback feasibility, freshness, and authority requirements.
The goal is not only to know that a condition is risky, but to understand what may break if the environment is changed and whether the intended change is qualified.
After change
Execution status is not treated as proof of success.
Execution ≠ Verified Outcome
After a change, Dome re-observes the environment and compares the resulting state with the required outcome.
Provider semantics
AWS, Azure, and GCP retain their provider-native semantics.
Rosetta and Universal Projection create a common analytical layer only where meaningful semantic correspondence exists.
Finished outputs
Professional lenses
CP001
Identity, trust, permission, ownership, and access relationships.
CP002
Runtime execution and dependency safety.
CP003
Evidence coverage and event reconstruction.
CP004
Non-human identities, ownership, privilege, and dependency context.
INV001
Evidence-driven root-cause investigation for ambiguous infrastructure problems.
Observed state → investigation → qualified decision → where authorized, governed action → independent outcome verification.
Discuss stoiXDome