Traffic analysis, audit and retention

Role: deployment operator. These steps use the operator console. An ordinary hosted account exposes only its own keys and limits; request policy, protection-mode and masking changes from the operator.

Use reports to answer four separate questions: what was detected, which policy decided, what actually happened to the request, and where the evidence is stored. Report controls change the displayed sample; they do not enable or disable inspection.

Trace a request from client to decision

1. Record the client’s Request ID, UTC time, tenant and application/model label; omit raw secrets.
2. Open Audit and forensics, select that tenant and time range, then search by request ID.
3. Read sensitivity, classes, injection, tier, decision reason and policy/rule identity. Compare actual action and destination with the intended policy.
4. Inspect content or replacement evidence only when stored and you have investigation permissions. Missing content is not proof of absent inspection.
5. For grouped threats, open Incidents / Incident analytics / DLP / Policy analytics; use links back to the same audit record.

What the fields mean

Reports, filters and live feed

Period, tenant, action, class, policy and app filters narrow the report. Clear filters to compare against a broader sample; recheck UTC time. Auto-refresh Off/None and live-feed Pause only affect this browser. Clear clears the visible feed buffer; durable audit remains. SSE reconnect may omit previous events, so investigations use persisted audit. No data and HTTP 503 are different outcomes.

Classifier Health requires available historical sources. Check its period, failure/fail-safe ratio and latency alongside the integration’s actual classifier status. A closed breaker means attempts are permitted; it does not prove every request succeeded. A circuit-open or fail-safe event should be investigated with its request ID.

Check inspection availability

Classifier Health and latency percentiles describe inspection, not only a running HTTP process. A 200 response from /healthz can contain inspection_healthy=false: the process is alive but inspection readiness is not established. Record UTC time and the affected environment, inspect classifier status, and check again after dependency recovery. Do not disable inspection to obtain a positive health result.

For on-prem administrators: point Kubernetes gateway and classifier readinessProbe at /readyz, while keeping livenessProbe on /healthz. An unready gateway returns readiness 503 and must be removed from ready service endpoints; a failed dependency should not by itself restart a live gateway. Readiness recovers automatically after the classifier recovers. Use the internal service address: external ingress may not expose /readyz, so an external 404 does not prove classifier failure.

A positive readiness result establishes the checked dependencies at that moment. It does not replace an actual request through the configured provider, authorization checks or audit persistence. Interpret latency by cascade stage and hardware; Tier 0/1 fast-path p99 is not full LLM-response p99.

Prepare protected object storage

The managed installation has a separate Kubernetes MinIO store prepared for audit checkpoints, with HTTPS, versioning and COMPLIANCE Object Lock. Staging and production use separate namespaces, CAs and credentials. This store is intended for signed hashes and counts; its presence does not enable checkpoint publication or establish that original requests or database backups are already uploaded to S3.

For on-prem administrators with storage management rights:

1. Allocate a dedicated bucket with versioning and Object Lock. Read the COMPLIANCE retention of the exact object version and confirm deletion/shortening denial, including with the administrative S3 identity. A successful upload with a retention header is insufficient.
2. Give the gateway only prefix-scoped reads and lock metadata access. Give a separate publisher COMPLIANCE writes without Delete, bypass or administrative permissions. Do not give the gateway the signing key or database modification rights.
3. Verify the HTTPS endpoint name and CA chain. For a private CA, mount an explicit public trust bundle; keep TLS verification enabled. Allow only the required network connections.
4. Set quotas and monitor physical space, certificate expiry and replica availability. Preserve PVCs/PVs during shutdown or rollback. Storage inside the same Kubernetes cluster remains subject to administrators who can destroy the underlying volumes; an independent disaster copy needs a separate boundary and restore qualification.

Encrypted originals retain their separate expiry policy. Do not copy them into a longer-lived immutable bucket without an agreed lifecycle. The new checkpoint signing/verification process described below remains a candidate until its separate release.

Confirm decision persistence

Release candidate: this contract has not been deployed to production. It becomes an active customer instruction only with the qualified gateway release.

When PostgreSQL is configured, an inspection decision must commit before a successful result is returned. The proxy separately records request admission before provider dispatch, decisions on inspected response fragments before releasing them, and the final request outcome. Additional events do not increase request counters.

