A risky sign-in gets a harder path. A non-compliant device lands in quarantine. A change approval gate consumes verified conditions instead of a stale spreadsheet. Panaptico observes live provider state through read-only credentials, verifies it against declared conditions, and supplies the answer your routing trusts — with evidence behind every result. Enforcement stays in your tools.
Change at the gate
Require compliant device for all cloud apps
Entra ID conditional access change — held at the approval gate until its required conditions verify.
Required condition · declared
Every identity in scope presents an MDM-enrolled device. Unknown counts as not met — never as a pass.
Current state · verified
340 identities on unenrolled BYOD mobile observed across the evaluated population. Evidence 14m fresh.
Gate decision
HELD340 identities diverge from the required condition
The gate stays closed until the population enrolls or the declared scope changes. Enforced in Entra ID — evidenced here, end to end.
340
Identities in scope
~4,200
Daily sessions on affected paths
0
Service identities in scope
All cloud apps
Evaluated scope
Named blast radius
What gets evaluated
Not a sandbox. Not a mock environment. Panaptico observes current state through read-only credentials and evaluates each class of change against what actually exists — users, groups, policies, roles, rules, and the effective paths of the dependency graph.
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
Observe with read-only scope
Connect providers with read-only credentials. Panaptico observes current state — identities, devices, policies, roles, rules — and never writes. Providers stay authoritative; enforcement stays in your tools.
Okta read-only admin, AWS SecurityAudit policy, Cloudflare API token (read), Entra ID directory readers
Declare the conditions that route
State what a decision requires: the scope it covers, the condition that must hold, how fresh the evidence must be. Each declaration is a verification contract with a definition version and history.
"No unenrolled device reaches cloud apps" · "The change gate opens only when the affected population verifies clean"
Route on the verified answer
Sign-in policies, quarantine workflows, and approval gates consume the same verified result — with the evidence attached. Unknown never passes, and every decision traces back to the conditions behind it.
Pass / Fail / Unknown results, each with evidence, freshness, and history from live provider state
Two modes of verification
You declare the conditions your decisions depend on — and the dependency graph exposes the gaps you didn't declare. Both resolve to the same thing: a verified result with evidence attached.
You declare
State the condition once. Panaptico evaluates it against live provider state on every refresh — current value vs declared target, field by field.
"No unenrolled device reaches the data warehouse."
"Every admin role carries WebAuthn — no exceptions, no stale evidence."
"The CI/CD service account holds exactly the permissions on its declared list."
The graph surfaces
The dependency graph exposes divergence no declaration covered — with the same evidence, freshness, and named scope as anything you declared.
340 BYOD identities reach cloud apps outside the compliant-device population — undeclared, now named
Service account sa-etl-prod inherits the policy through group nesting — an effective path no declaration covered
WAF custom rule is shadowed by the managed ruleset — evaluated after it, the custom rule never fires
Anatomy of a finding
Every finding is structured: the scope it evaluated, the condition it checked, the evidence behind the result, how fresh that evidence is, and the history of the field. Not a wall of text — an answer that humans, workflows, gates, and agents consume alike.
Declared condition: every identity reaching cloud apps presents an MDM-enrolled device. Observed in live provider state: 340 identities on unenrolled BYOD mobile (iOS + Android). Current state diverges from the declared target — evidence 14 minutes fresh.
340
Identities in scope
~4,200
Daily sessions on affected paths
0
Service identities in scope
All cloud apps
Evaluated scope
Named blast radius
Routing
Change approval gate holds. Divergence lands in a named scope — 340 identities, 3 groups, 14 app paths. Enforcement stays in Entra ID; the decision traces to this condition, this evidence, this history.
Strongest for
01
Step-up keys off verified conditions — device posture, network zone, identity risk — evaluated against live provider state, not a spreadsheet exported last quarter.
02
The quarantine workflow consumes the verified field — encryption on, EDR healthy, OS at target — and the evidence rides along. Your MDM enforces; Panaptico verifies.
03
The approval gate opens on conditions that hold and holds on conditions that don't. Unknown is a first-class result — a gate never opens on silence.
04
Expected vs evaluated populations on every decision. The approver sees 312 of 340 identities verified clean — and the 28 that are Unknown, named field by field.
05
Six months later, “why did this change go through?” resolves in one query — the conditions, the evidence, the freshness, and the history behind the decision.
Every access decision, quarantine, and approval is only as strong as its inputs. Panaptico supplies the verified answer — evidence attached — and your existing tools enforce it.
See System Readiness·See Design Studio·Related: Change Impact Analysis