주 콘텐츠로 건너뛰기
용어집

Web Bot Auth

Toshendra Sharma

작성자 Toshendra Sharma창립자 겸 CEO, AgentCredia · Updated November 13, 2026

봇과 AI 에이전트가 HTTP 요청에 암호학적으로 서명하여 사이트가 누가 보냈는지 검증할 수 있게 하는 방법에 관한 IETF 작업 그룹과 Internet-Draft 작업입니다.

Web Bot Auth란 무엇인가

Web Bot Auth는 자동화된 웹 트래픽을 인증하는 IETF 작업 그룹과 그 Internet-Draft 작업의 이름입니다. 핵심 아이디어는 단순합니다. 크롤러, AI 도우미, 자율 에이전트가 HTTP Message Signatures (RFC 9421)를 사용해 자신의 HTTP 요청에 서명하고, 그 서명을 검증하는 공개 키를 자신이 관리하는 식별자 아래에 공개하는 것입니다. 그러면 웹사이트는 누구나 복사할 수 있는 user-agent 문자열에 의존하지 않고, 요청이 실제로 명시된 운영자에게서 왔는지 확인할 수 있습니다. 이것이 제품 팀에 어떤 의미인지 보려면 제품 팀을 위한 Web Bot Auth를, 구현 단계는 서명된 AI 에이전트 요청을 검증하는 방법 가이드를 보십시오.

2026년 11월 기준으로, 작업 그룹의 핵심 문서는 draft-ietf-webbotauth-httpsig-protocol이며, 이는 인밴드 키 검색을 위한 Signature-Agent 헤더, JSON Web Key Sets를 기반으로 한 키 디렉터리 형식, 그리고 해당 디렉터리가 제공되는 well-known URI를 정의합니다. 작업 그룹 문서 페이지에는 관련 개별 초안들과 함께 이 문서가 나열되어 있습니다. 이 문서들은 Internet-Draft이므로 진행 중인 작업입니다. 키를 어떻게 검색하는지, 어떤 요청 구성 요소에 서명이 필요한지, 어떤 헤더가 운영자 정보를 전달하는지 같은 세부 사항은 버전마다 바뀔 수 있습니다. 구현자는 어떤 스냅샷이 아니라 현재 초안을 따라야 합니다.

중요한 이유

웹사이트와 API는 오랫동안 user-agent 문자열과 IP 범위로 봇을 식별해 왔습니다. 하지만 둘 다 한계가 있습니다. user-agent 문자열은 쉽게 위조할 수 있고(user-agent spoofing 참조), IP 범위는 자주 변하고 클라우드 제공업체들 사이에서 공유됩니다. AI 에이전트가 사람을 대신해 브라우징하고, API를 호출하고, MCP servers를 사용하기 시작하면, 애플리케이션은 협력하는 자동화 클라이언트를 익명 클라이언트와 구분할 더 견고한 방법이 필요합니다.

서명된 요청은 그 더 견고한 기반을 제공합니다. 검증된 서명은 애플리케이션이 알려진 운영자를 일관되게 인식하고, 사람용 인터페이스 대신 구조화된 경로를 제공하며, 활동을 정확하게 측정할 수 있게 합니다.

높은 수준에서 어떻게 작동하는가

  1. 운영자는 키 쌍을 생성하고, 자신의 식별자와 연결된 위치, 보통 도메인 아래의 http-message-signatures-directory well-known 경로에 공개 키를 게시합니다.
  2. 각 요청에는 선택된 요청 구성 요소를 포함하는 Signature-Input 및 Signature 헤더, 키 식별자, 그리고 키 디렉터리를 가리키는 Signature-Agent 헤더가 포함됩니다.
  3. 수신 사이트는 운영자가 게시한 키를 가져오거나 캐시하고, 서명 기본값을 다시 구성한 뒤 서명을 검증합니다.
  4. 성공하면 사이트는 요청이 해당 게시된 식별자와 연결된, 그 키의 보유자에 의해 생성되었다는 것을 알게 됩니다.

무엇을 입증하고, 무엇을 입증하지 않는가

Web Bot Auth 서명은 자동화된 클라이언트를 인증합니다. 하지만 다음 질문에는 답하지 않습니다.

  • 운영자가 요청한 작업을 수행할 권한이 있는지 여부(agent authorization),
  • 사람이 그 행동을 지시했거나 승인했는지 여부(delegated authority),
  • 그 행동이 안전한지, 또는 반환된 콘텐츠가 적절하게 사용될 것인지 여부.

이것들은 수신 애플리케이션의 자체 인증, 인가, 정책이 결정해야 합니다. 우리의 블로그 글 서명된 AI 에이전트 요청이 입증하는 것과 입증하지 못하는 것에서 이 경계를 더 자세히 다룹니다.

흔한 오해

  • "모든 봇이 곧 서명하게 될 것이다." 채택은 클라이언트별로 진행됩니다. 애플리케이션은 한동안 서명된 트래픽, 선언된 트래픽, 익명 트래픽이 섞인 상태를 보게 되므로, 각각을 처리할 분명한 방법이 필요합니다.
  • "서명은 봇을 좋게 만든다." 서명은 봇을 알려진 대상으로 만듭니다. 알려졌다는 것은 정책의 출발점이지, 정책 그 자체는 아닙니다.
  • "초안은 최종본이다." 그것은 진화 중인 Internet-Draft입니다. 현재 텍스트를 기준으로 구현하고, 개정이 있을 것으로 예상하십시오.

Proof of Actor와의 관계

Proof of Actor는 검증된 서명을, 그것이 증명하는 키와 식별자 범위에 속하는 basis가 Verified인 증거로 취급합니다. 이 제품은 이를 선언된 이름과 추론된 신호와 분리하며, 정체성을 권한으로 바꾸지 않습니다. Proof of Actor는 이러한 표준이 성숙함에 따라 서명된 요청을 검증하도록 설계되었고, Route에 있는 귀사의 정책이 검증된 에이전트가 무엇을 할 수 있는지를 결정합니다.

이것이 APIs와 MCP servers에 어떻게 들어맞는지 보거나, 초기 액세스를 신청하십시오.

출처

자체 앱에서 actor intelligence를 확인하세요.

먼저 이야기하고 싶으신가요? 창립자와 상담하세요