해설

제품 팀을 위한 Web Bot Auth: 서명된 agent 요청이 로드맵에 의미하는 것

AI agent와 크롤러는 누구인지 증명할 방법이 점점 더 필요하지만, 누구나 복사할 수 있는 User-Agent 문자열에 의존할 수는 없습니다. IETF의 Web Bot Auth 작업은 이를 표준화하려는 선도적 노력입니다. 여기서는 제품 관리자와 엔지니어링 리더를 위해, 어떻게 작동하는지, 무엇을 증명하는지, 2026년 11월 기준 상태는 어떤지, 그리고 어떻게 준비해야 하는지를 간단히 설명합니다.

조기 접근 받기 작동 방식 둘러보기

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

오랫동안 자동화된 클라이언트가 웹사이트에 자신이 누구인지 알릴 수 있는 유일한 방법은 User-Agent 헤더의 이름, 그리고 일부 대형 운영자의 경우 게시된 IP 주소 목록이나 reverse DNS 확인이었습니다. 이름은 쉽게 복사됩니다. 네트워크 목록은 이를 유지하는 운영자만 포괄합니다. AI agent가 웹 전반에서 실제 사람을 대신해 행동하기 시작하면서, 이 간극은 보안 문제일 뿐 아니라 제품 문제이기도 해졌습니다.

Web Bot Auth는 그 간극을 메우려는 선도적 노력입니다. 이 방식은 자동화된 클라이언트가 자신이 제어하고 공개한 키로 요청에 서명하게 하여, 사이트가 이름을 신뢰하는 대신 서명을 확인할 수 있게 합니다. 이 해설은 명세를 끝까지 읽지 않고도 무엇인지, 무엇이 바뀌는지, 그리고 무엇이 바뀌지 않는지를 이해해야 하는 제품 관리자와 엔지니어링 리더를 위한 것입니다.

요약

무엇인가: 자동화된 HTTP 클라이언트의 인증 방식을 표준화하는 IETF working group, webbotauth, 그리고 그 접근 방식입니다.
어떻게 작동하는가: 클라이언트는 HTTP Message Signatures (RFC 9421)를 사용해 각 요청의 일부에 서명하고, 공개 키 디렉터리를 가리킵니다. 사이트는 키를 가져와 서명을 검증합니다.
무엇을 증명하는가: 어떤 키가 요청에 서명했는지, 그리고 서명된 부분이 전송 중 변경되지 않았는지입니다.
무엇을 증명하지 않는가: 해당 agent가 요청한 작업을 수행할 권한이 있는지, 특정 사용자를 대신해 행동하는지, 또는 신뢰할 만한지입니다.
2026년 11월 기준 상태: RFC 9421은 게시된 Proposed Standard입니다. Web Bot Auth 프로토콜 문서는 아직 RFC가 아닌 working group Internet-Draft입니다.
해야 할 일: 유효한 서명을 강한 증거로 취급할 계획을 세우고, 서명되지 않은 트래픽도 계속 처리하며, authorization 결정은 자신의 코드에 유지하세요.

IETF Web Bot Auth 작업이란 무엇인가

IETF는 Web Bot Auth working group을 구성해 자동화된 클라이언트를 암호학적으로 인증하는 방법과, 그 뒤에 있는 운영자에 대한 더 많은 정보를 웹사이트에 제공하는 방법을 표준화했습니다. 이 charter는 주로 사람을 대상으로 하는 사이트에 초점을 맞추며, 범위에 포함되는 클라이언트를 폭넓게 지정합니다. 여기에는 crawler, web archiver, link checker, AI training crawler, 그리고 최종 사용자를 대신해 행동하는 AI agent가 포함됩니다.

제품 팀이 주목할 만한 charter의 제외 사항도 두 가지 있습니다. 최종 사용자 인증은 범위 밖이므로, 이것은 사람을 로그인시키는 방법이 아닙니다. bot reputation 추적도 범위 밖이므로, 이 표준은 누가 요청에 서명했는지 알려주지만, 그 운영자가 신뢰할 만한지는 알려주지 않습니다.

charter는 세 가지 유형의 산출물을 제시합니다.

사람을 위해 만들어진 웹사이트에 자동화된 클라이언트를 인증하는 기술에 관한 Standards track 문서.
도메인 이름이나 URL 같은 기존 식별자를 사용해 요청 bot에 대한 더 많은 정보를 전달하는 Standards track 문서.
key management, lifecycle, deployment 같은 운영 주제에 관한 Best Current Practice 또는 informational 문서.

