비교

Proof of Actor vs API 봇 방어: 키는 누가 비용을 내는지 말하고, actor context는 누가 동작하는지 말합니다

API 게이트웨이, WAF 봇 규칙, API 키, 속도 제한은 API의 가용성과 책임성을 지켜 줍니다. 하지만 이들은 요청이 앱 안의 사람에게서 왔는지, AI 비서를 사용하는 사람에게서 왔는지, 아니면 자율 에이전트에게서 왔는지를 알려 주도록 설계되지 않았습니다. 여기서는 API를 위한 봇 관리가 Proof of Actor와 어떻게 다른지, 그리고 두 방식이 어떻게 함께 맞물리는지 설명합니다.

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

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

API에는 한때 단순한 트래픽 모델이 있었습니다. 개발자가 등록하고, 키를 받은 뒤, 통합을 만들고, 그 통합이 일정에 따라 또는 사용자가 무언가를 클릭할 때 엔드포인트를 호출했습니다. API를 위한 봇 관리는 바로 그 모델을 중심으로 발전했습니다. 키를 인증하고, 트래픽 양을 제한하고, 분명히 악성인 트래픽을 걸러 내고, 나머지 사용자를 위해 서비스를 가용하게 유지하는 방식입니다.

그 모델은 여전히 유효하고, 그를 위해 만들어진 도구들도 여전히 중요합니다. 달라진 것은 호출 뒤에 누가 있느냐입니다. 같은 API 키가 이제는 고객의 앱을 사용하는 사람, 작업을 대신 시켜 달라고 AI 비서에게 요청한 사람, 밤새 여러 단계를 수행하는 자율 에이전트의 요청을 모두 담을 수 있습니다. 기존 제어는 키 하나와 요청 속도 하나만 봅니다. 하지만 제품, 지원, 정책 결정에는 종종 더 많은 정보가 필요합니다.

Proof of Actor는 그 간극을 메웁니다. 각 요청에서 누가 또는 무엇이 행동하는지 API에 알려 주고, 근거를 제시한 뒤, 결정은 코드에 맡깁니다. 이 페이지에서는 Proof of Actor가 API 봇 방어의 주요 계층과 어떻게 다른지 비교하여, 각 계층이 어디에 적합한지 보여 줍니다.

짧은 요약

	API 봇 방어	Proof of Actor
핵심 질문	이 요청은 허용되며, 인증되었고, 제한 범위 안에 있는가?	누가 또는 무엇이 행동하고 있으며, 근거는 무엇인가?
일반적인 계층	API 게이트웨이, WAF 봇 규칙, API 키, 속도 제한	API 또는 MCP server 내부의 actor classification
식별 대상	키를 소유한 계정 또는 통합	각 요청 뒤의 actor: Human, Human + AI, Agent 또는 Unknown
출력	허용, 거부, 제한, 때로는 봇 점수	class와 basis: verified, declared, inferred 또는 unknown
불명확한 트래픽	대개 키가 유효하면 허용되거나, 규칙으로 거부됨	Unknown, 경로별로 선택하는 fallback 포함
응답을 결정하는 주체	게이트웨이와 WAF 설정	애플리케이션 코드
설치 직후 기본값	강제 집행	관찰; 정책을 추가하기 전까지는 아무 것도 바뀌지 않음
가장 적합한 용도	가용성, 악용 필터링, 할당량, 책임성	각 actor에 맞게 응답하고 API 사용을 이해하는 일

아래 섹션에서 각 부분을 설명합니다.

API 봇 방어가 잘하는 것

각 계층이 맡는 역할을 구체적으로 보는 것이 중요합니다. Proof of Actor는 이들 옆에 자리하도록 설계되었지, 어떤 것도 대체하도록 설계된 것은 아니기 때문입니다.

API 게이트웨이

게이트웨이는 API의 정문입니다. 연결을 종료하고, API 키 또는 토큰을 인증하며, 요청을 올바른 서비스로 라우팅하고, 할당량을 강제하며, 종종 과금과 분석을 위해 사용량을 기록합니다. 각 엔드포인트 전체에 걸쳐 일관되게 "이 호출자는 들어올 수 있는가, 그리고 어느 문으로 들어와야 하는가?"에 답합니다.

WAF 봇 규칙

