검증된 자동화

검증된 자동 요청 식별

자동 클라이언트가 요청에 서명하면, 애플리케이션은 그 서명을 확인하고 호출자를 그에 맞게 처리할 수 있습니다. Proof of Actor는 그 확인을 명확하고 라우팅 가능한 결과로 바꿉니다.

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

모든 자동 트래픽이 같은 것은 아닙니다

자동 클라이언트는 매분 애플리케이션에 도달합니다. 검색 크롤러, 모니터링 도구, 사용자 대신 페이지를 가져오는 파트너 연동, AI 어시스턴트, 작업을 수행하는 자율 에이전트가 그 예입니다. 오랫동안 대부분의 애플리케이션이 이들을 구분할 수 있는 유일한 방법은 user-agent 헤더였고, 이 문자열은 어떤 클라이언트든 원하는 값으로 보낼 수 있었습니다.

이 때문에 애플리케이션 팀은 난처한 상황에 놓입니다. 모든 자동화를 의심하면 고객이 의존하는 정상적인 에이전트의 경험이 나빠집니다. 반대로 헤더를 그대로 믿으면 누구나 유명 크롤러라고 주장할 수 있습니다.

검증된 자동 요청은 이 구도를 바꿉니다. 자동 클라이언트가 공개한 키로 요청에 서명하면, 애플리케이션은 서명을 확인해 어떤 클라이언트가 요청에 서명했는지 암호학적으로 알 수 있습니다. Proof of Actor는 그 확인을 코드가 라우팅할 수 있는 하나의 일관된 actor 결과로 만듭니다. 그 확인이 무엇을 증명하고 무엇을 증명하지 않는지 더 자세히 보려면 서명된 AI 에이전트 요청이 증명하는 것을 읽어보세요.

요청 서명의 작동 방식

자동 트래픽에 대해 새롭게 자리 잡는 접근 방식은 HTTP message signatures를 사용하며, 이는 RFC 9421에서 표준화되어 있습니다. 이 표준은 HTTP 메시지의 구성 요소에 대한 서명을 생성, 인코딩, 검증하는 방법을 정의합니다. 클라이언트는 각 요청의 선택된 부분에 개인 키로 서명하고, 서명과 그 매개변수를 헤더에 포함합니다. 그런 다음 자신이 제어하는 식별자, 일반적으로 도메인과 연결된 위치에 대응하는 공개 키를 게시합니다.

요청이 도착하면 수신자는 공개된 키를 가져오거나 조회하고, 서명된 내용을 재구성한 뒤 서명을 확인합니다. 검증되면 그 요청은 해당 키의 보유자가 서명한 것입니다. 자동 트래픽 서명 작업은 IETF Web Bot Auth working group에서 계속 진행되고 있으며, 이 그룹의 charter는 크롤러와 최종 사용자를 대신해 동작하는 AI 에이전트 같은 자동 클라이언트를 암호학적으로 인증하는 범위를 포함합니다. Web Bot Auth 용어집 항목이 이를 요약합니다. 서명된 AI 에이전트 요청이 증명하는 것 블로그 글은 검증된 요청의 전체 흐름을 단계별로 보여주며, APIs use case는 검증이 가장 먼저 효과를 내는 지점을 설명합니다.

서명된 에이전트 요청 검증하기 가이드는 타임스탬프, 재전송 방지 창, 키 캐싱을 포함해 그 메커니즘을 자세히 다룹니다.

검증된 서명이 증명하는 것과 증명하지 않는 것

이 구분이 검증된 자동 요청을 올바르게 다루는 데 가장 중요합니다.

유효한 서명은 증명합니다. 요청이 공개 식별자와 연결된 키로 서명되었다는 사실을 증명합니다. 그 키가 운영자의 도메인에 속한다면, 요청은 그 운영자의 키를 보유한 클라이언트에서 온 것입니다.

유효한 서명은 다음을 증명하지 않습니다:

에이전트에게 누가 지시했는지, 또는 이 작업을 사람에게 요청받았는지;
사람이 에이전트에게 권한을 위임했는지;
운영자 뒤에 있는 실제 법적 신원;
요청된 작업이 안전한지, 또는 애플리케이션에서 허용되는지.

