직원이 업무상 Claude를 사용하게 되면서, 정보 시스템 부서에는 하나의 까다로운 질문이 생깁니다. '고객의 카드 번호나 미공개 결산 수치를 누군가가 실수로 프롬프트에 붙이지 않았는지'를 어디에서 막을 것인가 하는 문제입니다. 지금까지 Claude 측에서 이런 종류의 검사를 할 수 있었던 것은, 각자 기기에서 돌아가는 Claude Code의 클라이언트 훅(client hook)뿐이었습니다. 브라우저 채팅이나 Cowork를 통해 전송되는 문장에는 손댈 수가 없었습니다.

Anthropic이 8월 5일에 베타 공개한 inference hooks는 이 검사 지점을 '사용자 단말'에서 'Anthropic의 서버'로 옮기는 메커니즘입니다. 이를 활성화하면, claude.ai, Cowork, Claude Code 어디에서 온 추론 요청이라도 모델이 작동하기 직전에 조직이 지정한 서버로 한 번 전송되며, allow(통과)할지 deny(차단)할지 판정을 기다리게 됩니다.

설정하는 방법은 간단합니다. 사용자가 프롬프트를 보내면 Anthropic이 귀하의 AI 보안 서버에 HTTPS POST를 날립니다. 본문(body)에는 대화 기록(transcript)이 담겨 있으며, 서버는 이를 심사한 후 기본적으로 5초(설정 범위는 1~10000ms) 이내에 작은 JSON을 반환합니다.

{ "action": "allow" }

차단할 때는 이유를 명시해야 합니다. deny_reason은 그대로 사용자에게 표시되므로, 스캐너의 내부 코드가 아니라 '무엇을 지워야 하는지'를 작성하라고 엔드포인트 문서에는 강조되어 있습니다.

{
"action": "deny",
"deny_reason": "이 프롬프트에는 카드 정보가 포함되어 있을 가능성이 있습니다.",
...
}

여기서 사소하지만 중요한 설계 판단이 하나 있습니다. 거부(deny)하더라도 HTTP 상태 코드는 200을 반환해야 합니다. 500이나 타임아웃은 '거부'가 아니라 'Webhook 실패'로 처리되어, 판정 자체가 성립되지 않은 것으로 간주됩니다. 실패 시 요청을 차단할지 통과시킬지는 조직 설정에 따라 결정되며, 통과(fail-open)로 설정된 경우 검사를 거친 프롬프트가 그대로 모델에 도달합니다.

전송되는 본문 내용은 사용자가 화면에서 보는 것과 동일합니다. 텍스트, 도구 호출 및 그 결과, 첨부 파일에서 추출한 텍스트입니다. 반면, 시스템 프롬프트, 도구 정의(tool definition), Claude의 내부 추론, 파일의 원시 바이트는 포함되지 않습니다. 따라서 이미지에만 적힌 기밀 정보는 검사할 수 없다는 한계점도 명확히 명시되어 있습니다. 요청은 다음과 같은 형태를 하고 있습니다.

{
"type": "prompt",
"actor": { "type": "user", "email_address": "alice@example.com" },
...
}

발표 기사나 일부 보도에서는 'Claude가 MCP나 스킬, 플러그인을 통해 도구를 호출하면, 그 응답이 모델에 도달하기 전에 검사된다'고 서술하고 있습니다. 하지만 1차 자료를 대조해 보면, 이는 현재 구현보다 조금 더 나아간 모습을 이야기하는 것입니다.

문서는 명확합니다.

Today the only hook event is prompt, which fires once per governed inference request, before inference begins. Response-side enforcement is planned as a later event.

즉, 현시점에서 훅이 발동하는 이벤트는 '프롬프트 전송 시'의 종류가 하나뿐입니다. 그렇다면 왜 '도구 응답이 검사된다'고 말할 수 있는가 하면, 과거 도구 실행 결과(tool_result 블록)는 대화 기록(transcript)에 쌓인 상태로 다음 추론 시 함께 전송되기 때문입니다. 이전 턴에서 도구가 반환한 내용도 심사 대상이 됩니다. 다만, 도구가 결과를 반환하는 그 순간, 모델이 읽기 전에 개입하여 막을 수 있는 전용 이벤트는 아직 없습니다. 마케팅 용어와 구현의 세부 사항 간에 괴리가 있는 전형적인 사례이며, 도입을 검토한다면 '현재 가능한 것'은 문서의 prompt 이벤트를 기준으로 측정하는 것이 올바릅니다.

정당성 검증은 독자적인 방식이 아닌 표준 Webhooks를 준수합니다. webhook-id, webhook-timestamp, webhook-signature 세 개의 헤더로 구성되며, 서명(signature)은 {id}.{timestamp}.{raw body}입니다.

HMAC-SHA256에 대한 것입니다. 문서에서 경고하는 함정(pitfall)이 두 가지 있는데, 서명 검증은 JSON을 파싱하기 전의 원시 바이트(raw bytes)에 대해 수행해야 하고, 서명 키(whsec_ 뒤의 부분)는 표준 base64로 디코드해야 합니다. URL 세이프한 디코더를 사용하면 키 바이트가 틀어져서 모두 손실될 수 있습니다. 요청 출처 IP는 160.79.106.0/24에 고정되어 있지만, 이는 허용 목록(allowlist)의 보조 역할일 뿐 서명 검증을 대체할 수는 없다고도 쓰여 있습니다.

운영 측면에서 놓치기 쉬운 점들을 표로 정리했습니다.

흥미로운 점은 이것이 모델의 지능 문제가 아니라 거버넌스 파이프라인에 관한 이야기라는 것입니다. SaaS에 데이터를 전달하기 전에 관문을 둔 것이, 벤더 서버 측에서 표준화되었다는 점입니다. Netskope나 Zscaler 같은 기존 DLP(Data Loss Prevention) 제품을 뒤쪽에 그대로 삽입할 수 있도록 설계되었고, Webhook이라는 검증된 형태로 구현한 것은 솔직히 좋은 판단이라고 생각합니다.

반면에 모든 요청에 동기적인 왕복 시간이 끼게 되므로, 사용자의 서버 응답 속도가 조직 전체의 체감 레이턴시가 됩니다. 5초를 기다리다 차단되는 것보다는, 현장에서 다른 도구로 도망갈 미래도 쉽게 상상할 수 있습니다. 10MB 본문을 기본 설정 리버스 프록시가 조용히 떨어뜨리고(drop), fail-open과 결합되어 검사를 빠져나가게 하는 사고도 아주 일어날 것 같습니다. allow/deny의 두 가지 선택지로는 빈칸 처리(masking)를 할 수 없는 것도, 실제로 운영해 보면 너무 경직된다고 느낄 순간이 있을 것입니다. 도입한다면, 먼저 shadow 모드(판정만 관찰하고 차단하지 않음)로 실제 트래픽 분포를 살펴보고, 거부율과 레이턴시를 측정한 후에 Enforce verdicts를 적용하는 순서를 강력히 권장합니다. 참고로 대상은 Claude Enterprise의 베타 버전이며, Amazon Bedrock이나 Google Cloud 경로는 제외되고, 설정에는 organization:manage 권한이 필요합니다.