Why an AI Agent Must Never Choose Its Own Acting Subject

개요

AI 에이전트는 유효한 도구 호출을 생성할 수 있지만, 해당 행위에 대한 합법적인 주체(acting subject)가 없다는 문제가 발생할 수 있습니다. 특히 에이전트가 질문 응답을 넘어 주문, 재고, 직원 기록, 권한, 금전과 관련된 작업을 수행할 때 이 문제는 더욱 중요해집니다.

주요 내용

* 세 가지 신원(Identity)의 통합 문제: AI 에이전트 호출은 요청하는 인간 또는 비즈니스 주체, 에이전트 클라이언트/서비스 신원, 그리고 실제 비즈니스 시스템에서 작업을 평가하는 '행위 주체(acting business subject)'라는 세 가지 신원을 포함할 수 있습니다. 이 세 가지가 user_id와 같이 모델이 생성한 단일 값으로 통합될 경우, 인증, 위임, 비즈니스 권한 부여를 구분하기 어려워집니다.
* 모델 생성 신원의 비신뢰성: 모델의 출력값인 도구 인수는 신뢰할 수 없는 요청 데이터와 마찬가지로 의심해야 합니다. 모델은 모호한 사용자 언어, 오래된 대화 기억, 프롬프트 주입, 우연히 포함된 관리자 ID 예시, 단순히 작동하는 것처럼 보이는 신원 선택 시도, 또는 환각(hallucination) 등으로 인해 잘못된 주체를 생성할 수 있습니다. 모델은 암호화적으로 누가 인증되었는지, 어떤 위임이 부여되었는지, 또는 해당 위임이 여전히 유효한지 증명할 수 없습니다.
* 신뢰할 수 있는 행위 주체를 설정하는 방법: 신뢰할 수 있는 행위 주체는 인증된 애플리케이션 세션, 검증된 JWT 또는 서명된 위임 티켓, 신뢰할 수 있는 채널 신원에서 서버 측 매핑, 엔터프라이즈 신원 공급자, 명시적으로 비인간 서비스 작업을 위한 워크로드 신원, 승인된 핸드오프 후 발급된 단기 기능 등 신뢰할 수 있는 시스템 경계에서 와야 합니다. 중요한 것은 신뢰 경로(principal -> verified delegation/session -> runtime-bound acting subject -> business authorization check -> audit evidence)입니다.
* 모델 제어 인수 외부의 주체 컨텍스트 유지: 더 안전한 도구 경계는 요청된 비즈니스 데이터와 신뢰할 수 있는 신원 컨텍스트를 분리합니다. 모델 제어 인수(예: order_id, amount)와 신뢰할 수 있는 호출 컨텍스트(예: subject_id, tenant_id, delegation)를 명확히 구분해야 합니다.
* 도구 가시성은 주체 가용성에 따라 결정: 상품 카탈로그 검색과 같이 주체가 필요하지 않은 기능과, 개인 주문 읽기, 환불 생성 등 신뢰할 수 있는 주체가 필요한 기능은 구분되어야 합니다. 주체가 필요한 기능은 해당 주체가 없을 경우 에이전트에게 표시되지 않아야 합니다. Agent Capability Contract (ACC)는 subject: required: true와 같은 방식으로 이를 선언합니다.
* 모든 중요한 경계에서 주체 재확인: 대화 시작 시 한 번만 주체를 확인하는 것으로는 불충분합니다. 작업이 큐에 들어가거나, 일시 중지되거나, 재시도될 경우 사용자의 로그아웃, 위임 만료, 역할 취소, 주문 이전, 또는 다른 승인 주체가 발생할 수 있습니다. 최소한 주체는 런타임이 사용하는 호출 증거(task\_id + tool + arguments + acting\_subject + approval\_evidence)에 바인딩되어야 하며, 비즈니스 시스템은 실행 시점에 현재 비즈니스 상태와 대조하여 주체를 재평가해야 합니다.
* 신뢰할 수 있는 주체는 최종 권한 부여가 아님: '이 행위가 employee-27을 대표한다'는 것을 증명하는 것만으로는 'employee-27이 ORD-1042에 대해 800을 환불할 수 있다'는 것을 증명하지 못합니다. 비즈니스 시스템은 해당 직원의 환불 권한, 주문 소속 테넌트/스토어, 현재 환불 가능 여부, 요청 금액 제한, 이미 환불 처리되었는지 여부, 조직별 위험 통제 등을 최종적으로 확인해야 합니다. 이는 '도달(reach)'과 '권한(authority)'의 차이입니다.
* 실용적인 구현 순서: 신원 바운드 작업을 위해, 인증된 인간/워크로드/신뢰 채널, 검증된 컨텍스트에서 행위 주체 해석, 현재 경로 및 주체 전제 조건에 허용된 기능만 노출, 모델이 기능을 선택하고 인수 생성, 모델 출력에 의한 거버넌스 메타데이터/주체 컨텍스트 대체 시도 거부, 주체/도구/인수/작업/승인 증거 바인딩, 신뢰할 수 있는 신원 컨텍스트를 인증된 경계를 통해 비즈니스 시스템으로 전송, 비즈니스 시스템의 최종 권한 부여 수행, 누가 요청/대표/승인/실행했는지 설명할 충분한 증거 기록 등의 순서가 권장됩니다.

시사점

AI 에이전트가 민감한 비즈니스 작업을 수행할 때는 모델이 생성한 user_id 등에 의존하는 것이 아니라, 신뢰할 수 있는 시스템 경계로부터 오는 명확하고 검증 가능한 신원 컨텍스트를 사용해야 합니다. subject.required와 같은 메타데이터는 특정 기능에 대해 신뢰할 수 있는 행위 주체의 필요성을 명시하며, 실제 신원 해결 및 권한 부여는 배치별 비즈니스 로직 및 현재 상태에 따라 이루어져야 합니다.