에이전트 접근 정책

직접 제어하는 정책으로 AI 에이전트를 라우팅하세요

애플리케이션이 사람, AI 지원 사용자, 자율 에이전트를 route별로 어떻게 처리할지 결정하세요. Proof of Actor가 evidence를 제공하고, 정책이 최종 결정을 내립니다.

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

모두에게 하나의 정책만으로는 더 이상 충분하지 않습니다

대부분의 application은 하나의 사용자 유형을 전제로 설계되었습니다. account에 로그인한 뒤 interface를 클릭하는 사람입니다. access control도 그 가정에 맞춰 작동했습니다. session이 유효하면 request는 통과하고, 자동화된 것으로 보이면 CAPTCHA나 차단이 나타납니다.

그 모델은 무너지고 있습니다. 오늘날 같은 application은 사람, AI assistant와 함께 일하는 사람, 그리고 누군가를 대신해 행동하는 자율 agent를 모두 상대합니다. 어떤 agent는 고객 자신의 integration입니다. 어떤 agent는 documentation을 가져오는 AI assistant입니다. 어떤 agent는 crawler입니다. 또 일부는 제품을 악용하려고 합니다. 하나의 예 아니오 규칙으로는 이 모두를 잘 처리할 수 없습니다.

AI 에이전트 routing 및 access 정책은 그 단일 규칙을 의도적인 결정들의 집합으로 바꿉니다. 어떤 actor가 어떤 experience를 받고, 어떤 route에서, 어떤 조건으로 처리될지 정하는 것입니다. Proof of Actor는 애플리케이션이 그 결정을 내릴 evidence를 제공하고, 결정 자체는 고객이 직접 통제하도록 남겨둡니다. 이 접근의 설계 원칙은 사람과 AI 에이전트를 위한 app 정책 설계에서 확인할 수 있고, SaaS apps use case에서는 정책이 실제 product workflow에 어떻게 대응하는지 볼 수 있습니다.

좋은 agent 정책의 모습

유용한 정책은 구체적입니다. 특정 route 또는 workflow, actor class, 필요한 evidence의 강도, 그리고 response를 명시합니다. 예:

읽기 전용 catalog route: verified agent는 허용하고 구조화된 response를 제공합니다. declared agent에는 표준 rate limit을 적용합니다.
account 변경 action: 모두에게 기존 re-authentication을 유지합니다. actor가 Unknown이고 action의 영향이 큰 경우에는 review를 추가합니다.
support submission: AI 지원 content를 명시적으로 받아들이고 routing을 위해 라벨링합니다.
signup: 기존 check를 유지합니다. inferred actor result만으로는 절대 판단하지 않습니다.

이 모든 것은 모든 agent를 악용으로 간주하지도, 모든 agent를 무조건 신뢰하지도 않으면서 actor에 응답합니다. 바로 이것이 agent 인식 access의 핵심이며, 사람과 AI 에이전트를 위한 app 정책 설계 글에서는 route별로 더 많은 예시를 다룹니다.

다섯 가지 response

Proof of Actor의 Route 기능은 정책이 선택할 수 있는 다섯 가지 response를 중심으로 설계되어 있습니다.

Allow

request를 평소처럼 진행합니다. public 또는 low-risk route의 대부분 traffic, agent traffic을 포함한 대부분의 traffic은 그대로 allow되어야 합니다.

Adapt

actor에 맞게 experience를 바꿉니다. verified agent에는 사람용 interface 대신 구조화된 API response 또는 page의 Markdown version을 제공합니다. AI agent에 구조화된 content 제공하기 가이드에서 이 패턴을 다룹니다.

Challenge

더 강한 것을 요구합니다. 새 로그인, 추가 credential, account owner의 confirmation 등이 해당합니다. 잘못된 결정의 비용이 큰 route에서 challenge를 사용하세요.

Review

action을 곧바로 완료하지 않고 queue로 넘기거나, 사람이 확인하도록 표시합니다. legitimate user를 차단하면 손해가 크지만 무심코 완료하면 위험한 경우에 review가 유용합니다.

Limit

actor와 route에 맞춘 rate 또는 volume limit을 적용해, 사람을 위해 설계된 workflow를 자동 caller가 압도하지 못하게 합니다.

robots.txt가 access 정책이 아닌 이유

많은 team이 robots.txt로 시작하며, crawler에 대한 첫 번째 signal로는 합리적입니다. 하지만 agent를 위한 access 정책은 아닙니다. crawler 운영자는 user agent별로 다른 behavior를 문서화합니다. Anthropic은 자사 bot이 robots.txt directive를 준수한다고 밝히고(Anthropic crawler documentation), OpenAI는 ChatGPT에 질문할 때 사용자를 대신해 동작하는 ChatGPT-User에 대해서는 action이 user에 의해 시작되므로 robots.txt rule이 적용되지 않을 수 있다고 설명합니다(OpenAI crawler documentation). robots.txt는 API, MCP tool 또는 로그인된 workflow에 대해서는 아무 말도 하지 않습니다.

