I didn't have time to write you a short answer, so I wrote you a long one - Often people feel the desire to have "attribute-level" validations because they don't have enough controllers. The 1:1 mapping of resource and controller is great early on but it is actively harmful if you have two different user roles doing different operations on an object through the same controller endpoint. Just because you are editing columns on the `invoices` table does not mean that you should do it through `invoices#update`. If only admins can backdate an invoice, do that through `invoices/backdate#create` and authorize there. It will be super clear and confident. - A whole class of authorization goes away if you scope things to the current tenant / user with `Current.account.invoices.find(params[:id])`. In a SaaS project it should be a huge yellow flag when you are querying models directly. You can take this a step further too: `Current.user.backdateable_invoices.find(id)` where non-admins get `Invoice.none` returned - I find gems like Pundit/ActivePolicy/CanCanCan etc to be a net negative: authorization code should be first and foremost extremely clear and explicit. DSLs and conventions that reduce character count obscure this and are surface area for nasty bugs. Again if you have more targeted controllers, it doesn't matter that you have some extra code to authorize. And less gems means less chance of getting blocked on a Rails upgrade, less external updates to manage, less bikeshedding over people wanting to use their pet favorite. - Favor UI patterns that make it hard for users to do things they don't have permission to do. If you can't backdate an invoice because of permissions, don't show the Backdate button. Or show it disabled with text explaining that you dont have permissions. Keep the backend checks, of course, but let it just blow up with a generic 500. Avoid showing every user the form and then doing inline form validation errors. If you look at 37s code, they have almost no validations. Rails inline form validations are very limited and frankly kind of suck to configure -- don't reach for a different form builder, just realize you probably shouldn't be using them that much. - For any complex permission schemes, you will want to implement "role-based access control" (RBAC is what you want to search for). User has_many :roles, Role has_many :permissions, Permission is what you check for authorizations. Making these database tables (even if you think it's overkill) is really nice in the future since eventually accounts will want custom roles and custom configurations of permissions. Again don't reach for gems for this. You will be glad that you have full control over the system when you need to migrate/deprecate/add strange behaviors/etc as your needs change. - One last note: how do you authorize when changes are made via an API or a third-party integration or a webhook? You don't know what `User` is actually doing it. So if you bake authorization checks deep into the model, you'll end up creating mess as you have to make fake user records or pass flags to skip checks. Another +1 for controllers as the primary point to authorize IMO