Skip to main content
Request Logs capture the full request and response body — prompt text included — so you can troubleshoot what an agent actually sent and got back. That is sensitive data, so the gateway will not capture it until a workspace Admin has recorded explicit consent. This page covers how that consent is recorded, how versioning forces a fresh decision when your disclosure wording changes, and how to withdraw it. If you are looking for how long captured bodies are kept or how to scrub them, see Retention and Right to erasure. Capture is off by default and never retroactive. Turning it on is a deliberate act with an audit trail, because the captured documents contain whatever your users typed. The control is workspace-level: an Admin configures it once and it applies to every key in the workspace, rather than leaving two members’ keys behaving differently for the same stored logs.
Capture fail-closes. If no valid, non-revoked, current-version consent is on file, the gateway captures nothing — regardless of whether the enable switch looks “on”. Consent is the authoritative gate; the toggle alone never starts capture.
A consent record is a durable, auditable object. It carries who consented, when, the disclosure version they saw, and — once withdrawn — when it was revoked: 
{
  "consented": true,
  "consented_at": "2026-06-09T14:21:05Z",
  "consented_by": 8123,
  "disclosure_version": 1,
  "revoked": false
}
You configure this in the console under your workspace’s Request Logs settings panel — reading the current state is open to any workspace role, but recording or changing consent requires Admin. The panel shows you the current disclosure version and the retention bounds so you can review the wording before you acknowledge. When you flip capture on, the console sends the explicit acknowledgment together with the disclosure version it displayed. Both are required the first time:
1

Open Request Logs settings

Workspace settings → Request Logs. Members see the panel read-only; Admins see editable controls and the disclosure text.
2

Read the disclosure, then acknowledge

The console submits consent_ack: true and consent_version (the version you just read) alongside the enabled switch. The grant is rejected if the version you acknowledged is not the server’s current one — that means you were shown stale wording.
3

Capture begins on the next request

The decision takes effect on the workspace’s next relay call. The grant is recorded distinctly in the audit log — a standalone record of who consented to capturing prompt content, separate from the on/off toggle.
Consent is recorded on behalf of the whole workspace by an Admin. Workspace Admins already see every member’s captured prompts in the Request Logs viewer, so the consent decision is theirs to make — make sure your own end-user disclosures cover it.

​
3. Disclosure versioning

The point of versioning request log consent is that a consent only stays valid while it matches the current disclosure version. Each consent record stores the disclosure_version that was in effect when it was granted. The gateway treats a record as authorizing capture only while that stored version still equals the live one. When your privacy or disclosure wording materially changes, the live disclosure version is bumped. The effect is immediate and deliberate:
The capture chokepoint fail-closes: workspaces whose consent just went stale stop capturing prompt bodies immediately, with no fallback. They do not keep recording under withdrawn consent.
Because versioning is the lever, you never have to hunt down individual records to invalidate stale consent across your workspace — bumping the disclosure version does it in one move, and capture pauses until each workspace makes an explicit fresh decision.
Turning capture off explicitly withdraws consent. The record is not deleted — it is marked revoked (with a revoked_at timestamp) and retained for the audit trail, so the history of who consented and who withdrew stays provable. Re-enabling later requires a fresh acknowledgment; a revoked record never re-authorizes capture on its own.
Stored consentCapture
Valid, current versionAllowed
RevokedNot allowed
Stale disclosure versionNot allowed
None on fileNot allowed
Withdrawal stops future capture. To remove bodies already captured, set a shorter retention window or trigger erasure — see Retention and Right to erasure.

​
5. The audit trail

Every consent transition is logged distinctly from the capture on/off toggle, so the grant and the withdrawal are each their own provable record of who acted and when. A grant logs the disclosure version that was acknowledged; a withdrawal logs the revocation. This is the evidence your compliance reports read when they attest that prompt capture only ran under recorded consent — see how that surfaces in Export evidence.
Capture itself respects your retention bounds independently of consent: the default window is 30 days and an Admin-set per-workspace value is server-clamped to a hard maximum of 180 days. Consent governs whether capture happens; retention governs how long what was captured survives.

​
6. Where to go next

Retention

How long captured bodies live, the per-workspace window, and the server-clamped maximum.

Right to erasure

Self-delete, the grace window, and the cascade that scrubs captured prompts and matches.

Data residency

The region your signed compliance evidence is stamped and stored under.

Shared responsibility

What the gateway records and audits versus the disclosures and decisions that stay yours.
Consent on the gateway is recorded, versioned, and revocable — so capturing prompt content is always a deliberate, current decision an Admin can prove they made, and one that pauses itself the moment the disclosure behind it changes.