AI 에이전트 탐지

모든 결과의 근거를 보여주는 웹사이트용 AI 에이전트 탐지

웹사이트의 상호작용이 사람, AI와 함께 작업하는 사람, 자율 에이전트, 또는 아직 증거로 식별할 수 없는 출처에서 비롯되었는지 확인하세요. 모든 결과에는 그 근거가 표시됩니다.

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

이제 웹사이트에는 한 종류가 아닌 여러 종류의 방문자가 있습니다

대부분의 웹 역사에서 웹사이트는 단순한 모델을 가정할 수 있었습니다. 사람이 브라우저를 열고, 여기저기 클릭하고, 때로는 로그인하는 방식입니다. 분석, rate limits, 온보딩 흐름, 보안 점검은 모두 그런 사람을 기준으로 설계되었습니다.

하지만 이제는 그 모델이 실제 트래픽을 설명하지 못합니다. 오늘날 하나의 웹사이트에는 스스로 탐색하는 사람, AI assistant에게 요약이나 입력을 맡기는 사람, 다른 사람을 대신해 페이지를 읽고 endpoint를 호출하는 autonomous agent, 그리고 수많은 crawler와 script가 함께 들어옵니다. AI providers도 이런 방문자 중 일부를 직접 문서화합니다. 예를 들어 OpenAI는 search crawler, training crawler, 그리고 ChatGPT 사용자가 질문할 때 페이지를 방문하는 fetcher에 대해 서로 다른 user agent를 공개하며(OpenAI crawler documentation), Anthropic도 ClaudeBot, Claude-User, Claude-SearchBot에 대해 같은 방식으로 문서화합니다(Anthropic crawler documentation). 이들 방문자 중 일부는 환영할 만합니다. 일부는 다른 경험이 필요합니다. 일부는 민감한 작업을 하기 전에 더 면밀히 살펴봐야 합니다.

문제는 이런 상호작용의 대부분이 겉보기에는 비슷하다는 점입니다. 로그인은 어떤 계정이 사용 중인지 알려 줍니다. 그러나 사람이 직접 클릭하는지, assistant가 그 세션을 통해 동작하는지, 또는 자동화된 client가 다른 사람을 위해 가격 페이지를 읽는지는 알려 주지 않습니다. 웹사이트용 AI 에이전트 탐지는 이 간극을 evidence로 메워, 팀이 모든 traffic을 똑같이 취급하지 않고 각 actor 유형에 맞게 대응할 수 있게 하는 일입니다. 관련 signal을 실무적으로 살펴보려면 website traffic이 AI agents에서 오는지 확인하는 방법을 읽고, production site에서 이것이 어떻게 보이는지는 websites use case를 확인하세요.

단일 bot score만으로는 충분하지 않은 이유

많은 도구는 이 질문에 숫자 하나로 답합니다. bot score, risk score, 방문자가 얼마나 human한지를 주장하는 percentage입니다. 그 이유는 분명합니다. 숫자 하나는 rule에 넣기 쉽기 때문입니다.

문제는 단일 숫자가 reasoning을 가린다는 점입니다. 점수가 session이 아마 자동화되었다고 말해도, 그 결론이 검증된 signature에 근거하는지, 누구나 복사할 수 있는 user-agent string에 근거하는지, 아니면 빠르게 타이핑하는 사람과도 겹치는 패턴에 근거하는지 팀은 볼 수 없습니다. 그런 score가 block이나 challenge를 유도하면, 설명할 방법도 없이 그 오류를 모두 떠안게 됩니다. 고객, 동료, 감사자에게도 그 이유를 설명할 수 없습니다.

Proof of Actor는 다른 접근을 취합니다. 모든 결과는 Human, AI-assisted or agent: a taxonomy for app traffic에서 설명하는 네 가지 명확한 class 중 하나이며, 모든 결과에는 그 근거가 표시됩니다. 결론과 evidence를 함께 보게 되므로, 강한 결과는 신뢰하고 약한 결과는 검토하며, evidence의 품질에 맞는 policy를 만들 수 있습니다.

웹사이트에서 AI agents를 탐지하는 4단계

이미 갖고 있는 도구만으로도 웹사이트에서 AI agents 탐지를 시작할 수 있습니다. 이 네 단계는 vendor-neutral하며 Proof of Actor 사용 여부와 관계없이 적용할 수 있습니다. 자세한 내용은 website traffic이 AI agents에서 오는지 확인하는 방법 글에서 더 깊이 다룹니다.

