메인 콘텐츠로 건너뛰기
Request Logs는 전체 요청과 응답 본문 — 프롬프트 텍스트 포함 — 을 캡처하므로 에이전트가 실제로 무엇을 보냈고 받았는지 트러블슈팅할 수 있습니다. 그것은 민감한 데이터이므로, 게이트웨이는 워크스페이스 Admin이 명시적 동의를 기록하기 전까지 그것을 캡처하지 않습니다. 이 페이지는 그 동의가 어떻게 기록되는지, 공개 문구가 바뀔 때 버전 관리가 어떻게 새로운 결정을 강제하는지, 그리고 그것을 철회하는 방법을 다룹니다. 캡처된 본문이 얼마나 오래 보관되는지 또는 그것을 스크럽하는 방법을 찾고 있다면, 보존과 삭제권을 참조하세요.

​
1. 요청 로그 동의가 캡처를 게이트하는 이유

캡처는 기본적으로 꺼져 있고 결코 소급적이지 않습니다. 그것을 켜는 것은 감사 추적이 있는 의도적 행위입니다, 왜냐하면 캡처된 문서는 사용자가 입력한 무엇이든 담고 있기 때문입니다. 컨트롤은 워크스페이스 수준입니다: Admin이 한 번 구성하면 워크스페이스의 모든 키에 적용되며, 동일한 저장된 로그에 대해 두 멤버의 키가 다르게 동작하게 두지 않습니다.
캡처는 페일 클로즈합니다. 유효하고, 철회되지 않고, 현재 버전의 동의가 파일에 없으면, 게이트웨이는 활성화 스위치가 “켜짐”으로 보이는지와 무관하게 아무것도 캡처하지 않습니다. 동의가 권위 있는 게이트입니다; 토글만으로는 결코 캡처를 시작하지 않습니다.
동의 레코드는 내구성 있고 감사 가능한 객체입니다. 그것은 누가 동의했는지, 언제, 그들이 본 공개 버전, 그리고 — 일단 철회되면 — 언제 철회되었는지를 담습니다: 
{
  "consented": true,
  "consented_at": "2026-06-09T14:21:05Z",
  "consented_by": 8123,
  "disclosure_version": 1,
  "revoked": false
}

​
2. 동의 기록 (Admin)

워크스페이스의 Request Logs 설정 패널 하에서 콘솔에서 이것을 구성합니다 — 현재 상태를 읽는 것은 모든 워크스페이스 역할에 열려 있지만, 동의를 기록하거나 변경하는 것은 Admin을 요구합니다. 패널은 현재 공개 버전과 보존 한계를 보여주므로 확인하기 전에 문구를 검토할 수 있습니다. 캡처를 켜면, 콘솔이 명시적 확인을 그것이 표시한 공개 버전과 함께 보냅니다. 첫 번째에는 둘 다 필요합니다:
1

Request Logs 설정 열기

워크스페이스 설정 → Request Logs. 멤버는 패널을 읽기 전용으로 봅니다; Admin은 편집 가능한 컨트롤과 공개 텍스트를 봅니다.
2

공개를 읽은 다음 확인

콘솔이 enabled 스위치와 함께 consent_ack: true와 consent_version(방금 읽은 버전)을 제출합니다. 확인한 버전이 서버의 현재 것이 아니면 부여가 거부됩니다 — 그것은 당신이 오래된 문구를 보았음을 의미합니다.
3

다음 요청에서 캡처 시작

결정은 워크스페이스의 다음 릴레이 호출에 효력이 발생합니다. 부여는 감사 로그에 별개로 기록됩니다 — 켬/끔 토글과 분리된, 누가 프롬프트 콘텐츠 캡처에 동의했는지의 독립적 레코드.
동의는 Admin에 의해 전체 워크스페이스를 대신하여 기록됩니다. 워크스페이스 Admin은 이미 Request Logs 뷰어에서 모든 멤버의 캡처된 프롬프트를 보므로, 동의 결정은 그들이 내릴 몫입니다 — 당신 자신의 최종 사용자 공개가 그것을 커버하는지 확인하세요.

​
3. 공개 버전 관리