2026년 11월 기준 문서 현황

2026년 11월 현재, working group에는 채택된 working group 문서가 하나 있습니다. 바로 draft-ietf-webbotauth-httpsig-protocol로, 제목은 "HTTP Message Signatures for automated traffic"이며 revision 01, 날짜는 2026년 10월 29일입니다. 이는 Internet-Draft이므로 아직 진행 중인 작업이며 계속 변경될 수 있습니다. RFC는 아닙니다.

또한 여러 개별 draft도 그룹과 관련되어 논의 중입니다. 여기에는 registry와 agent card 형식, anonymous bot authentication, 자동화된 클라이언트의 IP 범위를 게시하기 위한 JSON 형식, 그리고 signed agent metadata를 위한 header 제안이 포함됩니다. 개별 draft는 제안서이며, 이 날짜 기준으로 그룹에 채택된 것은 없습니다.

charter는 2026년 동안 명세를 IESG 승인용으로 보내는 마일스톤을 설정했습니다. 2026년 11월 기준으로 프로토콜 문서는 여전히 working group draft입니다. 현재 상태는 IETF datatracker page for the working group와 protocol draft에서 확인할 수 있습니다.

HTTP Message Signatures의 작동 방식

Web Bot Auth는 2024년 2월에 Proposed Standard으로 게시된 RFC 9421, HTTP Message Signatures를 기반으로 합니다. RFC 9421은 일반적인 메커니즘으로, HTTP message의 선택된 부분에 서명하는 방법과 서명을 header에 담는 방법을 정의합니다. Web Bot Auth는 이를 자동화된 클라이언트용으로 프로파일링합니다.

간단히 말하면, 서명된 agent 요청은 다음과 같이 작동합니다.

운영자가 키 쌍을 만듭니다. private key는 비밀로 유지하고 public key는 게시합니다.
클라이언트가 무엇에 서명할지 선택합니다. 대상 host나 URI, 생성 시각 같은 request component를 고릅니다. 현재 draft는 authority 또는 target URI를 포함하도록 요구하므로, 한 사이트를 위한 서명을 다른 사이트에 단순히 재사용할 수 없습니다.
클라이언트가 서명하고 전송합니다. 요청에는 무엇에 어떤 키로 서명했는지 설명하는 Signature-Input header와 서명 값을 담은 Signature header가 포함됩니다. draft는 web-bot-auth tag를 사용하며 각 서명에 creation time과 expiry time이 있을 것을 기대합니다.
사이트가 검증합니다. public key를 찾고, 수신한 요청에서 서명된 구성 요소를 다시 구성한 뒤, 서명을 확인합니다. 검사가 통과하면 요청은 해당 키 보유자가 서명한 것이며, 포함된 부분은 변경되지 않은 것입니다.

이 draft는 사이트가 서명을 요청할 수도 있게 합니다. origin은 보통 거절과 함께 Accept-Signature header를 보내 서명된 요청을 원한다는 뜻을 나타낼 수 있습니다.

key directory 개념

사이트가 올바른 public key를 찾지 못하면 서명은 의미가 없습니다. Web Bot Auth는 이를 key directory로 해결합니다.

현재 working group draft에서 클라이언트는 HTTPS URL을 담은 Signature-Agent header를 추가합니다. 그 URL은 운영자의 public key를 JSON Web Key Set으로 제공하는 directory를 가리킵니다. 사이트는 directory를 가져와 signature의 key identifier와 일치하는 키를 선택하고 검증합니다. draft는 또한 운영자가 자신의 directory를 제공할 수 있는 well-known path, /.well-known/http-message-signatures-directory도 정의합니다.

제품 팀에게 중요한 개념은 URL이 identity가 된다는 점입니다. agent 운영자는 자신이 key를 게시하는 위치로 식별되며, 이로써 signature는 운영자가 제어하는 domain에 연결됩니다. key rotation은 새 key를 이전 key와 함께 게시한 뒤, 이전 key를 제거하는 방식으로 동작합니다.

검증하는 사이트는 directory를 신중하게 다뤄야 합니다. 일반적인 HTTP 규칙에 따라 캐시하고, 크기 제한과 timeout을 설정하며, private network 주소로의 fetch를 피해야 합니다. 이는 표준적인 엔지니어링 고려사항이며, 많은 팀이 검증을 대신 수행하는 구성 요소를 선호하는 이유이기도 합니다.

