MCP 호출자 식별

누가 당신의 MCP 서버를 호출하는지 파악하세요

당신의 MCP server는 당신이 통제하지 않는 AI 클라이언트에 도구를 노출합니다. Proof of Actor는 각 호출 뒤에 무엇이 있는지, 어떤 근거가 그것을 뒷받침하는지 알려주고, 도구별 정책을 설정할 수 있게 합니다.

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

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

당신의 도구는 볼 수 없는 호출자에게 열려 있습니다

<1>MCP server</1>는 당신의 제품을 AI 클라이언트가 사용할 수 있게 합니다. 사용 가능한 도구, 리소스, prompt를 노출하며, Model Context Protocol specification에 설명된 대로 host, client, server 사이에서 JSON-RPC 2.0 메시지를 사용해 assistant와 agent가 발견하고 호출할 수 있게 합니다. 팀이 이것을 만드는 이유도 바로 여기에 있습니다. AI agent가 이미 일하고 있는 workflow 안에 당신의 제품을 넣을 수 있기 때문입니다.

하지만 이는 당신이 만들지 않았고 직접 관찰할 수 없는 client로부터 호출을 받는다는 뜻이기도 합니다. 하나의 도구는 로컬에서 테스트하는 developer, 로그인한 사람을 대신해 동작하는 desktop assistant, 밤새 긴 작업을 수행하는 autonomous agent, 또는 취약점을 찾기 위해 server를 탐색하는 어떤 대상에 의해 호출될 수 있습니다. protocol은 어떤 tool이 호출되었는지와 어떤 arguments가 전달되었는지는 알려줍니다. 그러나 그 자체만으로는 호출 뒤에 어떤 종류의 actor가 있는지, 혹은 얼마나 신뢰해야 하는지는 알려주지 않습니다.

MCP server 호출자 식별은 그 공백을 메웁니다. Proof of Actor는 각 tool call에 근거가 있는 actor 결과를 더해, server가 누구에게 무엇을 줄지에 대해 정보에 기반한 결정을 내릴 수 있게 합니다. 문제를 더 깊이 보려면 누가 당신의 MCP server를 호출하는가를 읽고, 팀이 이를 어떻게 적용하는지 보려면 MCP server use case를 확인하세요.

용어에 대한 주의. "Caller identity"는 cloud infrastructure에서도 널리 쓰이는 뜻이 있습니다. 예를 들어 AWS STS GetCallerIdentity는 해당 operation을 호출하는 데 사용된 credentials의 IAM user나 role에 대한 세부 정보를 반환합니다. 이는 어떤 cloud credential이 호출을 했는지를 답합니다. 이 페이지의 MCP server 호출자 식별은 다른 질문에 답합니다. 즉, 당신의 MCP server에 대한 tool call 뒤에 있는 actor가 Human, Human + AI, Agent, Unknown 중 무엇인지, 그리고 그 답을 어떤 evidence가 뒷받침하는지입니다.

MCP caller가 다른 이유

MCP caller는 정책 측면에서 중요한 점에서 browser 방문자나 전통적인 API client와 다릅니다.

거의 항상 자동화되어 있습니다. 질문은 "사람인가 bot인가?"보다 "어떤 agent가, 어떤 방식으로, 어떤 evidence를 가지고 작동하는가?"에 가깝습니다.
대개 사람을 대신해 동작합니다. assistant는 사용자가 시켜서 도구를 호출할 수도 있고, 자율적으로 동작할 수도 있습니다. 이 경우는 서로 다른 방식으로 다뤄야 합니다.
자기 자신을 설명합니다. MCP lifecycle specification에서는 client가 clientInfo object에 name과 version을 담아 initialize request로 보냅니다. 그 선언은 유용한 context이지만, proof는 아닙니다.
도구마다 영향도가 크게 다릅니다. 검색 도구와 레코드를 삭제하는 도구가 같은 policy를 가져서는 안 됩니다.

좋은 MCP caller 식별은 이 네 가지를 모두 존중해야 합니다.

Proof of Actor가 MCP caller를 식별하는 방식

서버에서 오는 signals

당신의 MCP integration은 각 호출에 대해 사용 가능한 context를 Proof of Actor에 전달합니다. 여기에는 client가 선언한 세부 정보, transport와 request context, client가 제공하는 암호학적 request signature, 예를 들어 RFC 9421에서 정의한 HTTP Message Signatures, 그리고 호출되는 tool이 포함됩니다. 각 signal에는 그 출처가 표시됩니다.

근거가 있는 분류

Proof of Actor는 결과의 basis와 함께 Human, Human + AI, Agent, Unknown 중 하나를 반환합니다.

