AI 에이전트 권한 관리란? 고객 대신 온 AI의 동의를 검증하는 법

고객 대신 온 AI의 신원과 동의는 따로 확인해야 합니다. PACT와 Sierra 발표로 권한 검증 기준을 정리합니다.

Share
AI 에이전트 권한 관리와 고객 동의 검증을 표현한 청록색 게이트

편집 및 재구성: AXMOS 콘텐츠팀 | 최종 수정 2026-10-13

핵심 요약

  • AI 에이전트 권한 관리는 호출한 AI의 신원과 고객이 맡긴 작업 범위를 나누어 확인하는 일입니다.
  • Decagon의 PACT는 고객 계정 접근 전에 고객 인증과 동의를 거치고, 승인한 범위를 요청마다 확인하도록 설계되었습니다.
  • Meta와 Sierra가 업계 파트너들과 개발 중인 Personal Agent Protocol은 기업이 웹사이트·API·자사 에이전트 가운데 허용할 접점을 정하는 방향을 제시합니다.
  • AXMOS는 고객 대리 AI를 받는 기업이 조회와 변경 권한부터 구분하고, 승인 범위를 벗어나는 요청을 시험해야 한다고 봅니다.

AI 에이전트 권한 관리란?

AI 에이전트 권한 관리는 고객을 대신한 AI가 실행할 수 있는 업무 범위를 정하고 확인하는 일입니다. 외부에서 접속한 AI가 정상적인 서비스인지 확인해도, 그 AI가 특정 고객의 주문을 취소해도 되는지는 별도로 확인해야 합니다.

예를 들어 고객이 자신의 AI에게 배송 상태만 알아봐 달라고 했다고 가정해 보겠습니다. 조회 과정에서 배송 지연을 발견한 AI가 주문까지 취소한다면, 결과가 고객에게 유리해 보여도 처음 맡긴 범위를 넘습니다. 이 상황은 설명을 위해 만든 가상 예시입니다.

2026년 10월 6일(미국 시간) 공개된 고객 대리 에이전트 관련 발표들은 이 구분을 구체화하고 있습니다. Decagon의 PACT 공식 설명은 개인 에이전트의 신원과 고객 계정에서 행동할 권한을 분리합니다. Sierra가 10월 6일 발표한 Personal Agent Protocol도 소비자가 접근을 허용하고 기업이 가능한 행동의 범위를 정한다는 원칙을 제시합니다.

이 글은 2026년 10월 13일까지 확인한 공식 발표를 바탕으로 정리한 동향 분석입니다. 기존의 상시 에이전트 업무 위임 논의와 달리, 회사 밖에서 고객을 대리해 들어오는 AI를 어떻게 받아들일지에 초점을 맞춥니다.

에이전트 인증이랑 권한 관리는 어떻게 하세요?

먼저 호출한 에이전트를 확인하고, 그다음 고객이 승인한 계정과 작업 범위를 확인합니다. PACT는 이 두 확인 절차를 분리한 뒤 실제 요청에서 함께 검증하도록 설명합니다.

Decagon은 Instinct와 함께 개발한 PACT를 공개하며 A2A와 OAuth 2.0을 활용한다고 밝혔습니다. A2A는 에이전트 간 통신에 쓰이고, OAuth는 접근 권한을 승인하는 데 쓰입니다. 여기서 기업이 주목할 부분은 기술 이름보다 고객의 동의가 어느 작업에 연결되는지입니다.

  1. 접속한 에이전트를 확인합니다. 개인 에이전트는 기업의 Agent Card에서 접점과 인증 요건, 이용 가능한 권한을 찾습니다. 짧은 유효기간을 가진 서명된 JWT로 요청자를 확인하지만, 이 단계만으로 고객 계정 소유권이 증명되지는 않습니다.
  2. 고객이 기업에 직접 로그인해 동의합니다. PACT 설명에 따르면 고객은 로그인 링크에서 기업에 인증하고 필요한 권한을 승인합니다. 개인 에이전트는 고객 로그인 자격증명을 직접 다루지 않습니다.
  3. 승인 범위를 요청마다 검증합니다. 위임 토큰에는 확인된 고객 계정, 개인 에이전트 플랫폼, 대상 기업, 승인 범위가 연결됩니다. 기업 에이전트는 그 범위와 회사 정책 안에서 요청을 처리합니다.

추가 권한이 필요한 경우에는 같은 대화 안에서 권한을 요청하는 절차도 설명되어 있습니다. 위임된 권한으로 처리한 응답에는 사용한 권한과 수행한 작업을 기록하는 서명된 영수증이 포함됩니다. 다만 이 내용은 공개된 설계 설명이므로, 각 기업의 실제 시스템이 같은 방식으로 구현되었는지는 따로 확인해야 합니다.

