Change Impact Analysis
Every configuration change looks simple in plain English. “Tighten S3 access.” “Move to SSO.” “Add Browser Isolation.” The blast radius is encoded in live system state that nobody queries until production is on fire. Panaptico reads your actual environment before you ship — so you find out what breaks before anyone else does.
The pattern
Every one of these changes passed design review. Every one of them would have caused a production incident. The information to prevent it already existed — in CloudTrail, in ACCOUNT_USAGE, in the Cloudflare API. Nobody queried it because nobody knew to ask.
The change
Scope down IAM policy on prod data lake role
Remove s3:* and replace with explicit Get/Put on three buckets.
What Pre-Flight found
Glue ETL job data-lake-daily-transform
Calls s3:ListBucket on staging prefix — breaks silently, backfills stop
Cross-account SageMaker role in ml-prod (account 4471)
Assumes this role for training data read — AssumeRole chain fails at hour 3 of a 6-hour job
Contractor key AKIA…7F2X (last rotated 11 months ago)
Still active, used by a Terraform state backend nobody documented
The change
Migrate Snowflake auth from password to Okta SSO
Enable SAML, disable password auth, enforce SSO for all users.
What Pre-Flight found
SVC_ETL_PROD (ACCOUNTADMIN)
Service account with password auth — orchestrates nightly loads, no SSO-compatible identity
12 users with RSA key-pair authentication
Key-pair auth bypasses SAML but client config assumes password fallback — login flow breaks
3 orphaned accounts (last login >180 days)
Owned by departed employees, still referenced in FUTURE GRANTS — ownership chain breaks on disable
The change
Enable Cloudflare Browser Isolation for all Gateway policies
Flip isolation toggle on existing HTTP policies. All traffic gets sandboxed rendering.
What Pre-Flight found
Device posture rule: CrowdStrike sensor version >= 7.x
Isolation requires WARP client — 34 Linux dev machines have WARP but no CrowdStrike, posture check fails, all traffic blocked
Dev workflow: localhost tunnels via cloudflared
Isolated browser can't reach localhost — preview/debug cycle breaks for 60+ engineers
Adtech CDN rotation (ad.doubleclick.net, cdn.segment.com)
Isolation injects a service worker that conflicts with third-party analytics scripts — revenue attribution goes dark
The gap
The gap between “we designed it” and “we know what it'll touch” is where incidents live. The blast radius of every change is already encoded in queryable systems — CloudTrail logs, Snowflake ACCOUNT_USAGE views, Cloudflare API responses, Okta system logs, Entra ID audit trails. But that data never enters the planning conversation. It sits in a different console, behind a different login, queried by a different team — if anyone queries it at all.
Design happens in docs
The change is scoped in Confluence or a Slack thread. The language is plain English: “tighten access,” “enforce SSO,” “enable isolation.” No query runs. No config is checked.
Execution skips validation
The ticket moves to “In Progress.” Someone applies the change in a maintenance window. The only test is whether it deploys without error. Downstream consumers are invisible.
Production reveals the truth
The Glue job fails at 3 AM. The SageMaker pipeline times out. A contractor's Terraform run throws AccessDenied. You find out what the change touches by watching what breaks.
Where the data lives
Every system already exposes the data you need to predict impact. Panaptico knows which queries to run because it understands the change you're making.
AWS IAM
CloudTrail: GetObject, PutObject, AssumeRole calls against target policy ARNs in the last 90 days
IAM Access Analyzer: external access findings for the scoped-down resources
Config: resource relationships — who references this role, this bucket, this policy
Snowflake
ACCOUNT_USAGE.LOGIN_HISTORY: auth method breakdown per user over 90 days
ACCOUNT_USAGE.GRANTS_TO_USERS: ownership chains, FUTURE GRANTS, inherited privileges
ACCOUNT_USAGE.QUERY_HISTORY: service accounts with active query patterns against affected schemas
Cloudflare
Gateway API: active HTTP policies, isolation settings, device posture rule bindings
Devices API: enrolled clients by OS, WARP version, last seen — cross-referenced with posture rules
Tunnel API: cloudflared tunnel configs, ingress rules, DNS routes
Okta / Entra ID
System Log: authentication events by factor type — password vs SSO vs key-pair over 90 days
User API: lifecycle state, last login, group membership, app assignments
App API: SAML/OIDC config, provisioning status, assignment groups
How Panaptico solves it
When you design a change in Panaptico's Design Studio, Pre-Flight connects to your live systems with read-only credentials and runs targeted impact analysis. The output isn't a generic risk matrix — it's a list of specific affected actors, grounded in your actual configuration, with evidence you can trace back to the source query.
01
Connect
Read-only credentials to AWS, Snowflake, Cloudflare, Okta. No write access, no agents, no inline proxies.
02
Scope
Design Studio describes the change. Pre-Flight maps it to the specific resources, policies, and auth flows affected.
03
Query
Targeted API calls and log queries against live config. CloudTrail, ACCOUNT_USAGE, Gateway API — not sampling, not guessing.
04
Report
Rich findings with specific actors, risk severity, and remediation steps. Every finding traces back to the source query.
Not theory — your config
Pre-Flight doesn't guess based on best practices. It reads the actual IAM policies, the actual login history, the actual device posture rules in your environment.
Specific actors, not categories
You don't get 'service accounts may be affected.' You get 'SVC_ETL_PROD uses password auth, last query 4 hours ago, owns 12 schemas.'
Evidence, not assertions
Every finding links to the source query. CloudTrail event IDs, Snowflake query hashes, Cloudflare API response timestamps. Auditable and reproducible.
Connect your environment. Describe the change. See exactly what it touches — before you ship it and before anything breaks.