access 정책은 request가 처리되는 위치에서 실행되어야 하며, RFC 9421에 따라 검증된 signature 같은 evidence를 읽고, route별로 response를 선택해야 합니다. MCP server의 경우 MCP authorization specification이 client가 HTTP를 통해 access token을 얻는 방식을 정의합니다. actor 정책은 그 위에 context를 더할 뿐, 이를 대체하지 않습니다.

Proof of Actor가 정책에 공급하는 정보

integration이 평가하는 모든 request는 정책이 읽을 수 있는 네 부분으로 구성된 actor result를 생성합니다.

Class: Human, Human + AI, Agent 또는 Unknown.
Basis: verified, declared, inferred 또는 unknown. 이를 통해 policy가 검증된 signature와 사용자가 스스로 밝힌 client name을 다르게 다룰 수 있습니다.
Evidence summary: 결과가 무엇에 근거하는지 읽기 쉽게 설명한 내용으로, logging과 review에 유용합니다.
Context: 어떤 integration과 어떤 route가 이 결과를 만들었는지.

basis가 명시적이기 때문에 policy를 정밀하게 만들 수 있습니다. "agent를 allow한다"는 말은 "read route에서는 verified agent를 allow하고, declared agent에는 rate-limit을 적용하며, 나머지에는 Unknown fallback을 사용한다"로 바뀝니다. request에서 decision까지의 전체 흐름은 How It Works에서 설명합니다.

fallback은 정책의 일부입니다

정책은 evidence가 없을 때 어떻게 동작하는지에 따라 품질이 결정됩니다. Proof of Actor는 이런 경우를 숨기지 않고 명시합니다.

Unknown: evidence가 판단을 뒷받침하지 못했습니다. 정책이 route별로 Unknown의 의미를 정의합니다. 이것은 절대 Human으로 바뀌지 않으며, 기본적으로 악의적이라고 간주되지 않습니다.
Timeout: 결과가 제때 도착하지 않았습니다. integration은 해당 route에 대해 선택한 fallback을 적용합니다.
Missing signals: collector가 실행되지 않았거나 header가 없었습니다. 결과는 그 사실을 반영하며, 정책도 그에 맞게 처리합니다.

각 route마다 fail open 또는 fail closed 중 무엇을 할지 선택합니다. fail open은 Proof of Actor가 없어도 request가 계속 진행되는 것을 의미하고, fail closed는 기존의 더 강한 check가 적용되는 것을 의미합니다. low-risk route는 보통 fail open으로 둡니다. 민감한 action은 보통 fail closed로 둡니다. 이것은 전역 설정이 아니라 risk tier별 설정입니다.

identity, credential, authorization은 분리해서 다뤄야 합니다

agent access 정책은 세 가지 distinct layer 위에 놓이며, 이를 분리해 두면 가장 큰 실수를 막을 수 있습니다.

Identity evidence는 어떤 종류의 actor가 호출하는지와 그것을 무엇이 증명하는지에 답합니다. Proof of Actor가 이를 제공합니다.
Credentials는 어떤 account가 책임을 지는지에 답합니다. session, token 또는 API key가 이를 제공합니다.
Authorization은 이 caller가 이 action을 수행할 수 있는지에 답합니다. 권한 model이 이를 제공합니다.

verified agent identity가 있다고 해서 그 agent가 authorized라는 뜻도 아니고, 사람이 그 agent에게 권한을 위임했다는 뜻도 아니며, 그 action이 안전하다는 뜻도 아닙니다. actor result는 routing과 context 추가에 사용하세요. permission 부여는 authorization model로 처리하세요. Detection & Limitations 페이지에서는 각 evidence 유형이 무엇을 입증할 수 있는지 정확히 설명합니다.

아무것도 깨지지 않게 배포하기

agent access 정책을 도입하는 가장 안전한 방법은 단계적으로 진행하는 것입니다.

Observe. observation mode에서 Proof of Actor를 설치합니다. 사용자에게는 아무 변화가 없고, 결과만 기록됩니다.
Understand. 어떤 actor가 어떤 route를 사용하는지, 각 route의 unknown rate가 얼마인지, 그리고 이미 알고 있는 사실과 어긋나는 결과가 있는지 검토합니다.
Preview. policy를 preview로 실행해, enforce하지 않은 상태에서 무엇을 했을지 기록합니다.
Enforce narrowly. evidence가 분명히 뒷받침하는 하나의 route에서만 policy를 활성화합니다. 결과를 확인합니다.
Expand. confidence가 쌓이면 더 많은 route로 확장합니다.

