에이전트 권한 부여의 의미
에이전트 권한 부여는 AI 에이전트가 무엇을 할 수 있는지에 대한 결정입니다. 즉, 어떤 route를 호출할 수 있는지, 어떤 data를 읽을 수 있는지, 어떤 action을 수행할 수 있는지, 그리고 어느 정도의 volume으로 수행할 수 있는지를 정합니다. 이는 에이전트 식별과는 다르며, 에이전트 식별은 어떤 에이전트인지, 또는 어떤 operator의 에이전트인지가 요청을 보낸 주체인지 확인하는 것입니다.
이 둘은 종종 함께 나타나기 때문에 쉽게 혼동됩니다. 서명된 요청은 누가 보냈는지 알려줍니다. 하지만 그 보낸 주체가 account를 변경하거나, order를 생성하거나, data를 export할 수 있어야 하는지는 알려주지 않습니다. identity는 evidence이고, authorization은 policy입니다. 서명된 AI 에이전트 요청이 무엇을 증명하고, 무엇을 증명하지 않는지에 대한 글에서 이 차이를 자세히 설명합니다.
이 구분이 중요한 이유
애플리케이션은 이미 human 사용자에 대해 authentication과 authorization을 분리합니다. 로그인은 당신이 누구인지 증명하고, role과 permission은 무엇을 할 수 있는지 정합니다. 에이전트도 같은 분리가 필요하며, 여기에 한 겹의 주의가 더 필요합니다:
- Identity는 강하지만 permission이 없을 수 있습니다. 완전히 유효한 HTTP message signature를 가진 crawler라도 write endpoint를 호출할 고유한 권리는 없습니다.
- Permission은 강한 identity 없이도 존재할 수 있습니다. 고객의 API key를 사용하는 에이전트는 그 key에 의해 authorization을 받습니다. 그 key를 들고 있는 에이전트 소프트웨어가 무엇인지 식별되지 않더라도 마찬가지입니다.
- 에이전트 뒤의 사람이 중요합니다. 에이전트가 누군가를 대신해 행동할 때, 그 사람이 그 에이전트에게 권한을 부여했는지가 핵심 질문이 됩니다(delegated authority 참고).
이 둘을 하나의 검사로 합치면 두 가지 실패가 발생합니다. 사람의 login이 없다는 이유로 정당한 자동화를 차단하거나, 충분히 식별된 에이전트에게 원래 의도하지 않은 action을 신뢰해 맡기는 것입니다.
권한 부여가 일반적으로 표현되는 방식
대부분의 애플리케이션은 이미 가지고 있는 mechanism으로 에이전트를 권한 부여합니다:
- Credentials와 scope. API key 또는 scope가 통합에 필요한 범위로 제한된 OAuth 2.0 token. MCP server도 같은 모델을 사용합니다. MCP authorization specification은 보호된 server를 OAuth 2.1 resource server로 다룹니다.
- route 수준 policy. 알려진 에이전트에 열려 있는 읽기 전용 route, account에 연결된 credential이 필요한 쓰기 route.
- risk tier. 영향이 낮은 action은 넓게 허용하고, 영향이 큰 action은 더 강한 credential, 확인 또는 review를 요구합니다.
- operator, credential 또는 route별 rate limit과 quota.
에이전트 identity evidence는 이러한 결정에 하나의 입력으로 들어갑니다. 실제 적용 방법은 human과 AI 에이전트를 위한 app-level policy 설계를 참고하세요. 이를 통해 확인된 operator와 익명 client를 다르게 취급할 수 있지만, permission 자체는 여전히 여러분의 policy에서 나옵니다.
흔한 오해
- "검증된 에이전트면 허용된 것이다." 검증은 요청의 출처를 귀속시킬 뿐입니다. 그 귀속된 주체가 무엇을 할 수 있는지는 여전히 policy가 결정합니다.
- "에이전트는 사람이 아니라면 차단해야 한다." 많은 에이전트는 정당한 참여자입니다. 더 나은 질문은 각 actor 유형이 route별로 무엇을 할 수 있어야 하는가입니다.
- "authorization은 behavior로 추론할 수 있다." behavior는 어떤 종류의 actor가 있는지에 대한 신뢰도를 높이거나 낮출 수 있습니다. 하지만 그것만으로 permission을 부여해서는 안 됩니다.
Proof of Actor가 이를 다루는 방식
Proof of Actor는 evidence에 대한 질문에 답합니다. 어떤 actor가 존재하는지, 어떤 basis인지(verified, declared, inferred 또는 unknown), 그리고 무엇이 알려져 있고 무엇이 알려져 있지 않은지를 보여줍니다. 하지만 permission은 의도적으로 결정하지 않습니다. Agent 결과는, 심지어 검증된 경우라도 authorization을 의미하지 않습니다. Route에서 여러분의 애플리케이션은 actor 결과를 자체 credential, scope, risk tier와 결합해 각 interaction을 allow, adapt, challenge, review 또는 limit할 수 있습니다. 처음에는 observation mode로 시작해, 무엇이든 enforce하기 전에 결과를 확인할 수 있습니다.
결정이 앱 안에서 어떻게 연결되는지 더 알아보고, APIs와 MCP server 사용 사례를 살펴보거나, 조기 액세스를 신청하세요.
Sources
- RFC 6749: The OAuth 2.0 Authorization Framework: client를 위한 scope가 있는 token
- MCP specification 2026-07-28: Authorization: MCP server를 위한 OAuth 기반 authorization
- RFC 9421: HTTP Message Signatures: 서명된 요청이 무엇을 성립시키는지