Compliance API를 활성화하려면 Compliance API 설정을 참조하세요.
필수 스코프: Compliance Access Key 또는 Admin API 키의 read:compliance_activities.
프로덕션 Compliance API 통합에는 세 가지 설계 선택이 필요합니다: Activity Feed를 소비하는 방법, 그 출력을 "security information and event management"(보안 정보 및 이벤트 관리), 즉 SIEM 시스템과 상호 연관시키는 방법, 그리고 활동 및 콘텐츠의 장기 사본을 보관할 위치입니다. 이러한 선택은 엔드포인트 자체와는 독립적이며, 이 페이지는 그 트레이드오프를 평가하는 데 도움을 줍니다.
이 페이지는 전반에 걸쳐 참조되는 매개변수와 페이지네이션 계약을 정의하는 Activity Feed 쿼리와, 콘텐츠 보존 계획에서 참조되는 콘텐츠 엔드포인트 및 deleted_at 의미 체계를 정의하는 채팅, 파일 및 프로젝트 검색 및 삭제를 읽었다고 가정합니다.
Activity Feed는 두 가지 소비 패턴을 지원합니다: created_at.gte와 created_at.lt로 경계가 지정된 주기적 윈도우 폴링과, 한 응답에서 커서를 영속화하고 다음 요청에 전달하는 커서 기반 증분 읽기입니다. 두 방식 모두 동일한 Activity 객체를 반환하며, 차이점은 클라이언트가 호출 사이에 영속화하는 상태입니다.
두 패턴 모두 다음 제약 조건을 공유합니다:
limit은 5,000입니다./v1/compliance/* 엔드포인트에서 공유됩니다. 응답 헤더와 재시도 계약은 429 Too Many Requests를 참조하세요.| 패턴 | 선택 시점 |
|---|---|
| 윈도우 폴링 | 파이프라인이 고정된 일정으로 실행되고, 상태 비저장(stateless) 워커를 선호하며, 윈도우의 재생 또는 중복을 허용할 수 있는 경우 |
| 커서 기반 증분 읽기 | 활동 발생과 파이프라인 수집 사이의 latency(지연 시간)를 최소화하고 싶고, 이미 소진한 페이지를 다시 읽는 것을 피하고 싶으며, 실행 간에 커서를 영속화할 수 있는 내구성 있는 저장소가 있는 경우 |
윈도우 내의 모든 활동이 이미 쿼리 가능하도록 created_at.lt를 최소 1분 이전으로 설정하세요. 연속된 윈도우가 간격이나 중복 없이 타일링되도록 하한에는 created_at.gte를, 상한에는 created_at.lt를 사용하고, 이전 윈도우의 lt 값을 다음 윈도우의 gte 값으로 재사용하세요.
curl --fail-with-body -sS -G \
"https://api.anthropic.com/v1/compliance/activities" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
--data-urlencode "created_at.gte=2026-04-20T07:00:00Z" \
--data-urlencode "created_at.lt=2026-04-20T08:00:00Z" \
--data-urlencode "limit=5000"응답에 has_more: true가 있으면 해당 윈도우에 한 페이지 이상의 활동이 포함되어 있는 것입니다. 응답의 last_id를 다음 요청의 after_id로 전달하여 윈도우 내에서 페이지를 넘기거나(has_more가 false가 되면 중지), 더 작은 시간 윈도우를 선택하세요. 전체 계약은 결과 페이지네이션을 참조하세요.
깔끔하게 타일링하더라도, 윈도우가 닫힌 후에 인덱싱된 활동은 이후 윈도우에 절대 나타나지 않습니다. 활동 id로 중복을 제거하고, 각 새 윈도우를 이전 윈도우와 몇 분 정도 겹치도록 넓히거나, 이전 윈도우를 다시 쿼리하는 주기적인 조정(reconciliation) 패스를 실행하세요.
created_at.lt 경계가 현재 시점에 너무 가까우면 늦게 인덱싱된 활동이 조용히 그리고 영구적으로 누락됩니다. created_at.gte가 해당 활동을 지나가면 이후의 어떤 윈도우도 이를 복구할 수 없습니다. 1분 쿼리 가능성 수치를 부드러운 권장 사항이 아니라 문서화된 인덱싱 지연으로 취급하세요.
first_id="activity_01XyDMpzjS89pFZXqSFUBDr6" # first_id from a previous response
curl --fail-with-body -sS -G \
"https://api.anthropic.com/v1/compliance/activities" \
--header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
--data-urlencode "limit=5000" \
--data-urlencode "before_id=$first_id"has_more가 false가 될 때까지 페이지를 넘긴 다음, 마지막 응답의 first_id를 영속화하고 다음 실행 시 변경 없이 before_id로 전달하여 저장된 커서보다 최신 활동을 검색하세요. 백필(backfill)을 위해 반대 방향으로 탐색하려면 last_id를 영속화하고 대신 after_id로 전달하세요. 커서 대 페이지 토큰의 전체 참조와 재시도 의미 체계는 결과 페이지네이션을 참조하세요.
프로덕션 캐치업(catch-up) 루프는 has_more와 first_id를 기반으로 반복을 구동하여 마지막 폴링 이후 기록된 활동을 가져옵니다:
cursor = stored_cursor
loop:
page = GET /v1/compliance/activities?before_id={cursor}&limit=5000
store(page.data)
if page.first_id is not null:
cursor = page.first_id
if not page.has_more: break
persist(cursor)커서는 키 교체 후에도 유지됩니다. 키 관리 및 교체를 참조하세요.
각 페이지는 전달한 커서에 인접합니다. 루프는 한 번에 한 페이지씩 현재를 향해 앞으로 이동합니다. has_more가 true인 동안에는 단일 응답을 최신 상태로 간주하지 마세요. has_more가 false가 된 후에만 커서를 영속화하세요. 가져오지 않은 페이지는 이 응답의 first_id와 현재 사이의 더 최신 페이지이며, 루프를 완료하거나 다시 실행할 때까지 읽히지 않은 상태로 남아 있습니다.
각 Activity에는 SIEM(Splunk, Datadog, Microsoft Sentinel, Cribl 또는 유사 시스템)에 이미 있는 이벤트와 조인할 수 있는 필드가 포함되어 있습니다:
| Compliance API 필드 | 조인 대상 |
|---|---|
actor.user_id | ID 공급자의 안정적인 사용자 식별자 |
actor.email_address | 안정적인 ID를 사용할 수 없을 때의 디렉터리 이메일 |
actor.ip_address | 네트워크, VPN 및 엔드포인트 로그 |
created_at | 모든 소스에 걸친 시간 윈도우 상관 관계 |
actor.user_id와 actor.email_address는 actor.type이 user_actor일 때 존재합니다. 읽기 전에 판별자(discriminator)를 확인하세요. user_id는 사용자 계정에 대한 안정적이고 불투명한 식별자입니다. 모든 Compliance API 엔드포인트와 활동 페이로드에서 일관되며, 사용자의 이메일이나 표시 이름이 변경되어도 바뀌지 않습니다. 기본 조인 키로 email_address가 아닌 user_id를 사용하세요.
Compliance API 자체에 대한 호출은 compliance_api_accessed 활동을 생성합니다. SIEM이 누가 언제 컴플라이언스 데이터를 쿼리했는지 기록하도록 이러한 활동을 다른 활동 유형과 함께 수집하세요. activity_types[]=compliance_api_accessed를 전달하여 쿼리 범위를 지정한 다음, 클라이언트에서 actor.type이 api_actor인 각 활동의 actor.api_key_id를 읽어 특정 Compliance Access Key 또는 Admin API 키에 접근을 귀속시키세요.
나중에 검색할 수 있는 항목은 세 가지 보존 기간에 의해 결정됩니다:
| 데이터 | 보존 기간 | 제어 주체 |
|---|---|---|
| Activity Feed 레코드 | 6년 | Anthropic |
| 채팅, 파일 및 프로젝트 콘텐츠 | 조직의 claude.ai 보존 정책 | 귀하의 조직 |
| Compliance API를 통해 하드 삭제된 콘텐츠 | 보존되지 않음; 삭제는 즉각적이고 영구적임 | DELETE 엔드포인트 호출자 |
Claude Platform의 나머지 부분이 보존을 처리하는 방법은 API 및 데이터 보존을 참조하세요.
다음과 같이 내보내기 후 보관과 온디맨드 API 검색 중에서 결정하세요:
deleted_at이 채워진 상태로 계속 검색 가능하지만, Compliance API 삭제는 그렇지 않습니다.그 외의 모든 경우에는 직접 API 검색에 의존하고 병렬 사본을 유지하지 마세요.
Activity Feed를 최소 1회(at-least-once) 전달로 취급하세요. 올바르게 페이지네이션된 순회는 모든 활동을 최소 한 번 반환하지만, 부분 실패 후 재시도하면 이미 저장한 활동이 다시 전달될 수 있습니다. 활동 id 필드로 중복을 제거하세요.
목록 엔드포인트는 total_count 필드나 체크섬을 반환하지 않습니다. 내보내기 실행이 완료되었음을 증명하려면 다음을 로깅하세요:
last_id.request-id.콘텐츠 엔드포인트(채팅, 파일, 프로젝트 및 프로젝트 첨부 파일)는 claude.ai 데이터만 제공합니다. Activity Feed는 조직 전체의 관리 및 리소스 이벤트를 표시합니다. Compliance API에는 다음이 포함되지 않습니다:
Compliance API가 캡처하는 것과 캡처하지 않는 것에 대한 자세한 내용은 Compliance API FAQ를 참조하세요.
관리 연속성(chain of custody)을 위해 내보낸 레코드를 출처 메타데이터(소스 엔드포인트, 쿼리 매개변수, 실행 타임스탬프 및 각 레코드의 콘텐츠 해시)와 함께 저장하세요.
Was this page helpful?