Not a sandbox. Not a mock. Panaptico reads your live IAM policies, identity configs, network rules, and RBAC grants through read-only credentials — then simulates the proposed change and tells you exactly who and what would be affected before you ship.
Proposed change
Require compliant device for all cloud apps
Entra ID conditional access policy — applies to 14 cloud applications, all user groups.
Current state
Device compliance required for desktop only. Mobile excluded. BYOD allowed without MDM.
Proposed state
Device compliance required for all platforms including mobile. No BYOD exemption.
Impact analysis
FAIL340 mobile users will be blocked
BYOD users on iOS and Android are not MDM-enrolled. Policy applies at next session refresh — no grace period.
340
Affected users
~4,200
Blocked requests / day
0
Service accounts impacted
All cloud apps
Policy scope
Affected groups
What gets validated
Not a sandbox. Not a mock environment. SA reads current state through read-only credentials and simulates the proposed change against what actually exists — users, groups, policies, roles, rules.
Identity & Auth
Okta, Entra ID, PingOne
IAM Policy
AWS IAM, GCP IAM, Azure RBAC
Network Policy
Cloudflare WAF, Gateway, Zscaler, Palo Alto
RBAC & Schema
Snowflake, PostgreSQL, Databricks
How it works
Bind read-only credentials
Connect your systems through Key Management with read-only vault scope. SA never writes to production — it reads current state to build the simulation baseline.
Okta read-only admin, AWS SecurityAudit policy, Cloudflare API token (read), Snowflake ACCOUNTADMIN with no DDL
Design your change in Studio Chat
Describe the change in natural language or paste the config diff. SA parses the intent, maps it to your live environment, and proposes pre-flight checks automatically.
"Require compliant device for all cloud apps" or paste the Entra CA policy JSON — SA handles both
Get a rich impact report
Not a text dump. A structured finding with verdict, affected user counts, blocked request estimates, named actor lists, and a concrete recommendation.
Pass / Fail / Inconclusive verdicts, each with evidence from your real config
Two modes of validation
You can ask natural-language questions about any proposed change. But SA also proactively surfaces risks you didn't think to check — because it sees the full dependency graph.
You ask
Type a question, get a grounded answer backed by your real config.
"Will this WAF rule block our mobile app's API calls?"
"If I remove the VPN exemption, who loses access to the data warehouse?"
"Does tightening this IAM policy break the CI/CD service account?"
SA flags
SA sees your full environment graph. It flags risks you didn't think to ask about.
340 BYOD users will be denied at next session refresh — no grace period configured
Service account sa-etl-prod inherits this policy through group nesting — pipeline will break
WAF rule overlaps with existing managed ruleset — Cloudflare evaluates managed rules first, custom rule is dead code
Anatomy of a finding
Every finding is structured: a clear verdict, quantified impact, named actors who would be affected, and a concrete recommendation. Not a wall of text — a decision you can act on immediately.
Proposed policy requires "compliant device" for all cloud apps. 340 users on BYOD mobile (iOS + Android) are not MDM-enrolled and will be denied at next session refresh.
340
Affected users
~4,200
Blocked requests / day
0
Service accounts impacted
All cloud apps
Policy scope
Affected actors
Recommendation
Exclude mobile platforms from device compliance requirement, or enroll BYOD fleet in MAM-only policy before enabling. SA can generate the phased rollout plan.
Strongest for
01
Moving from ADFS to Entra ID, or consolidating Okta orgs. Pre-flight every conditional access policy against the user population before cutover day.
02
Tightening AWS IAM permission boundaries or GCP service account roles. Know exactly which pipelines, Lambda functions, and cross-account trusts break before you apply.
03
Adding Cloudflare WAF rules, Gateway policies, or firewall changes. Pre-flight against real traffic patterns — not a staging environment that sees 0.1% of production load.
04
Enforcing device compliance, geo-fencing, or risk-based step-up. See the exact user groups affected, the session counts impacted, and the edge cases that would generate support tickets.
05
Restructuring Snowflake roles, tightening database grants, or changing row-level security policies. Know which dashboards, ETL jobs, and service accounts lose access.
Every policy change is a bet on who and what it affects. Pre-flight turns that bet into evidence — grounded in your real environment, not a sandbox.
See Pre-Flight·See Design Studio·Related: Change Impact Analysis