요청 로그 동의를 버전 관리하는 요점은 동의가 현재 공개 버전과 일치하는 동안에만 유효하게 유지된다는 것입니다. 각 동의 레코드는 부여될 때 효력이 있던 disclosure_version을 저장합니다. 게이트웨이는 그 저장된 버전이 여전히 라이브 버전과 같은 동안에만 레코드를 캡처 허가로 취급합니다. 당신의 프라이버시 또는 공개 문구가 실질적으로 바뀌면, 라이브 공개 버전이 올라갑니다. 효과는 즉각적이고 의도적입니다:
버전 올림은 모든 기존 레코드의 disclosure_version을 오래되게 만듭니다. 그것들 중 어느 것도 더 이상 캡처를 허가하지 않습니다.
캡처 초크 포인트가 페일 클로즈합니다: 동의가 방금 오래된 워크스페이스는 즉시 프롬프트 본문 캡처를 멈춥니다, 폴백 없이. 그것들은 철회된 동의 하에서 계속 기록하지 않습니다.
Admin이 패널을 다시 열고, 새 공개를 읽고, 현재 버전에서 다시 확인합니다. 신선한 레코드가 스탬프되고 캡처가 재개됩니다.
버전 관리가 레버이기 때문에, 워크스페이스 전반에서 오래된 동의를 무효화하기 위해 개별 레코드를 추적할 필요가 결코 없습니다 — 공개 버전을 올리면 한 번의 동작으로 그것을 하고, 각 워크스페이스가 명시적인 신선한 결정을 내릴 때까지 캡처가 일시 중지됩니다.

​
4. 동의 철회

캡처를 명시적으로 끄는 것은 동의를 철회합니다. 레코드는 삭제되지 않습니다 — revoked_at 타임스탬프와 함께 철회로 표시되고 감사 추적을 위해 보관되므로, 누가 동의했고 누가 철회했는지의 히스토리가 증명 가능하게 유지됩니다. 나중에 다시 활성화하려면 신선한 확인이 필요합니다; 철회된 레코드는 스스로 결코 캡처를 다시 허가하지 않습니다.
저장된 동의캡처
유효, 현재 버전허용
철회됨불허
오래된 공개 버전불허
파일에 없음불허
철회는 미래 캡처를 멈춥니다. 이미 캡처된 본문을 제거하려면, 더 짧은 보존 윈도우를 설정하거나 삭제를 트리거하세요 — 보존과 삭제권을 참조하세요.

​
5. 감사 추적

모든 동의 전이는 캡처 켬/끔 토글과 별개로 로깅되므로, 부여와 철회는 각각 누가 언제 행동했는지의 자체 증명 가능한 레코드입니다. 부여는 확인된 공개 버전을 로깅합니다; 철회는 철회를 로깅합니다. 이것은 프롬프트 캡처가 기록된 동의 하에서만 실행되었음을 증명할 때 컴플라이언스 보고서가 읽는 증거입니다 — 그것이 증거 내보내기에 어떻게 표면화되는지 보세요.
캡처 자체는 동의와 독립적으로 당신의 보존 한계를 존중합니다: 기본 윈도우는 30일이고 Admin이 설정한 워크스페이스별 값은 180일의 하드 최댓값으로 서버 클램프됩니다. 동의는 캡처가 일어나는지를 관장합니다; 보존은 캡처된 것이 얼마나 오래 살아남는지를 관장합니다.

​
6. 다음으로 갈 곳

보존

캡처된 본문이 얼마나 오래 사는지, 워크스페이스별 윈도우, 그리고 서버 클램프 최댓값.

삭제권

자기 삭제, 유예 기간, 그리고 캡처된 프롬프트와 매치를 스크럽하는 캐스케이드.

데이터 레지던시

서명된 컴플라이언스 증거가 스탬프되고 저장되는 리전.

책임 범위

게이트웨이가 기록하고 감사하는 것과 당신의 몫으로 남는 공개와 결정.
게이트웨이에서의 동의는 기록되고, 버전 관리되고, 철회 가능합니다 — 그래서 프롬프트 콘텐츠를 캡처하는 것은 항상 Admin이 내렸음을 증명할 수 있는 의도적이고 현재적인 결정이며, 그 뒤의 공개가 바뀌는 순간 스스로 일시 중지되는 것입니다.