Denylist
Audit governance for the deny-by-default mutation audit. Every mutating manager API call is audited unless a denylist entry excludes it. This page manages those entries and shows the discovered route/page universe with each row’s audit status, so the blast radius of every exclusion is visible. Routes in a protection class (credentials, MFA, identity, evidence, scanner trust, the denylist itself) can never be excluded.
Inputs
| Name | Description | Allowed values | Default |
|---|---|---|---|
pattern | Route glob the exclusion matches. Wildcards match whole path segments; ** only as the final segment. | e.g. /api/config/port-lists, /api/health/** | — |
method | HTTP method the entry applies to. All = every verb. | All, GET, POST, PUT, PATCH, DELETE | All |
stream | Which audit stream the exclusion mutes. | mutation, view, both | — |
reason | Required justification. Shown in the discovery view and meta-audited. | free text (non-empty) | — |
enabled | Disabled entries stay listed but mute nothing. | on/off | on |
Fields & columns
| Name | Description |
|---|---|
Status (universe) | Audited = mutations on this route are written to the audit trail. Excluded by <pattern> = a matching enabled entry mutes it. Protected = un-excludable core (a named protection class). |
Kind | route = a live API route; page = a GUI page from the docs manifest (view stream). |
Protection class | Generated classification (credential, mfa, identity-rbac, evidence, denylist, …). Protected routes reject matching denylist entries with 409. |
Created by | system (seed) rows ship with the platform; user rows record the operator who created them. |
How to
Exclude a noisy route
- Find the route in the Discovered universe table (filter by path)
- Click Exclude — the entry form opens pre-filled with the route’s path, method, and stream
- Enter a reason and save (step-up confirmation required)
Re-enable auditing for an excluded route
- Find the entry in the Denylist entries table
- Click Disable (keeps the entry + reason for history) or Delete (removes it)
- The universe table now shows the route as Audited again
Gotchas
- All denylist changes require step-up (sudo mode) and are themselves audited — the denylist cannot silence its own management.
- Protected routes (credentials, MFA, identity, evidence, scanner trust) reject exclusions with a 409 — by design, no pattern can mute them.
- A broad glob like /api/config/* mutes every matching mutation — check the universe view for what a pattern hits before saving.
- Disabling an entry preserves it for history; deleting it is meta-audited with the removed values.
- View-stream exclusions act on page ids (GUI paths) and API view routes separately — a page entry mutes the page-view row; the /api/... polling routes need their own pattern.
API calls (5)
| Method | Path | Description |
|---|---|---|
| GET | /api/admin/audit/denylist | List denylist entries |
| GET | /api/admin/audit/denylist/universe | Discovered route/page universe with audit status |
| POST | /api/admin/audit/denylist | Create an entry (step-up) |
| PUT | /api/admin/audit/denylist/:id | Update an entry (step-up) |
| DELETE | /api/admin/audit/denylist/:id | Delete an entry (step-up) |
Related
- Changes — The audit stream this denylist governs