Prove what every agent did

When an auditor or an incident review asks what an agent did and why it was allowed, logs are a weak answer. They show that something happened, but they can be edited or rotated away, and they do not prove which policy made the decision. Your operations team also needs the same traffic in the monitoring tools it already runs, rather than in one more console.

What you can do

• Record every policy decision, allow or deny, in a durable audit entry so that you can show which policy, at which version, authorised or blocked each request.
• Tie each decision to the signed Verifiable Presentation the gateway issued for the same request, where it issued one, so that the caller’s identity rests on a signature rather than on a log line.
• Follow one request through its policy decisions, trust checks, and injected credentials so that an incident review starts from the whole story.
• Send metrics, traces, and logs to your own OpenTelemetry collector, Prometheus, or AWS CloudWatch so that agent traffic appears in the tools you already use.
• Rely on log redaction, on by default, to mask credentials and other sensitive values in logs and exported traces so that tokens and keys stay inside your boundary.

How it works

Governance evidence lives on the Audit page, recorded while VP Auditing is on in Settings › Security, where you also choose which event categories to record. Each Policy Decisions entry records the outcome, the policy scope, the flow direction, the caller, and the denial reason where the rule gave one. It can also carry the Policy version and Policy SHA of the exact Rego that ran, shown as chips on the entry.

Decision records themselves are unsigned. Where the gateway issued a signed Verifiable Presentation for the request, the event detail panel shows it alongside the decisions that share its trace ID. Editing a policy adds a new version rather than overwriting the old one, so an earlier decision always points to the rules that were actually enforced. Entries that share a trace ID are grouped in the event detail panel, from the caller’s identity through policy decisions and trust checks to any credential the gateway injected.

Operational telemetry goes to the tools you already run. On the Metrics page, Integrated Metrics Configuration sends traces, metrics, and logs to an OpenTelemetry (OTLP) collector and metrics to AWS CloudWatch, while Prometheus scrapes the gateway’s metrics endpoint. Each request carries an X-Gateway-Trace-Id that also appears on its metrics and audit entries, so a spike on a dashboard leads to the decisions behind it.

Log redaction is on by default and masks matching values in logs and exported traces. Its default rule set covers credentials such as Bearer, Basic, and API-key values, as well as private keys, access tokens, and email addresses. If a backend is unreachable, its exporter backs off and drops that batch, so request forwarding carries on unaffected.

The audit trail and the logs are separate records. Exported and downloaded logs include policy denials and failed trust checks, while the Audit page records allowed and denied decisions alike. The Logs page’s Download All Logs button downloads the gateway’s log files, which do not include the audit entries.

Related

• Audit log: Event categories, how records tie to signed presentations, and the event detail panel in full.
• Settings reference - Security tab: Turn on VP Auditing and choose the event categories to record.
• Observability: How the gateway produces metrics, traces, and logs and which backends each can reach.
• Metrics: Reference for every field emitted on a request record.