AI 에이전트 보안, 실행 권한은 어디까지 허용해야 할까

업무에 필요한 범위만 허용하고, 조회와 변경을 나누어 승인하는 편이 좋습니다. 고객이 동의한 작업도 회사의 취소 정책이나 계정 접근 규칙을 충족해야 실행하도록 설계합니다.

PACT는 기업이 orders:read, orders:cancel처럼 권한 범위를 정의할 수 있다고 설명합니다. 읽기 권한과 취소 권한은 서로 다른 범위로 정의됩니다. 아래 표는 이 원칙을 고객 서비스에 적용하기 위한 AXMOS의 실무 제안입니다. 표의 모든 항목을 프로토콜이 직접 구현해 주는지는 따로 확인해야 합니다.

확인할 상황검증할 정보권장 처리
공개된 반품 규정 문의계정 접근이 필요한지개인정보 없이 공개 정보만 안내합니다.
내 주문 배송 조회고객 계정과 조회 동의동의한 계정의 주문만 조회합니다.
배송 조회 중 주문 취소 요청취소 권한과 회사 취소 정책조회 동의만 있다면 추가 권한을 확인합니다.
다른 고객 계정으로 요청 변경토큰에 연결된 계정과 요청 계정계정 불일치 상태에서 변경을 실행하지 않습니다.
승인 범위가 불명확한 요청작업 대상과 요청 내용고객에게 확인하거나 담당자에게 넘깁니다.

업무 담당자는 이 표를 개발팀에 넘기기 전에 실제 서비스 규칙을 채워 넣어야 합니다. 취소가 허용되는 시점, 상담원이 개입할 조건, 추가 동의를 받을 화면이 서로 맞지 않으면 기술적인 인증에 성공해도 업무는 잘못 처리될 수 있습니다. 권한 이름만 정하고 운영 규칙을 비워 두지 않는 것이 중요합니다.

고객 대리 AI 동향은 기업의 접점을 어떻게 바꾸나?

공식 발표에서 확인되는 변화는 고객 대리 AI의 접속 방식과 동의 절차를 공통 규칙으로 정하려는 움직임입니다. 다만 공개된 설계와 개발 계획을 이미 확정된 단일 산업 표준으로 표현해서는 안 됩니다.

Sierra는 Meta 및 업계 파트너들과 Personal Agent Protocol을 개발한다고 밝혔습니다. 기업이 기존 웹사이트, API, 자사 에이전트 가운데 이용할 접점을 정하고, 고객이 읽기 또는 쓰기 접근을 결정하는 방향입니다. 발표 당시에는 v0.1 명세를 2026년 10월 중 공개할 계획이라고 설명했으므로, 이 글에서도 완성된 명세의 보급 실적으로 다루지 않습니다.

Decagon은 PACT를 공개하면서 해당 작업반에도 참여한다고 밝혔습니다. PACT와 Personal Agent Protocol을 동일한 규격으로 합쳐 부르거나, 두 규격의 호환성이 이미 검증되었다고 해석할 근거는 이 발표들에 없습니다. 기업은 도입을 검토할 때 현재 구현된 기능과 향후 계획을 구분해 확인해야 합니다.

전화로 들어오는 AI를 다루는 움직임도 있습니다. Sierra의 fleming-1 발표는 Sierra 기반 음성 에이전트로 들어오는 통화 음성을 실시간으로 분석해 AI일 가능성이 높은 통화를 표시한다고 설명합니다. Sierra는 이 기능을 정보 제공용으로 소개하며, 대응 방식은 기업이 정하도록 했습니다. AI 음성으로 추정된다는 사실과 특정 고객을 대신할 권한이 있다는 사실은 서로 다릅니다.

이 구분은 접근성에도 중요합니다. Sierra는 음성 합성에 의존하는 사람과 정상적인 고객 대리 요청도 있을 수 있다고 설명합니다. 따라서 탐지 결과만으로 일괄 차단하기보다, 어떤 요청에서 추가 인증을 요구할지 정하는 편이 적절합니다. 이 자료에는 독립적으로 검증된 탐지 정확도나 고객사 전체의 성과 수치가 없으므로 그 효과를 수치로 단정하지 않습니다.

AI 에이전트 권한 관리는 PoC에서 무엇으로 검증하나?

