Audit

When a request is allowed or denied at runtime, you need evidence you can trust — not a guess reconstructed from proxy logs. The Audit screen is Control’s evidence surface for exactly that: it shows the runtime decision events Control has ingested for your selected scope, with the TrustPlane authorization decision and the upstream result recorded separately.

For the runtime event schema behind this screen, see Audit (runtime capability).

Choose the evidence scope

The scope banner at the top states exactly which evidence you are looking at: all environments, one environment, one fleet, or one exact Auth Site — for example “Production · all fleets · all Auth Sites”. Audit reads require a resolved Control session and permission; if the requested scope cannot be applied, the screen shows a notice instead of events.

Filter and summarize decisions

The filter bar narrows the event list without changing the scope:

• Authorization outcome — any, Allowed, or Denied.
• Reason, Route ID, API ID, Protected surface ID, Subject — text matches.
• Upstream outcome — any, Not reached, Response received, or Transport error.
• Upstream HTTP status (100–599) and Upstream status class (2xx, 3xx, 4xx, 5xx).
• Search, a From/To time window, and a Results limit (1–200).

Clearing filters keeps your environment, fleet, and site scope.

Above the list, summary metrics report Total decisions, Allowed, Denied, and the Denial rate (denied divided by total decisions, shown only when the total is greater than zero). If Control does not return a summary or event list for the active scope, the screen says so explicitly rather than showing partial numbers.

Read the event list

The Runtime decision events table shows one row per recorded decision:

Column	What it shows
Occurred	The event timestamp
TrustPlane	The authorization outcome badge: Allowed or Denied
Reason	The normalized reason, or “Not recorded”
Identity	The recorded subject
Request route	Event ID, request ID when recorded, and the method and canonical path template
Surface / API	Protected surface IDs and API ID
Auth Site / target	Site ID and target name or ID
Upstream	The upstream result: an HTTP status, Not reached, Transport error, or Not recorded

Route cells degrade honestly: an event can show “Route not evaluated” or “route metadata unavailable” with just a route ID when full route metadata was not recorded. A target can show “Historical scope unresolved” when its historical scope could not be resolved. An upstream result of “Not recorded” means it was not recorded by that runtime version. When more events exist, a Next page link continues the list from a cursor.

Version skew, not data corruption

Older events may lack fields that newer adapter versions emit. When a historical event is missing a field — an upstream result of “Not recorded”, an absent request ID, no recorded check chain — that absence is version skew: the runtime version that produced the event did not emit the field. It is not evidence of data corruption or of tampering. Compare the event’s recorded bundle and target provenance (the Provenance tab) before concluding anything from a missing field.

Inspect a single event

Selecting an event opens a detail drawer with five tabs:

• Overview — an outcome banner showing the TrustPlane decision and the upstream result side by side, then the recorded result (event ID, request ID, occurred time, normalized reason, authorization outcome, upstream result, and upstream duration in milliseconds, marked when capped), the request and destination (canonical route, protected surface and API, Auth Site and target, recorded target ID), and the recorded decision fields projection when present.
• Decision — the authorization decision: outcome, normalized reason, enforcement layer, matched policy, matched grant, route, and protected surface and API. Below it, the recorded check chain lists each check supplied in the event with its recorded outcome (passed, failed, not run, skipped) and reason code. Only checks supplied in the event are shown; if none were recorded, the tab says so.
• Identity — subject, issuer, identity source, client ID, and key ID, plus the request: method, canonical path, route ID, API ID, protected surface IDs, and the body binding result.
• Provenance — bundle and target provenance that was explicitly recorded: bundle version, bundle digest, target ID, target configuration, scope resolution, key binding mode, and the Auth Site, fleet, and environment IDs. When the event carries explicit identity provenance, a projection of the recorded proof assurance, trust anchor, and enrollment fields appears.
• Raw — the sanitized evidence projection supplied by Control.

Deployment provenance: an image publication is not evidence

Publishing an adapter image alone is insufficient for its audit fields to appear — the Helm rollout must actually run that image before events carry the fields it emits. If you expect a newer field and do not see it, first confirm the rollout is running the intended image and check the event’s recorded bundle version and digest on the Provenance tab; do not treat the published image tag as proof of what produced an event.

Interpret an event

Read every event in the same order, so a conclusion always rests on the same fields:

1. TrustPlane decision — the Allowed/Denied badge. This is TrustPlane’s own authorization outcome, recorded separately from anything upstream did.
2. Normalized reason — the Reason field (or “Not recorded”). For a deny, this names the failure mode; the Decision tab’s recorded check chain shows which check produced it and its reason code.
3. Route, surface, and API — the Request route (method and canonical path template) and Surface / API columns tell you what was requested and which policy applied.
4. Identity — the recorded subject, and on the Identity tab the issuer, identity source, client ID, and key ID: who the decision applies to.
5. Auth-site / target — the Auth Site / target column: where the decision was enforced.
6. Upstream status, result, and duration — the upstream HTTP status, Not reached, Transport error, or Not recorded, plus the upstream duration in milliseconds on the Overview tab: what happened after (or never happened because of) the TrustPlane decision.

Worked example readings

Three shapes cover most of what you will read on this screen.

Allowed, verified, upstream HTTP 200 — the healthy baseline:

TrustPlane:        Allowed
Reason:            verified
Upstream:          200 (response received)

TrustPlane verified the signed request and authorized it; the upstream service handled it and returned 200. The Identity tab tells you which subject and key ID this success belongs to.

Denied, missing bearer, upstream not reached — an unauthenticated caller:

TrustPlane:        Denied
Reason:            missing bearer
Upstream:          Not reached

The request arrived without the required bearer credential, so TrustPlane denied it before any upstream saw it. “Not reached” is the important half: the upstream was never exposed to the request. Expect no subject-side identity detail — there was nothing verifiable to record.

Denied, request-binding mismatch, upstream not reached — a signed request whose binding does not match what was sent:

TrustPlane:        Denied
Reason:            request-binding mismatch
Upstream:          Not reached

The caller presented a signature, but the request TrustPlane received did not match what was signed — check the Identity tab’s body binding result and the Decision tab’s recorded check chain for the failing check. This shape is worth alerting on: it indicates either a misbehaving client (re-signing or mutating requests) or an attempted replay/tamper, and in both cases the upstream was never reached.

Read a deny

A denied request shows a Denied TrustPlane badge with a normalized reason, and its upstream result is typically Not reached — TrustPlane refused the request before any upstream saw it. Open the event’s Decision tab to see which recorded check failed and its reason code, then use the Identity tab to confirm the subject, key, and route the denial applies to.

The separation also works the other way: an Allowed TrustPlane decision paired with an upstream 4xx or 5xx status means TrustPlane authorized the request and the upstream service itself rejected or failed it. A Transport error upstream result means the runtime could not complete the upstream exchange.

Next steps

• Audit (runtime capability)
• Control console overview
• Trust Anchors
• Key lifecycle and compromise model