유효한 signature가 증명하는 것과 증명하지 않는 것

이 부분은 제품 policy를 작성하는 모든 사람에게 가장 중요합니다.

유효한 signature가 증명하는 것:

요청이 특정 private key 보유자에 의해 서명되었다는 점.
그 키가 운영자가 제어하는 directory URL에 게시되어 있다는 점.
요청의 서명된 부분이 전송 중 변경되지 않았고, signature가 유효 기간 안에 있다는 점.

유효한 signature가 증명하지 않는 것:

agent가 작업을 수행할 authorization을 받았다는 점. 식별 가능하다고 해서 허가가 되는 것은 아닙니다. agent authorization를 보세요.
agent가 특정 사람을 위해 행동하거나 그 사람이 부여한 권한 범위 안에서 행동한다는 점. delegated authority를 보세요.
운영자가 신뢰할 만하거나 agent가 잘 행동할 것이라는 점. reputation은 working group 범위에서 명시적으로 제외됩니다.
서명되지 않은 요청에 대한 어떤 것. 서명되지 않은 트래픽은 별도로 처리해야 합니다.

유효한 signature를 누가 요청했는지에 대한 강한 증거로 취급한 다음, 자신의 access control이 그 발신자가 무엇을 할 수 있는지 결정하게 하세요.

제품 팀이 해야 할 일

RFC를 기다릴 필요는 없습니다. 서명된 agent 트래픽은 지금부터 준비할 수 있으며, draft의 일부 세부 사항은 바뀔 수 있다는 점을 염두에 두면 됩니다.

1. 결정보다 먼저 측정하세요

트래픽 중 얼마나 많은 부분이 자동화되어 있는지, agent가 어떤 route를 사용하는지, 그중 얼마나 서명되어 있는지 파악하세요. 사용자에게 아무 변화도 주지 않도록 observation mode에서 시작하세요.

2. 증거와 policy를 분리하세요

무엇을 결정할지와 별개로, 증거가 말하는 내용을 verified, declared, inferred 또는 unknown으로 기록하세요. 그러면 policy가 읽기 쉬워지고, 재계측 없이 더 엄격하게 하거나 완화할 수 있습니다. evidence basis 항목에서 네 가지 수준을 설명합니다.

3. verified agent에게 더 나은 경로를 제공하세요

의미가 있는 곳에서는 사람을 위해 만든 페이지 대신 verified agent에게 구조화된 콘텐츠나 agent 친화적 흐름을 제공하세요. AI agent에게 구조화된 콘텐츠 제공하기 안내서에 패턴이 정리되어 있습니다.

4. authorization은 자신의 코드에 두세요

서명은 누가 요청하는지 알려줍니다. 무엇을 할 수 있는지는 기존 permissions, scopes, confirmation으로 결정하세요. 영향이 큰 작업은 요청에 누가 서명했든 여전히 사람의 확인이 필요할 수 있습니다. 민감한 작업을 보호하면서 agent는 막지 않기를 보세요.

5. 서명되지 않거나 Unknown인 트래픽을 대비하세요

서명을 지원하는 범위는 agent와 도구마다 다르므로, 한동안은 서명된 요청과 서명되지 않은 요청이 섞여 있을 것으로 예상하세요. site-wide 규칙 하나를 정하기보다 route별로 declared, inferred, Unknown 트래픽에 어떤 일이 일어날지 결정하세요. Unknown 트래픽 처리하기 안내서에서 이를 살펴봅니다.

Proof of Actor가 Web Bot Auth를 사용하는 방법

Proof of Actor는 각 상호작용에서 행동하는 주체가 Human, Human + AI, Agent, Unknown 중 무엇인지 알려주고, evidence basis를 제시합니다. Web Bot Auth 서명은 그 증거 중 가장 강한 출처 중 하나입니다.

agent가 HTTP Message Signatures로 요청에 서명하면, Proof of Actor는 그 서명을 운영자가 게시한 키와 대조합니다. 검사가 통과하면 결과는 팀이 검토할 수 있는 증거와 함께 verified basis를 가집니다. 클라이언트가 header에서 자신을 이름만으로 밝히면 결과는 declared입니다. 결론이 행동 또는 맥락 신호에 기반하면 inferred로 표시됩니다. 증거가 충분하지 않으면 결과는 Unknown입니다.

