.svg)
AI 솔루션 문의하기
AI 에이전트 API 위임은 에이전트가 사용자를 대신해 외부 시스템의 API를 호출할 수 있도록 작업 범위와 유효기간을 제한해 권한을 부여하는 방식입니다. 사람이 직접 버튼을 누르는 것과 달리, 에이전트가 여러 시스템에서 작업을 이어 가기 때문에 누가 요청했는지뿐 아니라 누구를 대신해 무엇을 실행하는지를 함께 확인해야 합니다.
인증(Authentication)은 요청 주체가 누구인지 확인하는 절차이고, 인가(Authorization)는 그 주체가 특정 기능을 실행할 권한이 있는지 판단하는 절차입니다. 인증된 에이전트라도 모든 고객 정보 조회나 송금 API를 호출할 수 있는 것은 아닙니다. 또한 사용자가 로그인했다는 사실만으로 향후 에이전트의 모든 실행을 승인한 것으로 볼 수 없습니다.
OAuth 2.0은 접근 권한을 위임할 때 활용하는 프로토콜이며, JWT는 토큰에 정보를 담아 전달할 수 있는 형식입니다. 두 개념은 같은 분류의 인증 방법이 아닙니다. 위임 환경에서 중요한 것은 토큰의 형식 자체보다 실제 API 서버가 허용 범위·대상·만료·철회 상태를 검사하는지 여부입니다.
일반적인 인증 API 구현이나 API 키·토큰 관리 방식이 필요하다면 기존 글인 인증 API 연동 가이드와 API 인증 관리 가이드를 참고할 수 있습니다. 여기서는 그다음 단계인 AI 에이전트의 대리 실행 권한에 집중합니다.
AI 에이전트에 권한을 맡길 때는 사용자 계정의 전체 권한을 그대로 넘기는 방식보다 업무 단위로 제한된 위임 권한을 발급하는 방식이 적합합니다. 예를 들어 회계 담당자가 세금계산서 확인을 맡겼다면 에이전트에는 필요한 문서 조회 권한만 부여하고, 거래처 계좌 변경이나 자금 이체 권한은 제외할 수 있습니다.
설계 단계에서 다음 항목을 구분해야 합니다.
가령 경비 처리 에이전트에 invoice:read와 expense:draft 권한만 주면, 관련 자료를 읽고 결재 초안을 만드는 업무까지 허용하는 설계를 고려할 수 있습니다. payment:execute는 발급하지 않거나 별도의 승인 경로로 분리합니다. 이 권한 이름은 구조를 설명하기 위한 예시이며, 실제 명칭과 집행 조건은 회사의 API 정책에 따라 달라집니다.
위임에는 시작 시각·만료 시각·철회 조건이 함께 필요합니다. 보고서 한 건을 생성하도록 맡겼다면 해당 작업이 끝났을 때 권한을 종료하는 방식이 적절합니다. 정기 업무라면 만료 후 새로 권한을 발급할지, 어떤 조건에서 사람의 재확인을 받을지 정책으로 정해야 합니다.
토큰의 exp 같은 만료 정보만 검사해서는 중도 철회를 모두 처리할 수 없습니다. 사용자가 위임을 취소하거나 직원의 직무가 변경되면 API 게이트웨이 또는 권한 서버가 현재의 위임 상태를 반영해 요청을 차단해야 합니다. 위임 철회와 토큰 만료는 별개의 통제입니다.
위임 흐름은 에이전트가 직접 권한을 선언하는 구조가 아니라, 사용자 승인과 권한 서버의 발급 결과를 API 실행부가 독립적으로 검증하는 구조로 설계해야 합니다. 다음은 기업 내부 시스템에서 적용할 수 있는 예시입니다.
사용자 계정의 자격 증명을 에이전트가 그대로 사용하는 계정 가장 방식은 실제 실행 주체를 구분하기 어렵게 만듭니다. 반면 위임 구조에서는 원래 사용자와 대리 실행 주체를 구분해 기록할 수 있습니다. OAuth 2.0 Token Exchange의 subject_token과 actor_token, JWT의 act 클레임 등은 이러한 관계를 표현하는 데 사용할 수 있지만, 토큰 교환 표준을 도입했다고 승인·철회·감사가 자동으로 완성되는 것은 아닙니다.
고위험 API 호출은 사전 위임만으로 실행하기보다 최종 실행 직전에 사람의 명시적 승인을 받도록 분리하는 것이 안전합니다. 예를 들어 에이전트가 거래처 정보를 조회하고 지급 요청서를 작성하는 것까지는 자동화하더라도, 계좌 변경·자금 이체·권한 확대·대량 삭제는 별도의 승인 대상으로 분류할 수 있습니다.
예를 들어 에이전트가 특정 거래처에 대금을 이체하려 할 때의 승인 흐름은 다음과 같습니다.
얼굴 인증은 승인권자가 누구인지 확인하는 수단이지, 거래에 동의했다는 의사표시 자체를 대체하지는 않습니다. 따라서 승인 버튼, 승인권자의 권한 검증, 얼굴 인증 결과를 각각 확인해야 합니다. 인증 실패·승인 거절·시간 초과 시에는 고위험 호출을 실행하지 않도록 구성합니다.
고위험 API 실행 직전에 승인자가 등록된 본인과 동일한 사람인지 재확인하려면 알체라 eKYC의 얼굴 인증 기능을 연동할 수 있습니다. 알체라는 얼굴 매칭·얼굴 위변조 판별 기능을 API·SDK 형태로 제공하므로, 기업은 자체 승인 화면에서 인증 절차를 호출하고 결과에 따라 실행을 보류하거나 다음 검증 단계로 넘기는 흐름을 설계할 수 있습니다. 다만 에이전트 권한 발급, 위임 범위 결정, 거래 승인 기록과 최종 API 실행 통제는 도입 기업의 시스템에서 별도로 구현해야 합니다.
권한 위임 기능은 처음 발급할 때보다 예외 상황이 발생했을 때 실행을 어디서 멈추는지가 중요합니다. 에이전트의 계획이 도중에 변경되거나, 외부 문서의 잘못된 지시를 읽거나, 사용자가 권한을 철회하는 경우에도 실제 API 실행부의 통제가 유지되어야 합니다.
기업이 구현해야 할 구성은 크게 권한·승인 관리 계층과 사용자 신원확인 계층으로 나뉩니다. 전자는 위임 토큰, 허용 범위, 거래별 승인, API 접근 차단과 감사 기록을 담당합니다. 후자는 고위험 승인 시점에 승인자의 실제 신원을 재확인합니다. 이 둘을 연동하더라도 신원확인 성공만으로 API 호출 권한이 자동으로 늘어나서는 안 됩니다.
알체라의 API·SDK는 이러한 구조 중 얼굴 인증이 필요한 구간에 적용할 수 있습니다. 구현 전에는 인증 결과를 어떤 거래 요청에 연결할지, 재인증을 요구하는 위험 조건이 무엇인지, 실패 시 승인 상태를 어떻게 처리할지 기업 정책을 먼저 정리해야 합니다. API·SDK 사용 방식이나 일반 인증 시스템 구축 내용은 앞에서 연결한 기존 블로그 글과 구분해 검토하는 것이 좋습니다.
AI 에이전트 API 위임을 설계할 때 기준은 에이전트의 자동 실행 능력이 아니라 사용자가 허용한 범위 안에서만 실행되는지입니다. 기존 사용자 인증 체계를 그대로 재사용하는 것만으로는 위임의 대상, 기간, 철회와 고위험 실행 승인까지 관리하기 어렵습니다.
도입 전에는 다음을 점검할 수 있습니다.
최종적으로 OAuth·JWT는 위임 권한을 전달하고 검증하는 기술적 수단, 사람 승인은 실행 의사를 확인하는 절차, 얼굴 인증은 그 승인자가 본인인지 확인하는 절차로 역할을 분리해야 합니다. 이렇게 구성해야 에이전트의 반복 업무 자동화와 고위험 작업의 사람 통제를 함께 운영할 수 있습니다.
.png)
.svg)
.svg)