자신을 밝히는 agents를 목록화합니다. 서버나 CDN logs에서 AI providers가 공개하는 user agent를 찾으세요. OpenAI는 OAI-SearchBot, GPTBot, ChatGPT-User를 문서화하며, ChatGPT-User는 사용자가 ChatGPT에 질문할 때 페이지를 방문하지 자동으로 crawl하지는 않는다고 밝힙니다. Anthropic은 ClaudeBot, Claude-User, Claude-SearchBot을 문서화합니다. 이렇게 하면 route별 agent traffic의 첫 번째 declared 그림을 얻을 수 있습니다.
문자열을 믿지 말고 주장을 검증합니다. user agent는 자기 보고식이며 쉽게 복사할 수 있습니다. 운영자의 자체 verification method와 대조하세요. Google은 Googlebot에 대해 reverse DNS lookup 뒤에 forward DNS lookup을 하고, 공개된 IP range files도 함께 확인하라고 설명합니다(Google: verifying Googlebot). Bing도 Bingbot에 대해 같은 reverse 및 forward DNS check를 설명합니다(Bing: verifying Bingbot). OpenAI는 각 user agent의 IP range files를 공개합니다. client가 HTTP Message Signatures를 사용해 요청에 서명하는 경우, RFC 9421에 정의된 대로 운영자가 공개한 key와 signature를 대조하세요.
모든 결과에 evidence를 붙이고 Unknown을 유지합니다. 각 결론이 verified, declared, inferred 중 무엇인지 기록하세요. 어떤 verified 또는 declared agent와도 일치하지 않고 명확한 human pattern도 보이지 않는 traffic은 human이나 bot으로 강제로 넣지 말고 Unknown으로 표시해야 합니다. 이 단계가 유용한 보고서와 추측을 가르는 기준입니다.
조치하기 전에 route별로 관찰합니다. 몇 주 동안 public content, signup, account settings, APIs 같은 route와 workflow별로 결과를 나누어 보세요. 그런 다음에야 actor context가 가장 중요한 route에 대해 좁은 policy를 작성하고, Unknown에 대한 명시적 fallback을 두세요.

Proof of Actor는 이 단계를 application 안에서 자동화합니다. 연동이 볼 수 있는 signal을 수집하고, basis가 있는 class를 반환하며, route별 Unknown을 추적하고, policy는 code에 남겨 둡니다.

Proof of Actor가 웹사이트에서 AI agents를 탐지하는 방법

Proof of Actor는 단순한 흐름을 중심으로 설계되었습니다. 연동이 관찰할 수 있는 signal, 명시적인 basis를 가진 분류, 그리고 사용자 손에 남는 decision입니다. 전체 흐름은 How It Works 페이지에서 볼 수 있습니다. 아래는 간단한 요약입니다.

연동에서 오는 signal

각 연동은 허용된 범위 안에서만 보게 됩니다. server-side integration은 request context, protocol details, 그리고 client가 지원할 경우 request signature를 봅니다. browser integration은 실행되는 page에서 interaction signal을 봅니다. application은 AI assistance로 초안을 작성했음을 사용자가 표시한 경우나 agent client가 자신을 명명한 경우처럼 자체 선언도 기록할 수 있습니다.

Proof of Actor는 실제로 존재하는 evidence만 다룹니다. 웹사이트가 볼 수 없는 것을 본다고 가장하지 않습니다.

구체적인 의미를 가진 네 가지 class

모든 상호작용은 네 가지 class 중 하나로 분류됩니다.

Human: 관찰 가능한 signal이 사람 주도의 상호작용을 가리킵니다.
Human + AI: AI assistance가 선언되었거나, 이를 볼 수 있는 지원되는 연동을 통해 관찰되었습니다.
Agent: 자동화되었거나 agent에서 비롯된 상호작용으로, 검증 가능한 identity 또는 신중하게 한정된 inference로 뒷받침됩니다.
Unknown: 사용 가능한 evidence로는 신뢰할 수 있는 판단을 내릴 수 없습니다.

각 class에는 분명한 정의와 한계가 있습니다. Human 결과가 검증된 identity를 뜻하는 것은 아닙니다. Agent 결과가 그 agent가 승인되었다는 뜻도 아닙니다. Unknown 결과는 비난이 아닙니다. 전체 taxonomy는 Detection & Limitations 페이지에서 확인할 수 있습니다.

모든 결과에 붙는 basis

class와 함께 모든 결과에는 basis가 표시됩니다. verified, declared, inferred, unknown입니다. 공개된 key로부터 유효한 signature가 포함된 request는 그 검사를 기준으로 verified입니다. 자신을 agent라고 밝히는 client는 declared입니다. 자동화와 일치하는 행동 패턴은 inference입니다. 이런 구분이 있어야 policy를 정확하게 만들 수 있습니다. 읽기 전용 route의 verified signed agent와 account settings page의 self-declared client를 같은 방식으로 다룰 필요는 없습니다. Proof of Actor에서는 그렇게 할 필요가 없습니다. 각 basis에 대한 자세한 설명은 evidence basis glossary entry에서 확인할 수 있습니다.