봇 규칙이 있는 웹 애플리케이션 방화벽은 알려진 공격 패턴과 악성 자동화를 가진 트래픽을 검사합니다. 주입 시도를 걸러 내고, 악용 이력이 있는 출처의 트래픽을 차단하며, 스크래핑이나 자격 증명 공격처럼 보이는 요청에 챌린지를 주거나 드롭할 수 있습니다. 코드에 도달해서는 안 되는 트래픽에 대한 가장 강력한 방어 수단입니다.

API 키와 토큰

키와 토큰은 책임성을 제공합니다. 모든 요청이 계정에 연결되므로, 어떤 통합이 호출했는지 알 수 있고, 접근을 취소할 수 있으며, 사용량을 귀속할 수 있습니다. 범위가 제한된 토큰은 여기에 더해 호출자가 할 수 있는 일도 제한합니다.

속도 제한

속도 제한은 가용성을 지킵니다. 하나의 통합이 모두를 위해 남겨 둔 용량을 소모하지 못하게 하고, 무차별 대입과 열거 시도를 늦춥니다. 키별, 경로별 제한은 표준적이고 효과적인 제어입니다.

이 계층들은 함께 보호와 책임성에 관한 질문에 매우 잘 답합니다. 그대로 유지하세요.

이 계층들이 답하도록 만들어지지 않은 질문

이 계층들 중 어느 것도 인증된 요청 뒤에 있는 어떤 종류의 actor인지 알려 주도록 설계되지 않았습니다. 유효한 키는 어떤 계정이 통합을 소유하는지만 말합니다. 다음은 말해 주지 않습니다.

이 특정 호출이 고객의 앱에서 버튼을 누른 사람에게서 왔는지,
사람이 AI 비서에게 작업을 시키도록 요청한 것인지,
자율 에이전트가 더 긴 작업의 한 단계로 호출했는지,
아니면 아무도 판단할 수 없는지.

이 구분은 매달 더 중요해집니다. CRM 통합, 일정 관리 도구, 개발자 플랫폼을 제공하는 API는 점점 더 사람 중심 앱에 사용되는 것과 같은 키를 통해 에이전트 트래픽을 받습니다. 에이전트에게 구조화된 응답을 주고 싶거나, 에이전트가 수행한 영향이 큰 쓰기에 대해 확인을 요구하거나, AI 보조 제출을 표시하거나, 단순히 API 사용량 중 에이전트 비율을 측정하려면 actor context가 필요합니다.

Proof of Actor가 API에 더하는 것

Proof of Actor는 각 상호작용마다 네 가지 class 중 하나를 반환합니다.

Human: 관측 가능한 신호가 사람 주도의 상호작용을 가리킵니다.
Human + AI: 사람이 AI 지원과 함께 상호작용을 주도했고, 그 사실이 지원되는 통합을 통해 선언되었거나 관찰되었습니다.
Agent: 자동화되었거나 에이전트에서 비롯된 상호작용입니다.
Unknown: 근거가 신뢰할 수 있는 판단을 뒷받침하지 못합니다.

모든 결과에는 evidence basis도 함께 표시됩니다.

Verified: 예를 들어 공개 키로 확인된 HTTP Message Signature (RFC 9421).
Declared: 클라이언트 또는 자체 애플리케이션이 그렇게 명시함.
Inferred: 행동적 또는 맥락적 신호를 기반으로 하되, 추론임이 명확히 표시됨.
Unknown: 신뢰할 수 있는 basis가 없음.

API에서는 verified basis가 특히 유용합니다. 서명된 요청을 보내는 에이전트는 공개된 키와 대조해 확인할 수 있으며, 이것이 IETF Web Bot Auth 작업의 기반입니다. 배경은 제품 팀을 위한 Web Bot Auth 해설에서, 구현 측면은 서명된 에이전트 요청 검증 가이드에서 확인할 수 있습니다.

여기서 중요한 한계가 하나 있습니다. 유효한 서명은 어느 키가 요청에 서명했는지만 증명합니다. 그 에이전트가 행동할 권한이 있다는 것까지 증명하지는 않습니다. 권한 부여는 API의 고유한 접근 제어에 그대로 남아 있어야 합니다. 에이전트 권한 부여 항목이 이 차이를 설명합니다.

점수와 키, 그리고 actor evidence