verified - 요청 signature가 공개된 key에 대해 통과한 경우
declared - client나 application이 그렇게 밝힌 경우, 예를 들어 session의 client name
inferred - 호출 패턴에 근거한 경우
unknown - evidence가 판단을 뒷받침하지 못하는 경우

선언된 client name은 절대 verification으로 제시되지 않습니다. evidence가 약할 때는 자신 있는 추측 대신 Unknown이 반환되며, server는 자신이 무엇을 다루고 있는지 정확히 알 수 있습니다.

도구가 사용할 수 있는 결과

actor 결과는 tool call과 함께 도착하며, server의 logic이 바로 사용할 수 있는 상태로 전달됩니다. observation mode에서는 이를 기록합니다. 준비가 되면 tool-level policy가 이를 기준으로 동작합니다.

당신의 팀이 얻는 것: Detect, Understand, Route

Detect

모든 tool call에서 사용 가능한 caller evidence를 수집하고, verified, declared, inferred evidence를 분리해 유지합니다.

Understand

어떤 client가 어떤 tool을 얼마나 자주, 어떤 evidence와 함께 호출하는지, 그리고 그것이 시간이 지나며 어떻게 변하는지 확인합니다. 대부분 Unknown caller를 끌어들이는 tool, behavior가 바뀌는 client, 그리고 검증 가능한 identity를 포함하는 호출의 비중을 파악합니다.

Route

tool과 risk tier별로 policy를 작성합니다. 일반적인 패턴은 다음과 같습니다.

Low-impact tools 예를 들어 search나 read-only lookup: 표준 rate limit과 함께 넓게 allow
Moderate-impact tools 예를 들어 draft 생성: verified 및 declared caller는 allow, Unknown은 rate-limit
High-impact tools 예를 들어 data 삭제, setting 변경, 사용자를 대신한 message 전송: 가장 강한 authorization을 요구하고, caller가 Unknown이거나 autonomous하게 동작할 때는 confirmation 또는 review를 추가

민감한 action을 agent를 막지 않고 보호하는 방법 가이드는 이러한 tier를 설계하는 방법을 보여줍니다.

identity evidence, credentials, authorization은 서로 다릅니다

MCP security는 다음 세 가지 질문을 분리해 둘 때 가장 잘 작동합니다.

Identity evidence: 어떤 종류의 client가 호출하고 있으며, 그것을 무엇이 증명하는가? Proof of Actor가 이를 제공합니다.
Credentials: 이 호출은 어떤 account나 token으로 이루어졌는가? 이것은 당신의 MCP server authentication이 제공합니다. MCP authorization specification은 authorization을 선택 사항으로 두며, HTTP 기반 transport의 경우 OAuth 2.1에 기반하고, MCP server가 access token을 검증하는 resource server 역할을 하도록 합니다.
Authorization: 이 caller가 이 tool을, 이 arguments로, 이 account에 대해 사용해도 되는가? 이것은 당신의 permission model이 제공합니다.

인정된 client가 곧바로 authorized된 것은 아닙니다. 유효한 signature가 session 뒤에 있는 사람이 이 특정 action에 대해 권한을 위임했음을 보여주지는 않습니다. delegated authority와 agent authorization에 대해 더 읽어보세요. Proof of Actor는 첫 번째 질문에 대해 server에 더 나은 context를 제공하고, 그 결과 두 번째와 세 번째에 대한 답이 더 잘 informed되도록 합니다.

왜 client name만 믿지 않나요?

어떤 client도 어떤 name이든 보낼 수 있기 때문입니다. 선언된 name을 proof로 취급하면 모방을 부릅니다. 악의적인 client는 인기 있는 assistant의 name을 복사하기만 하면 됩니다. Proof of Actor는 name을 declared evidence로 기록하고, 존재하는 더 강한 evidence와 결합해 basis를 알려줍니다. 그러면 policy는 verified caller에게 단순히 자신을 그렇게 선언한 caller보다 더 많은 권한을 줄 수 있고, 둘 다 해당하지 않을 때는 Unknown fallback을 적용할 수 있습니다.

observation mode에서 시작하세요

당신의 MCP server에 Proof of Actor를 설치해도 어떤 tool의 응답 방식도 바뀌지 않습니다. 결과는 기록되며, 누가 당신의 tool을 호출하는지, evidence가 얼마나 강한지, 그리고 policy가 어디에서 도움이 되는지 확인할 수 있습니다. 자신이 생기면 영향이 큰 하나의 tool에 policy를 활성화하고 결과를 지켜본 뒤 확장하세요. How It Works가 전체 흐름을 다루며, Detection & Limitations는 각 evidence가 무엇을 확립할 수 있고 무엇은 확립할 수 없는지 설명합니다.