팀이 얻는 것: Detect, Understand, Route

Proof of Actor는 함께 작동하는 3가지 capability를 가진 하나의 product입니다.

Detect

연동에서 사용할 수 있는 actor signal을 수집하고, verified assertion과 behavioral inference를 구분합니다. Unknown traffic은 추측으로 묶이지 않고 별도의 category로 계속 보입니다. 어떤 상호작용에 대해 자신 있게 말할 수 있는지, 그리고 어떤 상호작용은 더 많은 evidence가 필요한지 항상 알 수 있습니다.

Understand

맥락 속에서 AI agent traffic을 확인하세요. route와 시간에 따라 interaction type을 탐색하고, human, AI-assisted, agent, unknown activity의 추세를 따라가며, 어떤 분류든 열어 무엇이 알려져 있고 무엇이 알려져 있지 않은지, 그리고 결과가 무엇에 근거하는지 확인할 수 있습니다. 여기서 product, platform, security 팀은 웹사이트를 누가 사용하는지에 대한 공유 가능하고 설명 가능한 그림을 얻게 됩니다.

Route

자체 policy를 사용해 특정 상호작용을 allow, adapt, challenge, review 또는 limit 하세요. 문서를 읽는 verified agent에는 구조화된 response를 제공합니다. 사람이 주도하는 session에는 표준 경험을 유지합니다. 자체 조건이 요구할 때는 민감한 account change에 대해 더 강한 check를 요구할 수 있습니다. Unknown 결과와 timeout에 대해서는 route마다 명시적인 fallback을 정하세요. enforcement는 항상 application 안에서, 팀이 확인한 policy 아래에서 이루어집니다.

웹사이트를 대체하는 것이 아니라 웹사이트에 맞게 설계되었습니다

Proof of Actor는 이미 운영 중인 tool 옆에 자리합니다. authentication, authorization model, 기존 abuse control을 대체하지 않습니다. 대신 그 위에 actor context를 더합니다.

일반적인 website integration은 actor context가 가장 중요한 route에서 시작합니다. agent가 많이 읽는 public content, signup과 onboarding flow, account settings와 다른 민감한 action, 그리고 사이트를 구동하는 모든 API가 그 예입니다. founding team은 우리 engineers와 함께 어떤 route를 우선할지 정하고, 범위에 포함할 signal을 합의하며, 어떤 code도 배포되기 전에 data 처리 방식을 확인합니다.

decision layer가 여러분의 code 안에 있기 때문에 경험을 계속 통제할 수 있습니다. 몇 주 동안은 아무 rule도 바꾸지 않고 internal dashboard에서만 결과를 볼 수 있고, 그다음 한 route에 대해서만 하나의 좁은 policy를 적용한 뒤, 결과가 신뢰를 얻으면 범위를 넓힐 수 있습니다. handling unknown traffic 가이드는 첫 번째 rule을 어떻게 설계할지 안내합니다.

observation mode에서 시작하세요

AI agent 탐지의 가치를 가장 빠르게 얻는 방법은 차단이 아니라 관찰부터 시작하는 것입니다. observation mode에서 Proof of Actor는 결과를 기록하면서도 웹사이트는 그것이 없는 것과 정확히 동일하게 응답합니다. 그러면 팀은 이미 이해하고 있는 결과들, 예를 들면 support ticket, 알려진 integration, 내부 tool, 그리고 이미 알고 있는 crawler와 분류 결과를 비교할 수 있습니다.

이렇게 하면 enforcement 전에 세 가지를 얻습니다.

기준선. route별로 traffic의 어느 정도가 human-directed, AI-assisted, agent-driven, unknown인지 파악할 수 있습니다.
evidence에 대한 확신. 웹사이트에서 어떤 signal이 강한지, 어디에서 coverage를 더 넓혀야 하는지 알 수 있습니다.
더 나은 policy. 실제 pattern을 바탕으로 설계한 rule, 그리고 영향을 받기 전에 검토된 false positive를 갖게 됩니다.

policy가 준비되면 그 policy가 설계된 특정 workflow에만 적용하고, 언제든지 조정할 수 있는 권한은 유지합니다.

불투명한 score보다 evidence 기반 탐지가 더 나은 이유

