AI 에이전트 식별

API를 위한 AI 에이전트 식별

귀하의 API는 이미 어떤 key가 request를 만들었는지는 알고 있습니다. Proof of Actor는 그 뒤에 어떤 유형의 actor가 있었는지, 어떤 evidence가 이를 뒷받침하는지 알려주며, 그 다음에 무엇을 할지는 귀하의 code가 결정하게 합니다.

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

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

Your API는 key는 알고 있습니다. actor는 알지 못합니다.

모든 API request는 비용을 부담하는 주체에 대한 어떤 증거와 함께 도착합니다. 예를 들어 API key, OAuth token, session이 그렇습니다. 그 증거는 한 가지 질문에는 잘 답합니다. 어떤 account가 이 호출에 책임이 있는지 알려줍니다. 하지만 지금 실제로 무엇이 호출을 수행하고 있는지는 알려주지 않습니다.

하나의 API key는 terminal에서 테스트하는 developer가 사용할 수도 있고, 일정에 따라 실행되는 backend job이 사용할 수도 있으며, AI assistant를 통해 작업하는 사람이나 key를 넘겨받아 작업을 완료하라는 지시를 받은 autonomous agent가 사용할 수도 있습니다. 이들은 모두 서로 다른 actor입니다. 리듬도 다르고, 실패 양상도 다르고, risk profile도 다릅니다. 이들을 모두 같은 방식으로 다루면 고객이 의존하는 legitimate automation을 지나치게 제한하거나, 사람이 지켜보지 않는 agent가 절대 구동해서는 안 되는 API 영역을 충분히 보호하지 못하게 됩니다.

API를 위한 AI agent 식별은 그 간극을 메웁니다. key만으로 모든 것을 추론하는 대신, 각 request 뒤에 있는 actor의 classification과 이를 뒷받침하는 evidence를 함께 얻습니다. 이것이 Proof of Actor가 제공하도록 설계된 것이며, APIs use case에서는 API team이 이를 route별로 어떻게 적용하는지 보여줍니다.

왜 API team은 지금 actor context가 필요한가

API로 향하는 automated traffic은 새로운 것이 아닙니다. script, integration, crawler는 언제나 그 일부였습니다. 달라진 것은 automation의 종류입니다. AI agent는 documentation을 읽고, call을 이어 붙이고, 창의적으로 retry하고, 모든 단계를 지켜보지 않는 사람을 대신해 행동할 수 있습니다. 그들 중 상당수는 유용하고 환영할 만합니다. 일부는 제대로 만들어지지 않았고, 일부는 적대적입니다.

actor context가 없으면 API team은 대개 거친 도구로 돌아가게 됩니다.

key별 rate limit, good agent와 bad agent를 똑같이 느리게 만듭니다.
user-agent rule, client가 header를 바꾸는 순간 깨집니다.
전체 차단, legitimate automation이 대신 web app을 scraping하도록 밀어붙입니다.

actor context를 사용하면 정밀하게 대응할 수 있습니다. 귀하가 알고 있는 operator의 signed agent는 read route에서 더 높은 limit을 받을 수 있습니다. write route를 건드리는 unknown caller는 더 강한 credential을 요구받을 수 있습니다. AI assistant를 사용하는 human은 평소와 같은 경험을 유지할 수 있습니다. 핵심은 agent를 막는 것이 아닙니다. 각 종류의 caller에게 적절한 경로를 주는 것입니다. signed request가 무엇을 알려주고 무엇을 알려주지 않는지에 대해서는 signed AI agent requests가 무엇을 증명하는지를 읽어보세요.

Proof of Actor에서 AI agent 식별은 어떻게 작동하는가

Proof of Actor는 모든 request에 대해 동일한 evidence-first 흐름을 따릅니다. 전체 설명은 How It Works에서 볼 수 있으며, 여기서는 API team을 위한 짧은 버전만 소개합니다.

1. integration에서 오는 signals

귀하의 integration은 그 상황에서 사용 가능한 signals를 Proof of Actor에 전달합니다. API의 경우 일반적으로 header와 protocol 세부 정보 같은 request context, client가 제공하는 cryptographic request signature, 그리고 client가 자신에 대해 밝히는 declaration이 포함됩니다. 각 signal에는 어디에서 왔는지 라벨이 붙습니다.

2. 근거가 있는 classification

signals는 검사되고 결합되어 다음 네 가지 public class 중 하나가 됩니다.

Human: 관찰 가능한 signals가 human-directed interaction을 나타냅니다.
Human + AI: AI assistance가 선언되었거나, 이를 관찰할 수 있는 integration에서 감지되었습니다.
Agent: 검증 가능한 identity 또는 신중하게 한정된 inference로 뒷받침되는 automated 또는 agent-origin traffic입니다.
Unknown: evidence가 신뢰할 수 있는 판단을 뒷받침하지 않습니다.