이들은 별개의 질문입니다. 애플리케이션은 자체 자격 증명, 인가 모델, 정책으로 답합니다. Proof of Actor는 이를 의도적으로 분리하고, Detection & Limitations 페이지에서 각 근거가 정확히 무엇을 확립할 수 있는지 설명합니다.

Proof of Actor가 검증된 자동 요청을 처리하는 방식

Detect

통합은 서명 헤더를 포함한 요청 컨텍스트를 Proof of Actor에 전달합니다. 서명은 공개된 키와 대조해 확인됩니다. 검증된 요청은 Verified 근거로 기록됩니다. 이름만 밝힌 클라이언트는 Declared로 기록됩니다. 행동 패턴은 Inferred로 기록됩니다. 충분한 근거가 없으면 결과는 Unknown입니다. 암호학적 검사가 통과하지 않으면 어떤 것도 Verified로 승격되지 않습니다.

Understand

어떤 검증된 운영자가 애플리케이션을 호출하는지, 어떤 route를 사용하는지, 얼마나 자주 사용하는지, 그리고 그것이 선언된 자동화나 Unknown과 어떻게 다른지 확인하세요. 각 결과의 근거 요약에는 어떤 키와 식별자가 관련되었는지가 표시되므로, 팀이 요청을 빠르게 조사할 수 있습니다.

Route

정책에 그 근거를 사용하세요. 일반적인 패턴은 다음과 같습니다:

읽기 전용 route, 예를 들어 API 또는 페이지의 Markdown 버전에서 검증된 에이전트에게 구조화된 응답을 제공합니다.
선언된 클라이언트에는 표준 한도를 유지하면서, 인지한 검증된 운영자에게는 rate-limit을 상향합니다.
서명이 무엇을 말하든 모든 쓰기 route에서 기존 인가를 유지합니다.
각 route마다 서명되지 않은 호출자와 Unknown 호출자를 위한 명시적인 fallback을 정의합니다.

정책은 고객이 결정합니다. Proof of Actor는 그 결정을 뒷받침하는 근거를 제공합니다.

user-agent 헤더만으로는 충분하지 않은 이유

user-agent 문자열은 선언입니다. 어떤 클라이언트든 어떤 값이든 보낼 수 있고, user-agent spoofing은 특별한 기술을 요구하지 않습니다. 그래서 크롤러 운영자는 자체 검증 절차를 공개합니다. Google은 Googlebot 확인을 위해 역방향 및 정방향 DNS 조회와 공개 IP 범위를 문서화하고, Bing은 Bingbot 확인을 위한 DNS 검사를 문서화하며, OpenAI는 각 crawler와 user agent에 대한 IP 범위 파일을 공개합니다. Proof of Actor는 user-agent 주장을 선언된 근거로만 취급하며, 결코 검증으로 보지 않습니다. 즉, 유효한 서명 없이 유명 크롤러라고 주장하는 클라이언트는 선언된 근거 또는 추론된 근거로 보고되며, 정책은 이를 신원을 증명한 클라이언트와 다르게 다룰 수 있습니다.

이것이 검증된 자동 요청이 가치 있는 이유입니다. 헤더를 복사한 모든 사람에게까지 신뢰를 확장하지 않으면서, 그 신뢰를 받을 자격을 얻은 클라이언트에게만 신뢰를 확장할 수 있는 신뢰할 만한 방법을 제공합니다.

신원 근거, 자격 증명, 인가

자동 클라이언트를 제공하는 어떤 애플리케이션에서도 세 계층이 함께 작동합니다:

신원 근거: 누가 이 요청에 서명했는가? 검증된 서명이 이에 답합니다.
자격 증명: 어떤 계정이 책임이 있는가? API 키, token 또는 session이 이에 답합니다.
인가: 이 호출자가 이것을 수행해도 되는가? 권한 모델이 이에 답합니다.

Proof of Actor는 첫 번째 계층을 강화하고 이를 가시적으로 만듭니다. 신원이나 위임 자격 증명을 발급하지 않으며, 인가를 대체하지도 않습니다. 계층을 분리해 두어야 검증된 에이전트에게는 낮은 위험의 route에서 관대하게, 영향이 큰 요청에는 신중하게 대응할 수 있습니다.

적용 위치

Proof of Actor는 게이트웨이, 인증, rate limiting과 함께 배치됩니다. 통합은 서버 사이드 미들웨어, 엣지, MCP server 또는 범용 HTTP 통합으로 실행되며, 각 창립 팀과 직접 함께 제공됩니다. 트래픽의 대부분이 APIs와 도구라면 APIs와 MCP Servers 사용 사례가 가장 중요한 패턴을 보여줍니다.