정상 요청의 성공 여부와 권한 밖 요청의 차단 여부를 나누어 확인해야 합니다. 아래 항목은 AXMOS가 제안하는 도입 검수 기준이며, 특정 업체가 정한 인증 요건과는 별개입니다.

  1. 업무 한 건의 경계를 정합니다. 배송 조회처럼 대상 계정과 산출물이 분명한 업무를 고르고, 변경 작업이 필요한 구간을 따로 적습니다.
  2. 허용되지 않은 요청을 시험합니다. 조회 권한으로 취소를 시도하거나 다른 계정의 주문을 요청하는 테스트를 정상 요청과 함께 준비합니다.
  3. 동의가 달라질 때의 처리를 확인합니다. 토큰 만료, 권한 추가, 사용자 확인이 필요한 상황에서 처리 결과와 안내 문구가 일치하는지 살핍니다.
  4. 담당자가 결과를 재확인합니다. 고객이 승인한 작업, 실제 처리한 작업, 계정에 반영된 결과를 대조합니다. 처리 성공률만 집계하지 말고 추가 확인 건수와 잘못 허용한 요청도 구분해 기록합니다.

PoC를 통과할 기준은 서비스를 열기 전에 정하는 편이 좋습니다. 예를 들어 조회 업무는 자동 처리하되 취소는 담당자가 확인하는 범위로 시작할 수 있습니다. 이때 확인 담당자, 대응 시간, 미처리 요청을 돌려보내는 방법까지 운영 계획에 넣어야 합니다. 이 기준은 공식 성과 수치가 없으므로 회사마다 업무 위험에 맞춰 정해야 합니다.

실행 이후의 기록과 복구를 설계할 때는 AI 에이전트 승인 이력과 실행 로그도 함께 확인할 수 있습니다. 이 글의 초점은 사고 이후 추적보다 실행 전에 고객의 동의를 확인하는 데 있습니다.

자주 묻는 질문

Q. AI 에이전트 권한 관리란?

AI 에이전트가 누구를 대신해 어떤 작업까지 할 수 있는지 정하고, 실행할 때 그 범위를 확인하는 일입니다. 고객을 대리하는 경우에는 에이전트 신원과 고객이 승인한 권한을 따로 검증해야 합니다.

Q. 에이전트 인증이랑 권한 관리는 어떻게 하세요?

호출한 에이전트를 확인한 다음, 고객 계정과 승인 범위를 확인합니다. PACT는 두 정보를 분리하고 요청마다 함께 검증하는 구조를 설명합니다.

Q. AI 에이전트 보안, 실행 권한은 어디까지 허용해야 할까

업무에 필요한 범위만 허용하고 조회와 변경을 구분하는 편이 좋습니다. 주문 취소처럼 고객에게 영향을 주는 작업은 별도 동의와 회사 정책을 모두 충족하도록 설계합니다.

Q. PACT와 Personal Agent Protocol은 같은 규격인가요?

두 발표는 서로 다른 이름의 규격을 설명합니다. Decagon은 PACT를 공개하면서 Personal Agent Protocol 작업반에도 참여한다고 밝혔고, Sierra 발표는 별도 공동 개발 계획을 설명합니다.

Q. AI가 건 전화라고 판단되면 차단해야 하나요?

자동 차단이 정답이라고 볼 수는 없습니다. Sierra도 fleming-1이 정보를 제공할 뿐 대응은 기업이 결정한다고 설명하므로, 고객의 정상적인 대리 요청과 접근성 목적을 고려해야 합니다.

그래서 기업은 무엇을 해야 하나?

AXMOS는 고객 대리 AI를 받는 기업이 자동화할 업무와 허용할 권한을 같은 문서에서 정해야 한다고 봅니다. 조회와 변경을 구분한 뒤, 고객 동의와 회사 정책이 모두 맞을 때만 실행하도록 검수 기준을 마련하는 것이 출발점입니다.

2026년 10월 13일 확인한 공개 자료 기준으로, Decagon과 Sierra의 이번 발표는 고객 대리 AI와 기업 서비스가 연결되는 규칙에 초점을 둡니다. AXMOS 공개 소개는 전방 배치 엔지니어(FDE)가 현장의 업무 흐름을 진단하고, 시스템과 도구를 AI 중심으로 다시 설계한 뒤 검증·배포·운영까지 진행하는 방식을 설명합니다. 이 설명은 AXMOS가 PACT나 Personal Agent Protocol을 지원한다는 뜻이 아니며, 업체 간 성과를 비교한 내용도 아닙니다.

관련 개념은 AI 에이전트 글 모음에서 확인할 수 있습니다. 우리 회사의 고객 요청을 어디까지 자동 처리할지 정리하려면 AX 진단 문의하기에서 업무 범위부터 상담해 보세요.

출처

  1. Decagon, Introducing the Personal Agent Consent & Trust Protocol (PACT), 2026년 10월 6일
  2. Sierra, Introducing Personal Agent Protocol, 2026년 10월 6일
  3. Sierra, Caller ID in the age of agents
  4. AXMOS 한국어 공식 홈페이지