모든 결과에는 basis도 함께 표시됩니다. verified, declared, inferred, unknown입니다. 이것이 API team이 가장 중요하게 여기는 부분입니다. RFC 9421에 정의된 HTTP message signature가 공개된 key와 대조해 검증되면 verified로 보고됩니다. client가 단순히 자신을 agent라고 명시하면 declared로 보고됩니다. 자동화처럼 보이는 pattern은 inferred로 보고됩니다. 결과가 cryptography에 근거하는지, 아니면 heuristic에 근거하는지 추측할 필요가 없습니다. evidence basis는 답의 일부입니다.

3. code가 작동시킬 수 있는 result

result는 class, basis, 읽을 수 있는 evidence summary와 함께 application으로 반환됩니다. 무엇을 할지는 code가 결정합니다. observation mode에서는 단순히 기록합니다. 준비가 되면 그 결과를 기준으로 route를 정합니다.

팀이 얻는 것: Detect, Understand, Route

Proof of Actor는 하나의 product에 세 가지 capability가 있습니다.

Detect

API가 볼 수 있는 actor signals를 수집하고 verified assertion과 behavioral inference를 분리합니다. signed agent request, declared client, automation signal, Unknown result는 모두 분리되어 유지되므로, 아무것도 조용히 하나의 score로 합쳐지지 않습니다.

Understand

어떤 actor가 어떤 route를 호출하는지, 시간이 지나며 그것이 어떻게 변하는지, 그리고 각 classification 뒤에 어떤 evidence가 있는지 확인할 수 있습니다. unknown rate도 계속 보이므로, coverage의 끝이 어디인지와 더 강한 signal이 어디에서 도움이 되는지를 정확히 알 수 있습니다.

Route

route와 risk tier별로 policy를 작성하세요. allow, adapt, challenge, review 또는 rate-limit을 사용할 수 있습니다. read-only endpoint의 verified agent에는 구조화되고 관대한 path를 유지하세요. 영향이 큰 operation에서는 더 강한 credential을 요구하세요. Unknown과 timeout에 대한 명시적 fallback을 정의해, 무슨 일이 있어도 API가 예측 가능하게 동작하도록 하세요. 각 policy가 open으로 실패할지 closed로 실패할지는, 해당 route에서 실수의 비용을 기준으로 직접 결정합니다.

identity evidence, credential, authorization은 서로 다른 세 가지입니다

agent-aware API 설계에서 가장 흔한 실수는 서로 다른 세 질문을 하나로 합치는 것입니다. Proof of Actor는 이를 분리해서 유지하며, 귀하의 설계도 그래야 합니다.

identity evidence: 어떤 종류의 actor가 호출하고 있으며, 그것을 무엇이 증명하는가? 이것이 AI agent 식별이 제공합니다. verified signature는 request를 key와 그 공개된 operator identifier에 연결합니다. IETF Web Bot Auth working group은 이런 종류의 automated client용 cryptographic authentication을 표준화하도록 charter를 받았으며, 그 범위는 end user가 아니라 agent를 인증하는 데 있습니다.
credential: 이 호출에 대해 어떤 account가 책임을 지는가? 이것이 귀하의 API key, token 또는 session이며, 귀하가 발급하고 관리합니다.
authorization: 이 caller가 이 특정 작업을 해도 되는가? 이것이 귀하의 permission model입니다.

verified agent가 곧바로 authorized agent가 되는 것은 아닙니다. valid signature가 사람이 agent에게 authority를 위임했다는 것을 증명하지도 않으며, 요청된 action이 안전하다는 뜻도 아닙니다. Proof of Actor는 첫 번째 질문에 대해 신뢰할 수 있는 context를 제공하고, 두 번째와 세 번째는 원래 있어야 할 위치, 즉 귀하의 application에 남겨 둡니다. agent authorization과 evidence가 무엇을 establish할 수 있고 무엇을 establish할 수 없는지에 대해서는 Detection & Limitations에서 더 읽어보세요.

Unknown은 실패가 아니라 기능입니다

request signing은 선택 사항이며, unsigned client는 원하는 대로 자신을 설명할 수 있습니다. 모든 request를 Human 또는 Agent로 강제로 넣는 system은 때때로 자신 있게 틀릴 것이고, 언제 그런 일이 일어났는지도 알 수 없습니다.