그 맥락으로 무엇을 할지는 애플리케이션이 결정합니다. policy는 route별, actor class별, basis별로 작성되며 allow, adapt, challenge, review, rate-limit 같은 결과를 가질 수 있습니다. 기본적으로는 아무것도 enforce되지 않습니다. 실제 트래픽에 대해 policy를 preview한 뒤, 자신의 코드에서 route별로 enforce합니다.

Founding 팀은 Node.js middleware, Next.js, edge integration, 승인된 페이지의 browser collector, 일반적인 HTTP API, 또는 MCP server integration을 통해 증거를 수집할 수 있습니다. 실무 단계는 integrations와 서명된 agent 요청 검증하기 안내서를 참고하세요.

Proof of Actor는 표준이 가진 동일한 한계를 따릅니다. verified signature는 어떤 키가 요청에 서명했는지만 알려주며, 해당 agent가 authorization을 받았는지는 알려주지 않습니다. authorization은 귀하에게 남아 있습니다. evidence and limits 페이지에는 각 결과가 무엇을 지원할 수 있고 없는지가 정확히 정리되어 있습니다.

시작하기

Proof of Actor는 private beta 상태입니다. 선정된 founding developer team은 합의된 사용 한도 내에서 자동 청구 없이 최대 12개월 동안 무료로 사용할 수 있습니다. 조기 액세스 신청하기를 클릭하고, signed agent가 어떤 route를 사용할 것으로 예상하는지와 그것들에 대해 무엇을 하고 싶은지 알려주세요.

개발자를 위한

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent 또는 Unknown.
basis: 근거의 강도: Verified, Declared, Inferred 또는 Unknown.
evidence: 결과 뒤의 signal로, 팀이 이유를 확인할 수 있습니다.

관찰 모드로 시작하세요: 결과를 logs 옆에 기록하고, 정책을 선택할 때까지 아무것도 변경하지 마세요. Node.js 통합 가이드를 읽기

자주 묻는 질문

Web Bot Auth는 무엇인가요?

Web Bot Auth는 IETF working group인 webbotauth의 이름이며, 이들이 표준화하는 접근 방식입니다. 자동화된 클라이언트가 HTTP Message Signatures (RFC 9421)로 HTTP 요청에 서명하고 공개 키를 게시하면, 웹사이트는 어떤 운영자가 요청을 보냈는지 검증할 수 있습니다.

Web Bot Auth는 완성된 표준인가요?

아직 아닙니다. 2026년 11월 기준으로 주요 프로토콜 문서인 draft-ietf-webbotauth-httpsig-protocol은 revision 01의 working group Internet-Draft입니다. 그것이 기반으로 삼는 서명 형식인 RFC 9421은 게시된 Proposed Standard입니다.

유효한 Web Bot Auth 서명은 agent가 행동할 수 있다는 뜻인가요?

아닙니다. 그것은 어떤 키가 요청에 서명했는지, 그리고 서명된 부분이 변경되지 않았음을 증명할 뿐입니다. 그 agent가 데이터를 읽거나, 양식을 제출하거나, 특정 사용자를 대신해 행동할 수 있는지는 여전히 애플리케이션의 authorization 결정입니다.

제품 팀이 Web Bot Auth를 직접 구현해야 하나요?

사이트는 서명을 검증하면 됩니다. 자동화된 클라이언트를 직접 운영하는 경우가 아니라면 서명할 필요는 없습니다. 검증에는 키 디렉터리 가져오기, 안전한 캐싱, 서명 확인이 포함되며, Proof of Actor 같은 도구가 이를 대신 수행할 수 있습니다.

요청에 서명하지 않는 agent는 어떻게 처리해야 하나요?

이용 가능한 증거에 따라 처리하세요. 즉, declared, inferred 또는 Unknown으로 다루면 됩니다. 한동안은 서명된 트래픽과 서명되지 않은 트래픽이 섞여 있을 것으로 예상하고, 사이트 전체에 하나의 규칙을 두기보다 route별 fallback을 설정하세요.

Proof of Actor는 Web Bot Auth를 어떻게 사용하나요?

HTTP Message Signatures를 게시된 키와 대조하고, 검증이 통과하면 결과를 verified basis로 보고합니다. 그러면 귀하의 policy가 verified agent를 declared 또는 Unknown 트래픽과 다르게 다룰 수 있습니다.

누가 귀하의 app을 사용하는지 파악하세요.

소수의 founding developer를 위한 private beta입니다.

조기 접근 받기 가격 보기

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