MCP servers와 APIs를 운영하는 팀을 위해 설계됨

Proof of Actor는 기존 authentication, rate limiting, logging과 함께 server 내부에 자리합니다. integration은 각 founding team과의 직접적인 실무 지원으로 제공되므로, setup이 transport, hosting, tool design에 맞게 구성됩니다. MCP Servers와 APIs use case는 같은 접근 방식이 당신의 tools와 API 전반에 어떻게 적용되는지 보여줍니다.

노출한 모든 tool에 대해 물어볼 질문

tool-level policy를 작성하기 전에, MCP server가 노출하는 각 tool을 다음 짧은 checklist로 검토하면 도움이 됩니다.

이 tool은 무엇을 바꿀 수 있는가? read-only tool과 data를 수정하거나 message를 보내거나 billing에 영향을 주는 tool은 서로 다른 처리가 필요합니다.
누구를 위한 것인가? 어떤 tool은 로그인한 사람을 대신해 동작하는 assistant를 위한 것이고, 어떤 tool은 autonomous workflow를 위한 것입니다. 예상되는 caller가 적절한 policy를 결정합니다.
실수의 비용은 얼마인가? 잘못된 search 결과는 손실이 작습니다. 잘못된 deletion은 그렇지 않습니다. 각 tool을 risk tier에 매핑하세요.
어떤 evidence가 필요한가? 선언된 client만으로 충분한지, 아니면 tool이 verified identity와 가장 강한 authorization을 필요로 하는지 결정하세요.
Unknown일 때는 어떻게 할 것인가? 각 tool에 대해 명시적인 fallback을 선택하세요. allow, rate-limit, user에게 confirmation 요청, 또는 review로 route하기 등이 있습니다.
작동하고 있다는 것을 어떻게 알 것인가? 아무것도 enforce하기 전에 observation mode에서 어떤 결과를 볼지 정하세요.

각 tool에 대해 한 번씩 답하면 caller 식별이 명확하고 검증 가능한 규칙이 되며, 이를 통합하는 client에게 server의 behavior를 설명하기 쉬워집니다.

founding developer program에 참여하세요

Proof of Actor는 private beta 상태입니다. 선정된 founding development team은 합의된 사용 한도 내에서 최대 12개월 무료 access와 함께, tool-level policy를 설계하는 동안 엔지니어의 직접 지원을 받을 수 있습니다.

MCP server를 운영하고 있고 누가 그것을 호출하는지 알고 싶다면, apply for early access하세요. 당신의 server, 노출한 tools, 그리고 가장 중요한 calls에 대해 알려주세요.

Sources

Model Context Protocol specification (2025-06-18), modelcontextprotocol.io.
MCP lifecycle: initialization and clientInfo, modelcontextprotocol.io.
MCP authorization, modelcontextprotocol.io.
RFC 9421: HTTP Message Signatures, IETF, February 2024.
AWS STS GetCallerIdentity API reference, Amazon Web Services.

개발자를 위한

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

자주 묻는 질문

MCP server에 왜 호출자 식별이 필요한가요?

MCP server는 사람을 대신해 행동하거나 자율적으로 실행되는 AI 클라이언트에 도구를 노출합니다. 어떤 종류의 호출자가 도구 호출 뒤에 있는지 알면 영향이 작은 도구는 자유롭게 허용하고, 영향이 큰 도구에는 더 많은 조건을 요구할 수 있습니다.

MCP session의 client name은 검증인가요?

아니요. client name은 클라이언트가 선언하는 값입니다. Proof of Actor는 이를 declared evidence로 기록하고, 암호학적으로 검증된 identity와는 구분해 둡니다.

호출자 식별이 MCP authorization을 대체하나요?

아니요. 호출자 identity evidence, 사용된 credential, 그리고 호출자가 할 수 있는 일은 서로 다른 질문입니다. Proof of Actor는 첫 번째 질문에 컨텍스트를 더하고, authorization은 당신의 서버에 맡깁니다.

Proof of Actor가 도구 호출을 차단하나요?

정책이 그렇게 정하는 경우에만 그렇습니다. 모든 integration은 observation mode로 시작하며, 준비가 되면 도구 수준 정책을 활성화합니다.

어떻게 시도할 수 있나요?

초기 접근을 신청하세요. 선정된 founding developer 팀은 합의된 사용 한도 내에서 최대 12개월 무료 이용과 함께, 직접적인 integration 지원을 받을 수 있습니다.

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

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

조기 접근 받기 가격 보기

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