Change Impact Analysis

The blast radius is invisible
until something breaks.

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

Simple changes.
Hidden blast radius.

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.

CIA-0012
AWS IAM
3 hidden actors

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

Sourced fromCloudTrail · 90-day API call history
CIA-0019
Snowflake + Okta
3 hidden actors

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

Sourced fromSnowflake ACCOUNT_USAGE · LOGIN_HISTORY · GRANTS_TO_USERS
CIA-0027
Cloudflare Zero Trust
3 hidden actors

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

Sourced fromCloudflare API · Gateway policies · Device posture rules

The gap

The data exists.
It's not in the room.

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.

1

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.

2

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.

3

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

Queryable. Accessible.
Just never queried.

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

Pre-Flight reads your environment
before you change 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.

PRE-FLIGHTIAM scope-down · prod data lake role
Scanning live config

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.

Connected
AWS CloudTrail
IAM Access Analyzer
Snowflake
Cloudflare
Okta
Read-only credentials

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.

Stop finding out in production.

Connect your environment. Describe the change. See exactly what it touches — before you ship it and before anything breaks.