웹사이트는 이미 agents, assistants, AI와 함께 작업하는 사람들을 나란히 서비스합니다. 이 상황을 잘 다루는 팀은 가장 공격적인 filter를 가진 팀이 아닐 것입니다. 결정을 설명할 수 있는 팀이 될 것입니다.

evidence에 기반한 결과는 그 설명을 제공합니다. 지원 담당자가 사용자가 왜 추가 verification step을 봤는지 묻는다면, 적용된 evidence와 policy를 보여줄 수 있습니다. agent operator가 서명된 요청이 왜 구조화된 response로 제공되었는지 묻는다면, verified basis를 보여줄 수 있습니다. evidence가 충분하지 않을 때는 결과가 Unknown이라고 말하고, fallback은 여러분이 의도적으로 선택한 방식으로 처리됩니다.

이 접근은 web의 확장성과도 잘 맞습니다. 더 많은 agent operator가 요청에 서명하고, IETF Web Bot Auth working group 같은 표준화 작업이 자동화된 client를 위한 cryptographic authentication을 표준화하며 HTTP message signatures 위에 구축될수록, 여러분의 traffic은 inferred 또는 unknown에서 verified로 더 많이 이동하고, policy는 다시 작성하지 않고도 더 정밀해집니다.

founding developer program에 참여하세요

Proof of Actor는 소수의 application 팀과 함께 private beta로 운영 중입니다. 선정된 founding developer는 실사용 피드백을 제공하는 대신, 합의된 사용 한도 내에서 최대 12개월 동안 무료로 접근할 수 있습니다. 우리 engineers로부터 직접 integration 지원을 받고, 기능이 준비되는 대로 조기 접근하며, 다음에 무엇을 만들지에 대해서도 실제로 영향을 줄 수 있습니다.

웹사이트가 사람, AI-assisted 사용자, agents를 모두 서비스하고 있고, 다음에 무엇이 일어날지 결정하기 전에 누가 사용하고 있는지 알고 싶다면 early access를 신청하세요. 웹사이트와 가장 이해하고 싶은 상호작용에 대해 알려 주시면, 현재 beta에 적합한지 검토하겠습니다.

먼저 자세한 내용을 보고 싶으신가요? Proof of Actor를 살펴보거나, how it works를 읽거나, evidence가 무엇을 확립할 수 있고 무엇을 확립할 수 없는지를 정확히 확인해 보세요.

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
OpenAI crawlers 개요, OpenAI.
Anthropic는 web에서 데이터를 크롤링하나요, 그리고 사이트 소유자는 어떻게 crawler를 차단할 수 있나요?, Anthropic.
Googlebot 및 다른 Google crawlers를 검증하는 방법, Google Search Central.
Bingbot이 Bingbot인지 확인하는 방법, Bing Webmaster Blog.

개발자를 위한

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

자주 묻는 질문

웹사이트용 AI 에이전트 탐지는 Proof of Actor와 함께 어떻게 작동하나요?

Proof of Actor는 연동을 통해 사용할 수 있는 요청 서명, 클라이언트 선언, 상호작용 신호 같은 정보를 수집하고, 그 근거가 verified, declared, inferred 또는 unknown인 분류 결과를 반환합니다.

설치하면 방문자가 차단되나요?

아니요. Proof of Actor는 observation mode로 시작합니다. 팀이 결과를 검토하는 동안 웹사이트는 이전과 정확히 동일하게 동작하며, 나중에 어떤 policy를 적용할지 직접 결정할 수 있습니다.

다른 탭에서 AI를 사용했는지도 알 수 있나요?

어떤 웹사이트도 다른 탭이나 다른 기기에서의 활동을 볼 수는 없습니다. Proof of Actor는 지원되는 연동을 통해 AI 사용이 선언되었거나 관찰 가능한 경우에만 이를 보고하며, 그 밖의 것은 설계상 명확하게 유지합니다.

근거가 분명하지 않으면 어떻게 되나요?

결과는 Unknown입니다. Unknown은 기본적으로 Human으로 간주되지도, 악성으로 간주되지도 않는 일급 결과입니다. 각 route에서 이를 어떻게 처리할지는 policy가 결정합니다.

Proof of Actor는 누구를 위해 만들어졌나요?

SaaS 애플리케이션, 웹사이트, APIs, MCP servers를 운영하며, 경험이나 접근 policy를 정하기 전에 누가 또는 무엇이 작동 중인지 이해하고 싶은 팀을 위해 만들어졌습니다.

어떻게 접근 권한을 받나요?

Proof of Actor는 private beta 단계입니다. early access를 신청해 주세요. 선정된 founding developer 팀은 합의된 사용 한도 내에서 최대 12개월 동안 무료로 사용할 수 있습니다.

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

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

조기 접근 받기 가격 보기

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