1. Keep the Request ID and find the outcome in Аудит и форензика. New records retain the complete verdict, confidence, escalation path, detected spans and evaluated policy snapshots with SHA-256. After a refresh, the incident card uses the persisted verdict. Older records may lack these fields; missing values are not reconstructed by guessing.
2. HTTP 503 with audit_unavailable means required persistence was not confirmed. Do not treat the operation as successful. Check its Request ID before retrying: a lost acknowledgement can leave a committed record, and a proxy may already have contacted the provider.
3. If final persistence fails after SSE has started, the stream returns an error event without a successful [DONE]. Previously released inspected fragments may already have reached the client. Account for potentially repeated tool actions before retrying.
4. Changes to incident status, assignee or notes commit together with their history receipt. Re-read the card after an error; an error response does not mean the requested status was accepted.

A saved decision snapshot and an intact local chain do not prove PostgreSQL immutability, exact model-weight identity or complete history across replicas. A security audit also needs verified storage permissions, external chain anchors and a recovery procedure.

Check integrity scope and limitations

Release candidate, not production. Do not apply these statuses to a running version without checking its release.

1. With audit read permission, open Audit and forensics → Chain and wait for verification. The shared PostgreSQL ledger is checked in a consistent full snapshot: all new events, writers and request phases, together with required projections and incident-change history. The count represents events, not requests.
2. Distinguish “The audit chain is consistent” from complete history qualification. An amber panel means limited proof. Read its scope, historical-record count outside the new chain and limitations. Checked serving-role permissions and triggers do not replace an independent external anchor or protected archive.
3. File mode checks one process’s local segment. Missing or empty persistent storage cannot produce a positive result. HTTP 409 carries a negative report; 503 means authoritative history could not be verified. Check storage and retry the read; do not create artificial events to obtain a green status.
4. Compliance uses actual verification instead of the ring-buffer size. Its JSON export retains scope, chain_ok, verified, storage_protected, legacy_entries and limitations. Until external anchors and legacy coverage are qualified, verified remains false.

“Protected audit cleanup is unavailable” means the serving workload cannot delete evidence without a qualified archive. A previously configured period remains visible but inactive; enabling a positive period returns 409 archive_required. Do not bypass this boundary by granting the gateway DELETE or superuser. Encrypted originals have separate retention: expired bodies become unavailable, while metadata and disclosure receipts remain. Journal archival, independent anchors and restore still require separate qualification.

External checkpoint — release candidate

The prepared update lets an independent job publish a signed checkpoint in versioned S3 storage with COMPLIANCE Object Lock. The gateway receives only public keys and read access. Operators separately pin environment/stream and maximum age; the HTTP gateway never receives the signing key.

After Audit and forensics → Chain, read “The external checkpoint anchors entries through #…; newer entries: …”. The second count is the ledger tail not yet externally anchored. An unavailable, stale or mismatched configured checkpoint produces a negative result without falling back to a positive local check. Security analysts correlate Request ID, sequence and the JSON report; changing trust keys or stream is not a recovery procedure.

A checkpoint contains hashes and counts, neither original requests nor a backup. Legacy records form an observed baseline; their authenticity before cutover is not established. A matching checkpoint still does not enable complete verified=true status: independent archive restore remains unqualified. Encrypted originals do not gain a longer lifetime through this mechanism. This section remains a candidate until staging regression and the coordinated production release.

Operator archives are not a production feature yet. The separate secure-archive capture, inspect and restore commands are intended for storage administrators. Publication requires a separate SELECT-only database role, S3 publisher and private keys; cold recovery requires an S3 reader, AES key and a new explicitly marked recovery database with independently retained archive SHA-256/version pins. Keep the signing key and publisher out of the recovery process. Original bodies keep their previous availability deadline; logical expiry does not prove physical deletion. The full cycle and access to a recovered original request were checked on an isolated staging copy, but scheduling, physical cleanup and release remain unqualified. Administrators must retain keys outside the source database; MinIO and Secrets in the same Kubernetes cluster do not replace a separate disaster copy.

Retention and content access

Open Audit and forensics → Journal retention → maximum age → Save to change the supported retention control. Re-read its status. Changing a report’s period does not change retention.

Enlarge screenshot

1 2 3 4

1. Search
2. Audit retention
3. Days / save
4. Tenant filter

Inspection API, proxy and response analysis

/v1/inspect and batch inspection return decisions. The calling application must implement block, replacement and rerouting; dry-run inspection does not intercept other traffic. Pass point=request for inputs, response for model output, and tool_output for tool results; app labels use X-IAM-Secure-App. /v1/chat/completions uses the configured proxy to inspect request and response. Streaming response inspection uses overlapping windows; already-delivered chunks cannot be retroactively withdrawn. Do not assume full-response buffering from an inspector result.

Detailed settings · FAQ · Audit section