위임된 권한의 의미
위임된 권한은 사람(또는 조직)이 AI 에이전트에게 자신의 대신 행동하도록 부여하는 허가입니다. 어시스턴트가 캘린더에 회의를 예약하거나, 사용자를 대신해 지원 티켓을 접수하거나, 공급업체 포털에서 인보이스를 가져올 때, 그것은 사용자에게서 비롯된 권한을 행사하는 것입니다.
좋은 위임에는 세 가지 속성이 있습니다. 범위가 제한되어야 하고(에이전트가 일부 일은 할 수 있지만 모든 일을 할 수는 없음), 시간적으로 제한되어야 하며(만료되거나 철회될 수 있음), 귀속 가능해야 합니다(받는 애플리케이션이 누구의 권한이 행사되고 있는지 알 수 있어야 함).
애플리케이션에서 이것이 중요한 이유
애플리케이션 관점에서 보면, 에이전트 요청은 최대 세 가지의 별도 질문을 제기합니다:
- 누가 이 요청을 보냈는가? 이것은 에이전트 신원이며, 서명된 요청으로 확인할 수 있습니다(HTTP Message Signatures 참조).
- 누구의 권한으로 행동하는가? 이것은 위임입니다.
- 그 권한이 이 작업에 충분한가? 이것은 authorization이며, 애플리케이션의 자체 정책이 결정합니다.
잘 알려진 어시스턴트 운영자의 서명된 요청은 첫 번째 질문에 대해 좋은 답을 줍니다. 하지만 그것만으로는 두 번째 질문에 대해 아무것도 말해주지 않습니다. 어시스턴트는 사용자의 대신 행동할 수도 있고, 사용자가 아닌 다른 사람을 위해 행동할 수도 있으며, 아예 자체적인 판단으로 행동할 수도 있습니다. 클라이언트 신원을 사람의 동의에 대한 증거로 취급하는 것은 에이전트 대응 설계에서 가장 흔한 실수 중 하나입니다. 서명된 AI 에이전트 요청이 무엇을 증명하고 무엇을 증명하지 못하는지를 보세요.
위임이 일반적으로 표현되는 방식
- OAuth 스타일의 권한 부여. 사용자가 애플리케이션에 로그인하고, OAuth 2.0 (RFC 6749)에 정의된 대로 제한된 스코프를 가진 토큰을 에이전트에 부여합니다. 그러면 애플리케이션은 토큰이 누구의 권한을 담고 있는지 정확히 알 수 있고, 그 권한은 철회할 수 있습니다(RFC 7009).
- 계정 범위의 API key: 사용자가 특정 통합용으로 만들며, 이상적으로는 권한을 좁게 부여한 키입니다.
- 앱 내 확인: 영향이 큰 작업에 대해, 사람이 에이전트가 준비한 특정 작업을 승인합니다.
- 토큰 수준의 위임 클레임. OAuth 2.0 Token Exchange (RFC 8693)는 한 당사자가 다른 당사자를 대신해 행동함을 기록하는
act(actor) 클레임을 정의합니다. 요청에서 에이전트 위임을 표현하는 새로운 작업은 아직 발전 중이며, 애플리케이션은 위임 클레임을 있는 그대로 받아들이기보다 자체 기록과 대조해 검증해야 합니다.
흔한 오해
- "에이전트가 검증되었으면 사용자가 승인한 것이다." 검증은 클라이언트를 식별합니다. 승인은 애플리케이션이 신뢰하는 채널을 통해 사람에게서 나와야 합니다.
- "내 사용자의 세션을 사용하는 에이전트면 괜찮다." 그럴 수도 있지만, 세션은 대화형 사람 사용을 위해 발급된 것입니다. 많은 애플리케이션은 작업의 귀속성과 철회 가능성을 위해 자동화에는 별도의, 범위가 제한된 권한을 선호합니다.
- "위임은 전부 아니면 전무다." 가장 안전한 위임은 좁습니다. 읽기 권한은 넓게, 쓰기 권한은 특정 작업에만, 되돌릴 수 없는 작업은 확인을 요구하는 방식입니다.
Proof of Actor와의 관계
Proof of Actor는 상호작용이 에이전트에 의해 주도되었는지 또는 AI가 보조했는지, 그리고 그 근거가 검증됨, 선언됨, 추론됨, 알 수 없음 중 무엇인지 보여줍니다. 이 맥락은 위임 관련 질문이 어디에서 생기는지 알려줍니다. 예를 들어 사람 계정 세션 안에서 동작하는 autonomous agent가 그렇습니다. Proof of Actor는 위임 자격 증명을 발급하거나 검증하지 않으며, Agent 결과가 곧 사람이 그 작업을 승인했다는 뜻은 아닙니다. 그것은 애플리케이션의 자체적인 권한 부여, 스코프, 확인 절차가 결정합니다. 그리고 Route를 사용하면 실제 트래픽을 관찰한 뒤 각 route에 맞는 정책을 적용할 수 있습니다. 정책 패턴은 사람과 AI 에이전트를 위한 앱 수준 정책 설계를 보세요.
근거가 무엇을 입증할 수 있고 무엇을 입증할 수 없는지를 읽거나, 조기 액세스를 신청하세요.
출처
- RFC 6749: The OAuth 2.0 Authorization Framework: resource owner에서 client로의 범위 제한 권한 부여
- RFC 7009: OAuth 2.0 Token Revocation: 위임된 토큰의 철회
- RFC 8693: OAuth 2.0 Token Exchange: 위임을 위한
act(actor) 클레임