Soft delete adds a trash page and a restore button. Do they get the same permission checks as the rest of your API?

Most apps I've worked on move to soft delete at some point. A deleted_at column goes on the table, the default scope hides those rows, and a sprint later someone adds a Trash page with a restore button. That last step is where I keep finding authorization gaps.

The first one is the tenant filter. The normal read path goes through a scope that filters by tenant and hides deleted rows. The trash page needs the deleted rows, so someone reaches for Document.unscoped (or whatever your ORM calls it). In Rails, unscoped drops every default scope, so if the tenant filter lived in the same default_scope as deleted_at IS NULL, it's gone too. The trash list now shows deleted documents from every tenant, and nobody notices because in dev there's only one.

The second one is restore. It usually gets a role check like "editors can restore", which says nothing about whether this editor could ever see this document. Per-record checks are awkward here, because the sharing or folder lookups often skip deleted rows, so the check fails and someone removes it to make restore work.

What I do now:

• Keep the tenant filter apart from the soft-delete filter, so dropping one can't drop the other. If you use Postgres row-level security, the tenant policy shouldn't mention deleted_at at all.
• Keep the owner, folder and shares on the row when it's soft deleted, and run the same per-record check for viewing trash and for restore that you run for edit.
• Add the trash and restore endpoints to the test that walks every route as a user from another tenant and expects a 404.

How do you handle it? Is restore its own permission in your model, or does it ride on delete?