연결된 에이전트, 끊어진 책임의 사슬

로그는 행동만 알고 권한은 모른다

2026년 7월 21일 미국 상원에 제출된 법안 S.5051은 사용자를 대신해 행동하는 ‘수탁형 사용자 에이전트’를 다음과 같이 규정한다. 에이전트의 작동 방식은 투명하게 문서화되어야 하고, 권한의 범위는 명확히 제한되어야 하며, 사용자는 위임한 권한을 언제든 철회할 수 있어야 한다. 에이전트가 사용자를 대신해 수행한 모든 행위는 실시간으로 기록해야 한다. 허용 범위를 벗어난 행동과 명시적 승인 없는 권한 재위임도 금지된다.

하지만 현재의 관측 도구는 이런 요구에 답하기 어렵다. 오픈소스 관측 표준 OpenTelemetry의 생성형 AI 규약은 execute_tool과 invoke_agent 스팬(하나의 작업 구간을 담는 기록 단위)을 통해 도구 이름과 인자, 토큰 사용량, 지연 시간 등을 기록한다. 반면 권한의 핵심 맥락은 남기지 않는다. 누가 권한을 부여했는지, 어떤 목적과 범위로 허용했는지, 권한이 언제 만료되거나 철회됐는지, 실행 과정에서 어떤 행위자들을 거쳤는지를 하나로 연결할 필드가 없다. 따라서 transfer_funds 호출 기록이 있더라도, 호출 당시 송금 권한이 유효했는지는 확인할 수 없다.

행동 기록과 권한 정보를 연결할 조인 키가 없다면, 아무리 많은 로그를 수집해도 그것은 권한 원장이 될 수 없다. S.5051이 미국 국립표준기술연구소(NIST)에 ‘범위가 제한되고 철회 가능한 위임 증명’과 ‘감사 가능한 행위 기록’을 위한 프로토콜을 발굴하거나 개발하도록 요구하는 이유도 여기에 있다. 기존 로그만으로는 에이전트가 무엇을 했는지는 알 수 있지만, 그 행동을 할 권한이 있었는지까지 증명할 수는 없다.

에이전트가 늘수록 권한은 흐려진다

한 작업이 네 단계를 거쳐 처리된다고 가정해 보자.

먼저 사용자는 오케스트레이터에 OAuth 권한을 부여한다. 이때 권한의 범위와 만료 시점, 철회 주소를 지정한다. 오케스트레이터는 함수 호출로 서브에이전트를 생성하고, 서브에이전트는 에이전트 간 통신 규약 A2A를 통해 파트너 에이전트에 에이전트 카드와 작업을 전달한다. 마지막으로 파트너 에이전트는 MCP를 거쳐 자신의 서비스에 접근하며, 이 과정에서 소지자 토큰(bearer token, 가진 사람이 곧 권한자로 인정되는 토큰)을 사용한다.

문제는 사용자의 명시적인 인가 기록이 대부분 첫 단계에만 남는다는 점이다. 이후 권한이 여러 에이전트를 거쳐 전달되더라도, 누가 누구에게 어떤 권한을 위임했는지 입증할 기록은 이어지지 않는다.

기본 프로토콜만으로는 이 공백을 메우기 어렵다. 서브에이전트를 호출할 때는 위임 관계를 명시하는 별도의 통로가 없고, A2A에도 위임 내역을 담는 전용 필드가 없다. MCP의 OAuth 2.1 지원 역시 서버 접근용 토큰을 발급받는 절차일 뿐, 여러 단계를 거친 위임 이력을 전달하는 규약은 아니다. 2026년 8월 A2A가 MCP와 함께 Agentic AI Foundation에 편입된 것도 공동 거버넌스 체계의 변화였을 뿐, 프로토콜에 위임 기능이 추가된 것은 아니었다.

S.5051은 이러한 다단계 위임을 더 엄격하게 다룬다. 권한을 다른 사업자나 에이전트, 별도로 운영되는 AI에 넘기려면 사용자에게 명시적이고 구체적이며 철회 가능한 허가를 다시 받아야 한다. 권한을 넘겨받은 주체에도 동일한 의무가 적용된다.

ADCS나 cA2A처럼 위임 체인을 별도로 기록하는 규격이 등장한 이유도 여기에 있다. 기존 프로토콜만으로는 권한이 여러 주체를 거치는 동안 각 단계의 위임 근거가 사라지기 때문이다.

권한은 부여 순간부터 원장이 된다

권한이 부여되는 즉시 고유 ID가 있는 grant 객체를 발행해야 한다. 이 객체에는 권한 부여 주체, 허용 범위, 사용자가 밝힌 목적, 만료 시점, 철회 방법을 기록한다. 이후 발생하는 모든 행동에는 해당 ID를 남기고, 부여된 범위와 실제로 사용한 범위를 함께 기록한다. 단순히 서비스를 연결한 것만으로는 grant가 성립하지 않는다. 만료 시점이 없는 grant 역시 사실상 장기 자격증명과 다르지 않다.

하위 서비스에 권한을 넘기는 서브위임도 추적 가능한 연산으로 기록해야 한다. 토큰 교환 표준인 RFC 8693의 act 클레임을 사용하면 어떤 서비스가 누구를 대신해 행동하는지 토큰에 명시할 수 있다. 중첩 구조를 통해 이전 행위자까지 표현할 수 있으므로, 추가 표준을 기다리지 않고도 위임의 각 단계에 근거를 남길 수 있다.

결제 분야의 AP2는 Intent, Cart, Payment Mandate라는 서명 객체를 통해 누가 무엇을 허가했는지 전달한다. 그러나 행위 주체를 확인하는 것만으로는 구매 금액이 당시 사용자의 한도 안에 있었는지까지 증명할 수 없다. 이를 판단하려면 별도의 기록이 필요하다.

지속형 에이전트도 마찬가지다. 동일한 계정이 계속 활동하고 있다는 사실과 그 계정의 권한이 여전히 유효하다는 판단은 구분해야 한다. 목적, 범위, 기간이 명시된 lease와 grant 원장이 그 판단의 근거가 된다. 이미 생성된 트레이스에 누락된 ID를 나중에 정확히 복원할 수는 없다. 따라서 원장은 권한을 부여하는 시점부터 기록하기 시작해야 한다.

출처

#에이전트 #AI 정책