에이전트의 인증 주체는 누구인가? 고객을 대신하여 행동하는 AI를 위한 신원 구축

한 고객이 AI 비서에게 인보이스 결제를 요청합니다. 비서는 계정을 선택하고 API를 통해 결제를 제출합니다.

백엔드는 유효한 토큰을 받습니다. 하지만 그 토큰이 고객, 액션을 실행하는 소프트웨어, 또는 둘 다를 식별할까요?

고객의 자격 증명만으로는 실행 주체를 모호하게 만들 수 있습니다. 서비스 자격 증명만으로는 고객의 권한을 확립하지 못합니다. 누군가를 대신하여 행동하는 에이전트는 이 신원들 사이에 강제 가능한 관계가 필요합니다.

문제점

고객의 기존 액세스 토큰을 에이전트 런타임에 전달하면 세션 권한이 다른 실행 환경으로 넘어갑니다. 그 권한은 작업 범위를 초과할 수 있으며, 다운스트림 기록은 모든 액션을 오직 고객에게만 귀속시킬 수 있습니다.

더 명확한 아키텍처는 세 가지 개념을 분리합니다:

• 고객 (Customer): 어떤 자원이 영향을 받는지.
• 워크로드 (Workload): 어떤 인증된 소프트웨어가 작업을 호출하는지.
• 위임 부여 (Delegation grant): 해당 워크로드가 그 고객을 위해 무엇을 할 수 있는지.

인증(Authentication)은 주체(actor)를 확립합니다. 위임(Delegation)은 그 권한을 정의합니다. 인가(Authorization)는 요청된 작업이 그 권한에 맞는지 결정합니다.

“당신은 이 고객을 대표한다”라는 프롬프트는 이들 중 어느 경계도 설정하지 못합니다.

어려워지는 지점

광범위한 동의는 모호한 권한을 만든다

“AI 접근 허용”만으로는 유용한 결제 경계를 설명할 수 없습니다.

“이 청구서를 이 계정에서, 오늘 날짜 전까지 3,000 루피까지 결제하기”와 같은 내용은 강제 가능한 제약 조건을 가진 구조화된 부여가 될 수 있습니다.

자연어는 권한을 제안할 수 있습니다. 백엔드는 승인된 정책을 검증하고 저장해야 합니다.

토큰 보호는 거래를 인가하지 않는다

송신자 제한 토큰(Sender-constrained tokens)은 관련 키 없이 도난당한 토큰의 유용성을 줄일 수는 있지만, 결제에 대한 고객의 승인을 확립하지는 못합니다.

DPoP의 경우, 예를 들어 결제 본문(payment body)에 서명하거나 동의(consent)를 금액 및 수취인에게 바인딩하지 않습니다. 자격 증명 보호와 거래 승인(transaction authorization)은 서로 다른 위험을 다룹니다.

재시도(Retries)가 소비된 권한과 상호작용하는 방식

백엔드가 ₹2,750 결제를 수락하고 부여된 권한의 단일 허용 작업을 예약했다고 가정해 봅시다. 응답이 손실되었습니다.

재시도는 다시 권한을 소모해서는 안 됩니다. 백엔드는 접근성을 확인하고 요청과 일치하는지 비교한 후, 범위가 지정된(scoped) Idempotency 키와 관련된 기존 작업을 반환해야 합니다.

단순히 부여된 권한에 아직 사용되지 않은 권한이 남아 있는지 여부만 확인해서는 이러한 복구 경로를 잘못 거부할 수 있습니다.

유효한 신원이라도 프롬프트 주입을 해결하지 못한다

검색된 인보이스나 이메일은 합법적인 에이전트의 도구 사용에 영향을 미칠 수 있습니다.

백엔드 제약 조건은 과도한 금액이나 승인되지 않은 목적지를 거부할 수 있습니다. 하지만 광범위한 부여(broad grant) 내에 남아 있는 유해한 결정을 항상 감지할 수는 없습니다.

권한 설계는 이러한 잔여 위험(residual risk)을 고려해야 합니다.

아키텍처 방향성

자격 증명은 모델 컨텍스트나 생성된 출력 외부의 통제된 실행 구성 요소에 보관해야 합니다. 워크로드를 독립적으로 인증하고, 그 허용되는 작업을 백엔드 위임 기록(backend delegation record)과 연결해야 합니다.

결제 수락 시:

• 자격 증명을 검증하고 고객 및 현재 행위자(actor)를 식별합니다.
• 범위가 지정된 Idempotency 키가 이미 작업을 식별하는지 확인합니다.
• 기존 작업의 경우, 접근성과 일치하는 결제 세부 정보를 검증합니다.
• 새로운 작업의 경우, 부여 상태, 한도, 목적지 및 승인 요구 사항을 강제합니다.
• 권한 소비, Idempotency, 영구 전송 의도를 원자적으로(atomically) 기록합니다.

철회(revocation)가 수락과 어떻게 경쟁하는지 정의해야 합니다. 미래의 권한을 철회한다고 해서 이미 전송된 결제가 반드시 취소되는 것은 아닙니다.

큐(queues)와 워커(workers)를 거치면서 초기 행위자 및 위임 참조(delegation reference)를 보존해야 합니다. 워커의 서비스 신원(service identity)이 누가 비즈니스 작업을 시작했는지 지워버려서는 안 됩니다.

핵심 요약

인증된 에이전트는 설계의 한 부분일 뿐입니다.

백엔드는 어떤 소프트웨어가 행동했는지, 누구의 권한을 사용했는지, 그 권한이 무엇을 허용했는지, 그리고 실행이 불확실해졌을 때 어떻게 복구되었는지를 설명해야 합니다.

더 깊은 아키텍처 분석, 구현 고려 사항, 실패 시나리오 및 전체 추론 과정이 궁금하신가요?

Medium에서 전체 기사 읽기