Authorization

Set approvals.authorization.enabled to true — or the env variable, which also accepts 1, yes and on (false, 0, no and off switch it off, a blank value leaves it off; anything else throws InvalidConfigurationException) — to gate every decision path through a Gate ability:

APPROVALS_AUTHORIZATION=true

The package never defines the gate — your app does:

use Illuminate\Support\Facades\Gate;

Gate::define('decide-approval', fn ($user, $approvable) => $user->can('review', $approvable));

A denied gate throws UnauthorizedApprovalException before anything is recorded:

use RoundlyConsulting\Approvals\Exceptions\UnauthorizedApprovalException;
use RoundlyConsulting\Approvals\Facades\Approvals;

try {
    Approvals::for($deployment)->as($intern)->approve();
} catch (UnauthorizedApprovalException $e) {
    // the gate denied this actor — nothing was recorded
}

How the check runs

• It guards approve(), reject(), toggle(), ask() and cancel() — through the facade, the traits, the test helpers and the actions alike.
• The ability is checked with Gate::forUser() against the approvable, for the model that acts, so the actor doesn’t have to be the logged-in user. For ask() it is the asked actor.
• With delegation, the gate checks the acting delegate, not its delegator.
• The named-approver check on requests is separate and always on.

A custom ability name

// config/approvals.php
'authorization' => [
    'enabled' => env('APPROVALS_AUTHORIZATION', false),
    'ability' => 'review-deployment',
],

// App\Providers\AppServiceProvider::boot()
Gate::define('review-deployment', fn (User $user, Deployment $deployment) => $user->team_id === $deployment->team_id);

Not set (null or blank) means decide-approval; a non-string ability throws InvalidConfigurationException rather than checking a different gate.