True when what an action changes holds nothing beyond what the actor holds — the grant ceiling (MishkaCmsCore.Accounts.Validations.GrantWithinActorScope) asked of the account or the row an action changes, by the same covering rule (MishkaCmsCore.Accounts.Checks.AccessPermissions.beyond/2).

• An account (MishkaCmsCore.Accounts.User): every permission it holds, when the action deletes it or changes its email, its password, its authenticator or its site — what signing in as it takes, and where it belongs. A generic action names the account by its :id argument, and deletes it when it is given nothing else. Changing only what the account holds is a grant, held to the grant ceiling instead; anything else asks nothing.
• A catalogue row (MishkaCmsCore.Accounts.Permission): the name a destroy removes, and both names of a rename, which every holder of the row loses and gains. A create names what nobody holds yet, and an update that keeps the name changes no name.
• A grant row (MishkaCmsCore.Accounts.UserPermission) written directly: the permission it grants. Removing one grants nothing, as remove_permission does not.

False for no actor. It only ever narrows a gate: put it beside the checks that authorize, since a policy passing on it alone would authorize whatever no other policy asks about.

policy action(:tenant_update) do
  forbid_unless {MishkaCmsCore.Accounts.Checks.AccessPermissions, permissions: ["admin:dashboard:user", "admin:api:user"]}
  forbid_unless MishkaCmsCore.Accounts.Checks.WithinCeiling
  authorize_if expr(site_id == ^actor(:site_id))
end