Manage log retention and purge
Enterprise Tier
Request records age out of the management plane on fixed defaults that are set by the operator of the deployment, not in the Console. No Console or API operation purges request records on demand. Prompt and response bodies routinely carry the most sensitive data an organization handles, so the retention that applies, and the limits of what a customer can change, belong in any compliance statement.
Retention has three parts: how much is captured in the first place, how long the management plane keeps it, and what happens to the archived copy. How much request detail is captured is decided in the request-log mode, described in Control request log data.
Persona: Platform operator working in the Admin Console, in coordination with compliance and data-governance stakeholders.
Estimated time: 15 to 20 minutes to confirm the logging mode and record the retention that applies.
When this guide applies
Typical cases:
| Situation | What it covers |
|---|---|
| A retention policy specifies a maximum age for request records | The default retention that applies, and who controls it |
| A compliance review asks where request records live and for how long | The active store, the archive, the audit log, and any SIEM copies |
| A right-to-erasure or subject-access request requires specific records to be deleted | How such a request is handled, and what a purge does not reach |
| Different apps or routes carry different retention obligations | Choosing the single deployment-wide logging mode that satisfies the strictest obligation in scope |
Outcomes
By the end of this guide:
- The logging mode that decides what request records exist has been confirmed.
- The retention that applies to request records and MCP request logs has been recorded, together with who can change it.
- The way an erasure request is handled has been agreed with compliance stakeholders.
- The relationship between request-log retention, audit-trail retention, and any external SIEM copies is understood, so a claim about "where the data lives and for how long" can be made accurately.
Prerequisites
- Administrator access to the Admin Console, typically the
super_adminrole, to read the logging mode. - A logging mode already chosen and active for the deployment. Retention governs whatever records the mode produces. See Control request log data.
- Agreement with compliance stakeholders on the retention the organization requires, so it can be compared with the defaults below.
Step 1: confirm the logging mode and its scope
Retention only governs records that exist, so the first step is to confirm what the deployment is configured to capture. The request-log mode is deployment-wide: a deployment running in metadata-only mode has no prompt or response bodies to age out, while one running in full mode stores the largest record and has the strongest case for a short retention window.
- Review the deployment's active logging mode, configured in Control request log data.
- Note whether the mode captures prompt or response bodies. These carry the most sensitive content and usually warrant the shortest retention.
- When the deployment's request-log mode is Off, no request records are stored, so there is no retention to account for and nothing to erase.
- Record the obligations each app, route, or data classification in scope carries, as the basis for comparing them with the retention that applies, recorded in the next step.
This mapping is what shows which obligation is the strictest. Because the capture mode is deployment-wide, the mode and the retention posture built on it must satisfy the most sensitive class of data that shares the store.
Step 2: record the retention that applies
The management plane keeps request records for a fixed period, set by the archival job that runs against its database. These values are deployment settings (Helm values or environment variables of the archival job). No Console screen or API sets them.
| Record | Default retention | What happens at the end |
|---|---|---|
| Request log bodies | 7 days | The row is copied to object storage, then the body is cleared from the database. |
| MCP request logs | 30 days | The row is deleted. A value of 0 turns pruning off. |
| Usage rollups, hourly | 48 hours to 90 days, by interval | The row is deleted. |
| Usage rollups, daily | 365 days | The row is deleted. |
Two points affect any statement made to a reviewer:
- Where the management plane is operated by Tetrate, these values are not a customer setting. Ask Tetrate for the values in force.
- The archived copy in object storage is not deleted by Agent Router. Its retention is set by the bucket's own lifecycle policy, which is a separate clock from the values above.
Records that are not sent to the management plane are not covered by these defaults. Under the metadata-only mode, prompt and response bodies are not sent. Full records sent to a customer's own backend are governed by that backend. See Control request log data.
Step 3: handle an erasure request
Agent Router has no Console screen or API operation that purges request records on demand. A right-to-erasure or subject-access deletion that has to reach the management plane has to be raised with Tetrate. No self-service path exists.
A deletion that is requested but not confirmed cannot be attested to. Written confirmation of the removal should be requested and kept with the record of the request: what was removed, when, on whose authority, and how the removal was verified. A purge reaches the active store only. It does not remove the archived copy in object storage, any copy exported to a SIEM, or the audit record that the request was made.
Step 4: account for the audit trail and external SIEM copies
Request-log retention governs request records. It does not govern two other places the same activity may be recorded, and a complete retention statement has to account for all three.
- The audit trail is outside the request-log retention. Administrative actions are recorded in Agent Router's audit log, which is not subject to the request-log retention above. No Console or API operation edits or deletes audit records, so a purge of request records does not remove the audit record that a request was made. Audit records are sealed in signed checkpoints that make tampering detectable. See Audit Agent Router activity for the audit surface and Audit log events reference for the event vocabulary.
- Exported copies live under the SIEM's retention. Where request or audit records are exported to an external SIEM, those copies are governed by the SIEM's retention policy, not Agent Router's. Removing a record from the active store does not remove any copy already delivered to the SIEM; that copy ages out, or is purged, on the SIEM's own terms. See Export audit and policy decisions to a SIEM.
"The record has been deleted" is therefore only true for the store it names. A right-to-erasure response that has to cover every copy must address the active store, the archive (Step 2), and any external SIEM separately, each on its own retention clock.
Where to go next
Configure data residency and no-retention
Where nothing should be stored, the deployment-wide Off request-log mode removes the record at source.
Export audit and policy decisions to a SIEM
Retain audit records beyond the Admin Console window and govern them centrally.
Revisit the logging mode
If a retention window keeps coming up too short for a scope, the underlying mode may be capturing more than the scope needs.