actor-aware policy를 안전하게 배포하기 가이드가 각 단계를 설명하고, agent를 막지 않으면서 민감한 action을 보호하기에서는 고위험 route를 다룹니다.

팀이 얻는 것

Proof of Actor를 사용하면 팀은 세 가지 capability를 담은 하나의 integration을 얻게 됩니다. Detect는 actor signal을 수집하고 verified assertion을 inference와 분리합니다. Understand는 actor analytics, trend, 그리고 각 결과의 evidence를 보여주며 Unknown을 계속 보이게 유지합니다. Route는 이 페이지에서 설명한 policy를 작성해 원하는 위치에 적용할 수 있게 합니다. private beta 동안 routing policy는 각 founding team과 함께 설계되며 고객의 application code 안에서 실행되므로, 고객이 완전한 control을 유지합니다.

피해야 할 일반적인 정책 실수

처음 agent access를 설계하는 team은 몇 가지 실수를 반복하는 경향이 있습니다. 이를 피하면 수주에 걸친 재작업을 줄일 수 있습니다.

모든 agent를 기본 차단하는 것. 그러면 legitimate agent는 우회 경로를 찾게 되고, 종종 사람을 위해 만든 interface를 scraping합니다. 이는 구조화된 경로보다 보호하기 어렵습니다.
declared name을 신뢰하는 것. 이름만 밝힌 client는 claim을 한 것이지 proof를 제공한 것이 아닙니다. 검증되지 않은 caller와 같은 방식으로 다뤄야 합니다.
모든 곳에 하나의 fallback을 쓰는 것. public pricing page의 Unknown과 password change의 Unknown은 전혀 다른 상황입니다. 각 route마다 별도의 답이 필요합니다.
inference만으로 사람에 대해 결정하는 것. actor result는 routing을 위한 context이지 개인에 대한 판결이 아닙니다. 중대한 결정은 자신의 control과 review에 맡기세요.
observation을 건너뛰는 것. 첫날부터 enforce하면 customer complaint를 통해 false positive를 발견하게 됩니다. 먼저 observe하고, evidence가 분명한 곳에서만 enforce하세요.

각 enforce 단계 전에 security, product, support 담당자와 짧게 policy를 review하면 이런 문제의 대부분을 초기에 잡을 수 있습니다.

Founding Developer Program으로 시작하세요

Proof of Actor는 private beta 상태입니다. 선정된 founding development team은 합의된 usage limit 내에서 최대 12개월 동안 무료 access를 받을 수 있으며, 첫 policy를 설계하는 동안 우리의 engineer가 직접 지원합니다.

애플리케이션이 AI agent를 어떻게 다뤄야 할지 결정하고 있다면, early access 신청을 해보세요. 가장 중요한 route와 만들고 싶은 decision을 알려주시면, 그에 맞는 policy를 함께 설계하겠습니다. 또한 이것이 APIs와 MCP servers에 어떻게 적용되는지도 확인할 수 있습니다.

Sources

Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
Overview of OpenAI crawlers, OpenAI.
RFC 9421: HTTP Message Signatures, IETF, February 2024.
MCP authorization, modelcontextprotocol.io.

개발자를 위한

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 에이전트 접근 정책이란 무엇인가요?

요청을 보내는 actor의 종류에 따라 애플리케이션이 적용하는 규칙입니다. 예를 들어 읽기 전용 route에서는 verified agent를 허용하고, 영향이 큰 action에서는 더 강한 credential을 요구하는 방식입니다. Proof of Actor는 actor result를 제공하고, 정책이 응답을 결정합니다.

Proof of Actor가 정책을 자동으로 enforce하나요?

아니요. 모든 integration은 observation mode로 시작하며, 정책은 팀이 해당 workflow에 적합하다고 확신할 때 route별로 활성화합니다.

actor가 Unknown이거나 check가 timeout되면 어떻게 되나요?

각 route마다 명시적 fallback을 정의합니다. 예를 들어 public read는 allow하고 account 변경에는 기존 check를 유지할 수 있습니다. Unknown과 timeout은 절대 Human으로 기본 처리되지 않습니다.

모든 AI 에이전트를 차단해야 하나요?

대개는 그렇지 않습니다. 많은 agent는 정당한 참여자입니다. 정책을 통해 구조화된 경로를 제공하고, 중요한 부분에서는 제한하며, 민감한 action에는 더 강한 check를 남겨둘 수 있습니다.

정책이 사람에 대한 결정을 내릴 수 있나요?

Proof of Actor 결과는 고용, 신용, 필수 서비스 접근 같은 개인에 대한 중대한 결정의 유일한 근거가 되어서는 안 됩니다. 자신의 control과 함께 routing 및 context 파악에 활용하세요.

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

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

조기 접근 받기 가격 보기

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