Compliance API는 요청 시 활성화됩니다. Claude Enterprise 조직은 전체 API에 액세스할 수 있으며, Claude Console 조직은 Activity Feed에만 액세스할 수 있습니다. 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를 참조하세요.| 패턴 | 선택 조건 |
|---|---|
| 윈도우 폴링 | 파이프라인이 고정된 일정으로 실행되고, 상태 비저장 워커를 선호하며, 윈도우를 재생하거나 중첩하는 것을 허용할 수 있는 경우 |
| 커서 기반 증분 읽기 | 활동 발생과 파이프라인 수집 사이의 지연 시간을 최소화하고, 이미 처리한 페이지를 다시 읽는 것을 피하고 싶으며, 실행 사이에 커서를 저장할 수 있는 내구성 있는 저장소가 있는 경우 |
윈도우 내의 모든 활동이 이미 쿼리 가능하도록 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로 중복을 제거하고, 각 새 윈도우를 이전 윈도우와 몇 분 정도 겹치도록 확장하거나, 이전 윈도우를 다시 쿼리하는 주기적 조정 작업을 실행하세요.
현재 시각에 너무 가까운 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로 전달하여 저장된 커서보다 새로운 활동을 조회하세요. 백필을 위해 반대 방향으로 이동하려면 대신 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일 때 존재합니다. 이 필드를 읽기 전에 판별자를 확인하세요. 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를 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?