Proof of Actor는 evidence가 판단을 뒷받침하지 않을 때 Unknown을 보고합니다. Unknown은 결코 Human으로 바뀌지 않으며, 기본값으로 악의적이라고 간주되지도 않습니다. 귀하의 policy는 route별로 Unknown이 무엇을 의미하는지 정의합니다. public read에는 허용하고, account 변경에는 기존 checks를 유지하고, 위험이 큰 곳에서는 review 대기열에 넣을 수 있습니다. Unknown을 보이게 유지하는 것이 다른 classification을 신뢰할 수 있게 만드는 핵심입니다. unknown traffic 처리하기 가이드는 이를 어떻게 설계할지 보여줍니다.

AI agent 식별이 스택에서 들어가는 위치

Proof of Actor는 기존 gateway, authentication, rate limiting과 나란히 배치됩니다. 이들을 대체하지 않습니다. 일반적인 배치 방식은 다음과 같습니다.

server-side middleware를 route handler 앞에 두어, business logic가 실행되기 전에 모든 request를 평가합니다.
edge에서, request가 origin에 도달하기 전에 signals를 평가합니다.
generic HTTP integration을 사용해 어떤 stack이든 request context를 보내고 basis가 포함된 result를 받을 수 있게 합니다.

integration은 onboarding 동안 각 founding team과 함께 직접 제공되므로, path는 귀하의 architecture에 맞춰집니다. 반대로 귀하의 architecture가 제품에 맞춰질 필요는 없습니다. developer hub에서는 현재 사용 가능한 integration path를 보여줍니다. agent용 도구를 운영한다면 MCP Servers use case에서 tool call에 대한 구체적인 pattern을 다룹니다.

observation mode로 시작하세요

Proof of Actor를 설치해도 API의 응답 방식은 바뀌지 않습니다. result는 기록되므로 팀은 이를 이미 알고 있는 outcome과 비교하고, agent가 실제로 어디로 가는지 확인하며, 각 route의 unknown rate를 측정하고, 잘못된 것처럼 보이는 classification을 검토할 수 있습니다. 그런 다음에야 evidence가 뒷받침하는 route별 policy를 활성화합니다.

이렇게 해야 고객을 놀라게 하거나, 그들이 의존하는 integration을 깨지 않으면서 AI agent 식별을 도입할 수 있습니다. actor-aware policy를 안전하게 rollout하는 방법 가이드가 그 순서를 단계별로 설명합니다.

founding developer program에 참여하세요

Proof of Actor는 소규모 founding development team과 함께 private beta 상태입니다. 선정된 team은 onboarding 중 합의한 usage limit 내에서 최대 12개월 무료 access를 받을 수 있으며, 엔지니어의 직접적인 integration 지원과 앞으로 우리가 무엇을 만들지에 대한 실제 영향력도 함께 얻습니다.

API를 운영하고 있고 누가 실제로 호출하는지 알고 싶다면 early access를 신청하세요. 귀하의 API, 가장 중요한 route, 그리고 actor context가 있다면 다르게 내릴 결정에 대해 알려주세요. 그러면 Proof of Actor가 어떻게 맞는지 설명드리겠습니다.

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.

개발자를 위한

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 에이전트 식별은 API key authentication과 어떻게 다릅니까?

API key는 어떤 account가 request를 보냈는지 알려줍니다. AI 에이전트 식별은 request 뒤에 어떤 종류의 actor가 있는지, 그리고 그 결론을 어떤 evidence가 뒷받침하는지 알려줍니다. 두 가지 모두 필요하며, 서로 다른 질문에 답합니다.

Proof of Actor는 내 API를 호출하는 모든 AI agent를 식별할 수 있습니까?

Proof of Actor는 자신이 보는 모든 request를 Human, Human + AI, Agent 또는 Unknown으로 분류하고, 각 결과의 근거를 명시합니다. evidence가 충분히 강하지 않으면 추측 대신 Unknown으로 표시합니다.

agent를 식별한다는 것은 그 agent가 행동할 수 있다는 뜻입니까?

아닙니다. identification과 authorization은 별개입니다. Proof of Actor는 caller에 대한 context를 application에 제공하고, 실제로 무엇을 할 수 있는지는 귀하의 authorization rule이 결정합니다.

Proof of Actor가 내 API 요청을 차단합니까?

귀하가 그렇게 결정하지 않는 한 그렇지 않습니다. 모든 integration은 observation mode로 시작하며, enforcement는 팀이 작성하고 활성화한 policy를 통해서만 이루어집니다.

어떻게 access를 얻을 수 있습니까?

Proof of Actor는 private beta 상태입니다. early access를 신청할 수 있으며, 선정된 founding developer team은 합의된 usage limit 내에서 최대 12개월 무료로 이용할 수 있습니다.

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

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

조기 접근 받기 가격 보기

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