See repeated attempts as well as successful actions
An access refusal can be valuable security evidence. Wildo records authorization denials with the attempted operation, required authority and classified reason, while grouping repeated attempts into an escalating series.
Example — See repeated attempts, not just successful changes
A caller repeatedly requests records outside their scope. The trail preserves the refusal pattern and its growing count without creating a separate event for every guessed identifier.
For engineers
The authorization service observes refusals at its operation and subject gates. It records the operation identity, variant, required and held roles, attempted identifiers and denial reason. Internal application faults keep their own error handling.
A concealed record still produces useful evidence: the outward not-found response does not disclose whether the record exists, while the authorizer’s internal reason can identify a subject-resolution refusal.
Preserve the pattern without unbounded event volume
The source escalation rule is small because the behavior is precise:
Selected source from authorization-denial-audit.backend.utils.ts:
export function isDenialAuditEscalationMilestone(count: number): boolean {
if (!Number.isInteger(count) || count < 1) return false;
for (let rung = 1; rung <= count; rung *= 10) {
if (rung === count) return true;
}
return false;
}
Within the configured window, counts 1, 10, 100 and later powers of ten emit observations. The bucket includes the available user identity, resource, operation, variant and reason; it deliberately excludes the target record ID. Userless calls use a shared fallback bucket.
When the counter is unavailable, the event can still be emitted with an inexact count. The receiver should use the count’s precision flag instead of interpreting every observation as an exact total.
Keep prevention and observation separate
The authorization decision denies access. This volume policy neither rate-limits the caller nor replaces endpoint authorization. Application extensions must reach the normal authorization boundary; an internal service call with deliberately borrowed authority is not an ordinary customer request.