AI-Assisted AuthZ Review: Reading Permission Boundaries in Ory Kratos
AI is bad at finding bugs but great at generating suspicion.
In security, the cheapest thing an AI can do is create a flood of false reports. This is why bug bounty programs are pausing or tightening rules.
I use AI differently. I let the AI over-generate hypotheses based on my AuthZ Smell Catalog. Then, I do the hard work. My job is to kill those hypotheses.
A successful review is not a list of bugs. It is a kill table of ideas that failed the test.
I reviewed the Ory Kratos source code. Kratos handles identity and user management. It is a high-risk area because it uses multiple identities and public APIs.
I tested five hypotheses:
- H1: Admin API has no authorization in code.
- H2: Cross-identity or cross-tenant data leaks.
- H3: Token reuse in recovery flows.
- H4: Identity confusion in settings flows.
- H5: Tenant assignment via request payloads.
The results:
- H1: KILLED. Authorization lives at the network boundary, not the code handler. This is by design.
- H2: KILLED. A central data-access layer filters all queries by tenant ID. Users cannot bypass this.
- H3: KILLED. Tokens are single-use and time-boxed.
- H4: KILLED. Flows are bound to the session, not user input.
- H5: KILLED. Tenant IDs come from the system context, not the request body.
Five hypotheses went in. Zero findings came out. This is a successful review.
Two lessons for your security work:
Deployment-layer security looks like missing security. If a guard lives at the network level, the code will look naked. Do not report it until you check the architecture.
Find the chokepoint. If a system enforces boundaries at the data layer, individual handlers do not need checks. Instead of asking "does this handler check permissions," ask "can anyone reach the data without the chokepoint?"
Use AI to reject candidates. Use humans to verify the survivors. The value is in the rejection.
Optional learning community: https://t.me/GyaanSetuAi