일부 봇 방어 제품은 각 요청에 점수를 붙입니다. 점수는 차단 결정을 내릴 때 효율적입니다. 하지만 정당한 요청이 사람 주도인지 에이전트 주도인지 알려 주지 못하고, 검증된 사실과 추론을 구분하지 못하므로 API 제품 결정에는 덜 유용합니다.

API 키는 반대의 한계를 가집니다. 소유권에 대해서는 정확하지만 actor에 대해서는 침묵합니다. 한 고객의 키가 한 시간 안에 네 가지 class를 모두 담을 수 있습니다.

Proof of Actor는 이 두 구분을 모두 보이게 유지합니다. API는 키에서 나온 계정, Proof of Actor에서 나온 actor class, 그리고 그것을 뒷받침하는 basis를 봅니다. 각 계층은 자신이 잘하는 질문에 답합니다.

각각 어디에서 실행되는가

게이트웨이와 WAF는 네트워크의 가장자리 또는 서비스 앞단에서 실행됩니다. 그 위치는 보호와 할당량에 적합합니다.

Proof of Actor는 API 로직이 있는 곳에서 실행됩니다. Founding 팀은 Node.js 미들웨어, Next.js, 직접 제어하는 엣지 계층, 일반 HTTP API, 또는 MCP server 통합을 통해 연동할 수 있습니다. 전체 목록은 통합을 참고하세요. 애플리케이션 내부에서 실행되기 때문에 API가 아는 정보, 즉 경로, 워크플로, 클라이언트가 스스로를 선언했는지, 서명이 검증되었는지 등을 사용할 수 있습니다.

라우팅 결정은 코드 안에 남습니다

Proof of Actor는 기본적으로 아무 것도 차단하지 않습니다. 관찰 모드로 시작하므로 설치한다고 해서 API의 응답 방식이 바뀌지는 않습니다. 엔드포인트별 actor 구성 비율을 보고, 개별 결과의 근거를 검토하며, Unknown 비율을 추적할 수 있습니다.

준비가 되면 경로별, actor class별, basis별로 애플리케이션이 정의한 정책을 작성합니다. 일반적인 결과는 다음과 같습니다.

Allow: 요청을 정상적으로 처리합니다.
Adapt: 검증된 에이전트에게 구조화되었거나 축소된 응답을 반환합니다.
Challenge: 추가 확인 단계를 요구합니다. 예를 들어 영향이 큰 쓰기 작업에 대해 사람 승인을 요구할 수 있습니다.
Review: 사람이 확인하도록 작업을 대기열에 넣습니다.
Rate-limit: 특정 경로에서 특정 class와 basis에 더 엄격한 제한을 적용합니다.

실제 트래픽에 대해 정책을 미리 확인한 뒤 강제 집행할 수 있으며, 이후 경로별로 적용할 수 있습니다. actor-aware 정책을 안전하게 출시하기 가이드가 이 과정을 다루고, 에이전트를 차단하지 않고 민감한 작업을 보호하기가 일반적인 패턴을 보여 줍니다.

분류할 수 없는 API 호출자 처리하기

모든 API는 자신 있게 분류할 수 없는 트래픽을 받습니다. 기존 제어에서는 유효한 키면 대개 통과, 유효하지 않으면 차단입니다. 그 중간은 없습니다.

Proof of Actor는 명시적인 Unknown 결과를 제공하고, 경로별 fallback을 선택하게 합니다. 읽기 전용 카탈로그 엔드포인트는 그대로 열어 둘 수 있습니다. 계정 변경은 기존의 더 엄격한 검사를 유지할 수 있습니다. 대량 내보내기는 검토로 보낼 수 있습니다. 자세한 내용은 Unknown 트래픽 처리와 알 수 없는 자동화 트래픽을 참고하세요.

함께 작동하는 방식

가장 강력한 API 구성은 각 계층을 제 역할에 맞게 사용하는 것입니다.

엣지에서 WAF가 악성 및 비정상 트래픽을 필터링합니다.
게이트웨이에서 키를 인증하고, 할당량을 강제하며, 사용량을 기록합니다.
API 내부에서 Proof of Actor가 통과한 각 요청을 분류하고 basis를 표시합니다.
핸들러 안에서 정책이 class와 basis를 사용해 응답을 선택합니다. 사람 주도 호출에는 정상 처리, 검증된 에이전트에는 구조화된 응답, 에이전트 주도 영향이 큰 쓰기에는 확인 단계, Unknown에는 fallback을 사용합니다.
분석에서는 팀이 어떤 엔드포인트와 워크플로를 각 actor class가 사용하는지, 그리고 게이트웨이의 계정 데이터와 함께 볼 수 있습니다.

