The single most common feature request we deflect is "can you log in and check the admin panel?" The answer is no — by design, not by limitation. Here's the full rationale, what we do instead, and which tool to use if you genuinely need behind-auth monitoring.
The short version. Holding customer admin credentials would invert our trust model, make Cipherwake a target whose breach hands attackers admin access to every paying customer at once, and add a class of operational complexity (OAuth flows, MFA, CSRF rotation, session expiry) we're not equipped to maintain reliably. The catastrophic events that customers want caught — "did /admin become public" — are detectable from outside without credentials via route assertions. The full case is below.
To crawl your authenticated surface, Cipherwake needs one of:
Whatever the form, we'd be holding the keys to every paying customer's admin panel. The pitch we sell is "we watch your public trust surface and tell you when it drifts" — meaning we look at what the outside world sees. The moment we store credentials, we ARE part of the attack surface. A breach of Cipherwake hands attackers admin access to every customer at once. That's the same liability shape as a password manager — and a password manager's entire business model is dedicated to managing that risk. We'd be carrying it as a side effect of a deploy-gating product.
The security-conscious engineer who would pay $19.99/mo for Cipherwake is exactly the person who will refuse to hand us their admin cookie. Wrong-buyer rejection.
What an authenticated-crawler would need to handle per customer:
Every one of these is a per-customer integration nightmare. The crawler breaks on Wednesday because a customer rotated their OAuth consent screen, or enabled MFA, or shortened their session timeout. The on-call burden (us) eats the support cost. Our error rate destroys the "is it actually monitoring" trust that justifies the bill.
Pingdom and DataDog Synthetic handle this in dedicated teams with secret vaults. We're not. Building it badly is worse than not building it.
Admin UIs are where active product development happens. Adding a column to a table, renaming a button, reorganizing a menu, A/B testing a new layout — these aren't security regressions, they're routine product work. A visual trust-diff against a constantly-changing admin surface generates noise, not signal. The customer churns because the gate cries wolf on every product update.
The valuable events behind auth — "an admin export endpoint was added that shouldn't exist," "a new admin action allows mass data deletion without confirmation" — need real semantic understanding, not visual diffing. That's a different product (closer to Data Security Posture Management) than what we sell.
The high-severity event that customers actually fear is "did /admin become public on this deploy?" That's a status-code check from the outside. You don't need to log in to detect it — you need to probe the route without credentials and assert it's still gated.
That's exactly what route assertions do, with zero credential risk:
/api/admin/users/delete-all exists and is gated, the assertion catches it staying gated..cipherwake.json. Cipherwake never sees behind the auth boundary — it only verifies the boundary is still there.We never needed to be inside.
The moment we store admin credentials, the world changes:
Route assertions have ZERO of this. Just HTTP probes against routes the customer has told us about.
If you genuinely need synthetic checks behind auth — actually logging in and verifying authenticated pages render correctly — these are the right tools:
If a customer asks us "can you also monitor my admin panel content?", we route them to these tools honestly. Recommending the right tool when it's not ours is part of the brand.
Authenticated-surface monitoring is on the permanent "will not build" list. Not "maybe later" — never.
What we WILL keep investing in instead:
report-to endpoint that aggregates real-user browser-side blocked attempts. Continuous signal from production traffic without credentials.Every one of these stays on the right side of the credential boundary.
This decision was made explicitly on 2026-06-05 when a customer dogfooded Cipherwake against an admin-heavy app for ~10 deploys and observed that Cipherwake stayed silent (correctly — the public surface didn't drift). The natural next ask was "what if you logged in?" The response, on review, was "no — that's wrong for the entire category." Route assertions shipped instead.
If we're ever tempted to revisit this, three things must change: (a) a way to hold credentials that doesn't centralize them on Cipherwake's infrastructure (e.g. customer-supplied per-scan tokens that expire in minutes); (b) a credential-handling team and audit posture we don't currently have; (c) evidence that route assertions + the other roadmap items aren't enough. None of those are likely.