관찰 모드로 시작하기

모든 통합은 관찰 모드에서 시작합니다. 결과는 애플리케이션의 응답 방식을 바꾸지 않은 채 기록되므로, 자동 트래픽 중 얼마나 많은 부분이 검증되었는지, 어떤 운영자가 서명하는지, Unknown 비율이 어디에서 가장 높은지 확인할 수 있습니다. 정책은 나중에, route별로, 근거가 그것을 뒷받침할 때 적용됩니다. How It Works가 전체 흐름을 설명합니다.

검증을 신뢰할 수 있게 만드는 실무 세부사항

서명 검증은 주변 세부사항만큼만 정확합니다. 몇 가지 실천 방법은 운영 환경에서 검증된 자동 요청을 안정적으로 만듭니다.

키를 합리적으로 캐시하기

운영자의 공개 키를 모든 요청마다 가져오면 지연 시간이 늘어납니다. 적절한 기간 동안 캐시하고, 알려지지 않은 키 식별자로 인해 서명이 실패할 때 갱신하세요. 그래야 키 회전이 거짓 실패로 이어지지 않습니다.

요청의 올바른 부분에 서명하기

타임스탬프만 포함하는 서명은 증명하는 것이 거의 없습니다. 서명된 구성 요소에 method, path, host가 포함되어 있는지 확인하세요. 그래야 서명이 애플리케이션이 실제로 받은 요청에 묶입니다.

근거 기록하기

검증된 각 요청마다 키 식별자, 공개 식별자, 결과를 함께 보관하세요. 비정상적인 일이 발생하면 팀이 어떤 클라이언트가 무엇에 언제 서명했는지 정확히 볼 수 있습니다.

Proof of Actor는 Detect 단계의 일부로 이러한 검사를 처리하고, 정책이 읽을 수 있는 근거로 결과를 보고하므로 애플리케이션 코드는 단순하게 유지됩니다.

창립 개발자 프로그램에 참여하기

Proof of Actor는 private beta 상태입니다. 선정된 창립 개발팀은 합의된 사용 한도 내에서 최대 12개월 무료 액세스와 함께, 엔지니어의 직접 통합 지원을 받을 수 있습니다.

자동 클라이언트가 애플리케이션에 도달하고, 검증된 클라이언트를 다르게 다루고 싶다면 조기 액세스를 신청하세요. 애플리케이션과 관찰되는 자동 호출자에 대해 알려주시면, Proof of Actor가 어떻게 맞는지 보여드리겠습니다.

출처

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.
Overview of OpenAI crawlers, OpenAI.

개발자를 위한

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 통합 가이드를 읽기

자주 묻는 질문

검증된 자동 요청이란 무엇인가요?

알려진 식별자, 예를 들어 운영자 도메인에 대해 공개된 키로 검증되는 암호학적 서명이 포함된 자동 클라이언트의 요청입니다. 어떤 클라이언트가 요청에 서명했는지 보여줍니다.

검증된 서명이 있으면 에이전트가 인가되었다는 뜻인가요?

아니요. 서명은 요청을 키와 그 공개 식별자에 연결할 뿐입니다. 그 클라이언트가 작업을 수행할 수 있는지는 애플리케이션이 별도로 내리는 인가 결정입니다.

요청에 서명하지 않는 자동 클라이언트는 어떻게 되나요?

Proof of Actor는 여전히 이를 분류하며, 사용 가능한 경우 선언된 근거와 추론된 근거를 사용합니다. 근거가 충분하지 않으면 Unknown으로 보고합니다. 모든 결과에는 그 근거가 표시됩니다.

user-agent 문자열만으로 클라이언트를 검증할 수 있나요?

아니요. user-agent 문자열은 쉽게 위조할 수 있으므로 검증이 아니라 선언에 해당합니다. 요청을 검증 가능하게 만드는 것은 암호학적 서명입니다.

어떻게 시작하나요?

조기 액세스를 신청하세요. 창립 팀은 관찰 모드로 시작하며, 선정된 팀은 합의된 사용 한도 내에서 최대 12개월 무료 혜택을 받을 수 있습니다.

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

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

조기 접근 받기 가격 보기

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