Second in a series on using AI to review authorization — not to spray reports.
Companion reference: — an open-source identity and What this review does and does not claim. In this limited, repo-only review, the I let cheap finders over-generate against the is the companion reference this series builds on.
user-management server (login, registration, recovery, verification, sessions, self-service
settings). Source-available, Apache-2.0.
Why Kratos: it is exactly the shape where authorization goes wrong — multiple identities,
a public API and an admin API, and (in Ory's hosted product) multi-tenancy. If a boundary
is fragile, this is where it shows.
Scope of this write-up: source reading only, on the public repository, single-tenant
OSS build. No hosted target was touched. Nothing here is an undisclosed finding — the point
is the method and the boundary design, and where relevant, how the design held against
the hypotheses I tested. This maps to the reproduction tiers we track: everything below is
repo_only, and I say so explicitly rather than implying it reaches a live product.
hypotheses I tested were killed. This is not a claim that Kratos has no vulnerabilities,
and it is not a security audit. It is a case study in how AI-assisted AuthZ review can
avoid false positives — how to kill a suspicion instead of shipping it.
3. What the AI suspected
SOCIAL SHARE CARD GENERATOR