이 스택에는 중복이 없습니다. 게이트웨이는 계정을 알고, WAF는 위협 패턴을 알며, Proof of Actor는 actor를 압니다.

무엇에 언제 집중할 것인가

주요 문제가 악용, 가용성, 또는 비과금 사용이라면 먼저 API 봇 방어에 집중하세요. 예를 들어 인증 엔드포인트에 대한 자격 증명 공격, 과도한 스크래핑, 또는 한 통합이 다른 통합의 자원을 소진하는 상황입니다.

주요 질문이 호출자에 관한 것이라면 Proof of Actor에 집중하세요. API 트래픽 중 에이전트가 차지하는 비율은 어느 정도인지, 어떤 에이전트가 어떤 엔드포인트를 호출하는지, 사람 주도 사용과 에이전트 주도 사용은 어디서 다른지, 어떤 경로에 actor-aware 정책이 필요한지와 같은 질문입니다. API 사용 사례와 API를 위한 AI 에이전트 식별에서 더 자세히 다룹니다.

운영 중인 API를 가진 대부분의 팀은 두 가지 모두에 대한 답이 필요합니다.

시작하기

Proof of Actor는 private beta 상태입니다. 선택된 founding developer 팀은 합의된 사용 한도 내에서 최대 12개월 동안 무료로 이용할 수 있으며, 자동 과금은 없습니다. 조기 접근 신청을 통해 어떤 API와 어떤 호출자를 이해하고 싶은지 알려 주세요.

개발자를 위한

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가 제 API 게이트웨이나 WAF를 대체하나요?

아니요. 게이트웨이는 여전히 키를 인증하고 할당량을 강제하며, WAF는 여전히 악성 트래픽을 필터링합니다. Proof of Actor는 API 내부에서 동작하면서 통과한 요청에 actor context를 더합니다. 기존 제어는 그대로 유지하세요.

모든 호출자에게 API 키가 있다면 왜 actor context가 필요한가요?

API 키는 통합을 소유한 계정을 식별합니다. 하지만 특정 요청이 고객의 앱에서 버튼을 누른 사람에 의해 발생했는지, AI 비서를 사용한 사람에 의해 발생했는지, 아니면 자율 에이전트가 작업을 수행한 것인지는 알려 주지 않습니다. Proof of Actor는 그 내용을 근거와 함께 보고합니다.

Proof of Actor가 제 API를 호출하는 어떤 에이전트인지 확인할 수 있나요?

클라이언트가 HTTP Message Signatures (RFC 9421)로 요청에 서명하고 공개 키를 게시하면, Proof of Actor가 서명을 확인하고 verified basis를 보고합니다. 유효한 서명은 어느 키가 요청에 서명했는지를 증명합니다. 그러나 그 에이전트가 행동할 권한이 있는지는 증명하지 않으므로, 권한 부여는 여전히 코드 안에 남아 있습니다.

Proof of Actor가 제 API 트래픽에 속도 제한을 시작하거나 차단을 시작하나요?

아니요. 기본값은 관찰 모드이며, 아무 것도 차단하지 않습니다. 속도 제한은 정책에서 선택할 수 있는 결과 중 하나로, 경로별, actor class별, basis별로 적용할 수 있으며, 강제는 고객의 코드 안에서 이루어집니다.

API에 Proof of Actor를 어떻게 추가하나요?

Founding 팀은 Node.js 미들웨어, Next.js, 직접 제어하는 엣지 통합, 일반 HTTP API를 사용할 수 있습니다. MCP server도 자체 통합이 있습니다. 자세한 내용은 통합 페이지를 참고하세요.

분류할 수 없는 호출자는 어떻게 되나요?

그들은 Unknown으로 보고되며, 이는 1급 결과입니다. 경로별 기본 동작을 직접 선택할 수 있습니다. 예를 들어 읽기 전용 엔드포인트는 허용하고, 쓰기 엔드포인트는 더 엄격한 검사를 유지할 수 있습니다.

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

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

조기 접근 받기 가격 보기

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