Authorization logic placed in wrong layer

How to fix

1. Move authorization to the request guard, policy service, or application service boundary.
2. Keep persistence methods free of caller-role decisions.
3. Retain UI gating only as presentation feedback, not enforcement.

What the rule validates

Authorization decisions appear in persistence, presentation, or miscellaneous helper code instead of the expected boundary.

Why it matters

Authorization should be visible and reusable at stable request or service boundaries.

Common causes

• Role checks were embedded in repositories.
• UI-only checks were treated as server authorization.
• Authorization branches were added inside generic utilities.

Typical violation example

A repository checks whether the current user is an admin before returning rows.

Typical compliant example

The route/service checks admin access, then calls a repository with scoped inputs.

Related rules

Adjacent categories

Related files/config

• apps/api/src
• apps/web/app/api
• packages/db/prisma/schema.prisma

Related CLI commands

• archpilot validate
• archpilot validate --ci