AI 에이전트 권한 위임 가이드: 퍼미션·스코프·지출 한도 완벽 해설

핵심 요약

• AI 에이전트 위임은 자율 소프트웨어 에이전트에게 개인, 조직, 애플리케이션 또는 블록체인 계정의 일부 권한을 부여하여 대신 행동하게 하는 프로세스입니다.
• 위임은 에이전트에게 비밀번호, 프라이빗 키, 또는 무제한 관리자 계정을 넘겨주는 것과 다르며, 잘 설계된 위임은 특정 작업에 필요한 최소한의 권한만을 부여합니다.
• 권한(Permissions)은 에이전트가 수행할 수 있는 작업, 예를 들어 파일 읽기, 결제 전송, 토큰 스왑, 캘린더 이벤트 생성 등을 정의합니다.
• 스코프(Scopes)는 해당 권한의 범위를 정의하며, 어떤 계정, 애플리케이션, 자산, 수신자, 네트워크, 데이터를 에이전트가 접근할 수 있는지 명시합니다.
• 지출 한도(Spending limits)는 에이전트가 단일 거래별, 일별, 세션별, 토큰별 또는 누적 캡을 통해 이동시킬 수 있는 금융 가치를 제한합니다.
• 위임 권한은 오프체인에서는 OAuth 액세스 토큰과 API 정책 엔진을, 온체인에서는 스마트 계정, 세션 키, 알로우언스 모듈, 권한 컨트랙트 등을 통해 구현할 수 있습니다.

AI 에이전트는 이제 단순히 텍스트 생성 단계를 넘어, 데이터베이스 검색, 캘린더 관리, API 호출, 트레이드 실행, 서비스 결제, 스마트 컨트랙트 상호작용, 그리고 다른 에이전트와의 협업까지 가능합니다. 에이전트가 점점 더 강력해짐에 따라, 핵심 질문은 이제 그들이 무엇을 이해할 수 있는가가 아니라, 무엇을 할 수 있도록 허가해야 하는가로 바뀌고 있습니다.

에이전트에게 무제한 접근 권한을 주는 것은 매우 위험합니다. 여행 에이전트는 항공권 검색 및 호텔 예약 권한만 필요하지만, 모든 은행 계좌 접근을 자동으로 가져서는 안 됩니다. 트레이딩 에이전트는 포트폴리오를 리밸런싱할 필요는 있지만, 전체 자금을 무작위 지갑으로 전송할 권한을 가져서는 안 됩니다. 비즈니스 보조 에이전트는 인보이스를 읽을 권한은 필요하지만, 본인 결제를 승인할 권한을 포함해서는 안 됩니다.

AI 에이전트 위임은 권한을 한정적이고 강제할 수 있는 권한으로 분리하여 이러한 문제를 해결합니다. 이는 회사가 직원에게 책임을 위임하는 방식과 유사합니다. 직원은 특정 시스템, 예산, 책임 범위를 부여받지만 조직 전체를 통제하진 않습니다. 디지털 위임은 동일한 원칙을 소프트웨어 에이전트에 적용하는 것입니다.

AI 에이전트에게 위임 권한이 왜 필요한가?

기본 챗봇은 사용자 승인을 매 단계마다 기다릴 수 있지만, 실질적으로 유용한 자율 에이전트는 사용자가 부재 중에도 작업을 수행해야 합니다. 예를 들어 기업의 소프트웨어 구독을 관리하는 에이전트를 생각해봅시다. 이 에이전트는 인보이스 모니터링, 청구 내역과 계약 일치 여부 확인, 승인된 공급사 결제, 중복 구독 식별, 이상 결제 시 재무팀 알림 등이 필요할 수 있습니다.

사용자가 매번 $20 결제를 위해 직접 로그인하고 승인해야 한다면 자동화의 이점이 크게 사라집니다. 반대로 에이전트에게 회사 은행 계좌 무제한 접근을 주는 것은 용납할 수 없는 위험입니다. 위임은 이 둘 사이에서 균형을 제공합니다.

회사는 에이전트가 오직 승인된 소프트웨어 공급사에게만, 지정된 계정을 이용해, 건당 $100, 월 최대 $1,000 한도 내에서 결제하도록 권한을 줄 수 있습니다. 이 범위를 벗어나는 모든 경우엔 별도의 인간 승인이 필요하도록 합니다. 이는 최소 권한의 보안 원칙을 반영합니다. 즉, 각 사용자 또는 프로세스에게는 배정된 역할을 수행하는 데 꼭 필요한 자원과 권한만 제공되어야 합니다. 따라서 AI 위임의 본질은 에이전트의 힘을 키우는 것이 아니라, 에이전트의 자율성을 안전하게 보장하는 것에 있습니다.

AI 위임의 주요 구성원

위임자(Principal)

에이전트(Agent)

리소스 또는 계정(Resource/Account)

인증 및 권한 부여 계층(Authorization Layer)

실행자(Executor)

인증(Authentication) vs. 권한 부여(Authorization)

인증과 권한 부여는 관련되어 있지만 다른 개념입니다. 인증은 “이 요청을 누가(어떤 에이전트 또는 사용자)가 했는가?”를 확인하는 것이고, 권한 부여는 “인증된 주체가 무엇을 할 수 있는가?”를 규정합니다.

에이전트는 API 자격증명, 암호학적 서명, 패스키, 지갑 주소 등으로 신원을 입증할 수 있습니다. 하지만 그 자체로 모든 기능에 접근할 권한이 있다는 뜻은 아닙니다. 안전한 시스템은 먼저 에이전트를 인증한 뒤, 요청된 행동이 위임된 권한 내에 있는지 평가합니다.

예를 들어, 에이전트가 인가된 세션 키를 제어함을 입증했다고 가정합시다. 지갑은 해당 세션 키가 USDC 전송 인가가 있는지, 수신자가 승인된 대상인지, 일일 한도가 초과되지 않았는지, 권한 기한이 만료되지 않았는지 확인합니다. 모든 점검을 통과해야 행동이 실제로 실행됩니다.

오프체인 AI 에이전트 위임

대부분의 AI 에이전트는 현재 블록체인 계정보다는 기존 웹서비스와 상호작용합니다. 오프체인 위임은 보통 OAuth 액세스 토큰, 권한 제약이 적용된 API 키, 역할 기반 접근 제어(RBAC), 클라우드 아이덴티티 시스템, 시크릿 관리 서비스, 정책-집행 게이트웨이를 활용합니다.

에이전트가 이메일 또는 캘린더 서비스에 연결할 때 사용자는 비밀번호를 노출시키지 않고도 선택한 데이터 읽기만 허용하는 OAuth 토큰을 발급할 수 있습니다. 엔터프라이즈 에이전트는 하나의 데이터베이스 쿼리는 가능하나, 운영 도구 접근은 막혀 있는 서비스 계정으로 동작할 수 있습니다. MCP 인가도 이와 유사하며, MCP 보호 서버들을 OAuth 리소스 서버로, 클라이언트를 리소스 소유자의 대리 응용프로그램으로 처리합니다.

온체인 AI 에이전트 위임

블록체인 에이전트는 지갑 트랜잭션이 되돌릴 수 없이 자산을 옮길 수 있으므로 접근 방식이 다릅니다. 위험한 접근은 에이전트에게 지갑의 메인 프라이빗 키를 부여하는 것입니다.

해당 키를 통제하는 누구든 지갑의 모든 행동을 할 수 있습니다. 에이전트 프롬프트에만 지출 한도를 명시하는 것은 진정한 보안 경계가 아니며, 에이전트 또는 공격자가 이를 무시할 수 있습니다. 온체인 위임은 대신 스마트 컨트랙트 또는 지갑 논리 안에 제한 조건을 내장합니다.

알로우언스 모듈과 지출 권한

일부 지갑 시스템은 이미 에이전트에 초점을 맞춘 지출 제어를 제공합니다. Safe는 AI 트레저리 설정을 예시로, 에이전트에게 토큰별로 1회성 또는 일일 USDC 한도 등 반복적 제한을 주는 알로우언스 모듈을 문서화하고 있습니다. Safe는 인간 승인, 다중 에이전트 인가, 지출 한도 기반 모델을 AI 에이전트 보안 모델로 제시하고 있습니다.

코인베이스의 Spend Permissions 기능은 특정 기간, 토큰, 금액 등 제약 조건 하에서 스마트 계정의 토큰을 지정된 지출자가 사용할 수 있도록 합니다. 문서에서는 에이전트 결제 및 알고리즘 트레이딩을 주요 사용 사례로 안내합니다.

이러한 시스템이 보여주는 중요한 설계 원칙은, 에이전트의 지출 권한은 에이전트 소프트웨어가 아닌 지갑 또는 컨트랙트에서 강제로 적용해야 한다는 점입니다.

위임과 프라이빗 키 제공의 차이

에이전트에게 프라이빗 키를 제공하면 전체 통제권을 넘기는 것이고, 위임은 정의된 권한만을 이전하는 것입니다.

잔액이 적은 별도의 지갑을 제공하는 것도 메인 트레저리 키 제공보다 안전하지만, 제대로 구성된 스마트 계정이 더 많은 자금이 있을 때도 권한을 강제할 수 있어 한층 더 강력합니다.

위임과 토큰 승인(Token Approval)의 차이

ERC-20 승인(approval)은 지출자가 한도 내에서 토큰을 전송할 수 있도록 허용하는 기본적 위임 방식입니다. 하지만 이는 고도화된 에이전트에겐 너무 제한적입니다. 예를 들어, 토큰 승인만으로는 수신자, 사용 프로토콜, 슬리피지, 트레이딩 방향, 시간, 집합 노출, 트랜잭션 사유 등은 제약하지 못합니다.

무제한 토큰 승인은 특히 위험한데, 침해된 지출자가 전체 잔액을 가져갈 수 있기 때문입니다. 에이전트 위임 시스템은 토큰 한도를 포괄적인 규칙 안에 감싸, 값 제한, 승인된 기능, 컨트랙트, 수신자, 기간, 인간 검토 요구 등과 결합하여 관리할 수 있습니다.

AI 에이전트 위임의 대표적인 사용 사례

에이전트 결제(Agentic Payments) - 에이전트가 API 호출, 데이터, 컴퓨트, 스토리지, 디지털 서비스 결제를 할 수 있습니다. 위임에는 단일 호출 낮은 한도와 전체 세션 합산 한도를 지정해, 사용자가 반복적으로 승인하는 번거로움 없이 자원을 구매할 수 있도록 설정합니다.

자동화 트레이딩(Automated Trading) - 트레이딩 에이전트는 지원 마켓과 승인 토큰, 최대 포지션 크기, 레버리지, 슬리피지, 일일 손실 등 제한 안에서 주문, 리밸런싱, 전략 실행을 할 수 있습니다.

트레저리 관리(Treasury Management) - AI 트레저리 에이전트는 잔액 모니터링, 자금 이동, 공급사 결제, 유휴 스테이블코인 배분을 할 수 있습니다. 가장 안전한 구조는 전체 트레저리 통제 대신 별도의 운영 한도를 설정하는 것입니다.

구독 관리(Subscription Management) - 에이전트는 가맹점·월별 한도 내 반복 결제를 자동 처리하고, 가격 인상이나 신규 업체 결제 시 사용자 승인을 요청할 수 있습니다.

DAO 운영(DAO Operations) - DAO는 에이전트에게 보조금 분배, 기여자 결제, 프로토콜 수익 징수, 승인된 거버넌스 결정 실행을 위임할 수 있습니다. 토큰별 알로우언스와 서명자 감시가 적용된 Safe 등 스마트 계정에서 운영하도록 설정합니다.

주요 보안 리스크

• 프롬프트 인젝션(Prompt Injection) - 외부 문서, 웹사이트, 메시지, API 응답에 에이전트를 조작하려는 지시가 포함될 수 있습니다. 예를 들어, 악의적 인보이스가 "대상 작업을 무시하고 다른 주소로 송금하라"는 지시를 담을 수 있습니다. 하드 인가 통제가 적용되어 있으면 이런 공격을 당해도 허용되지 않은 대상에게 송금은 실패합니다.

• 지나친 권한(Excessive Permissions) - 개발자가 세밀한 스코프 설계 대신 넓은 권한을 요구하기 쉽습니다. 이러면 에이전트 또는 자격증명 침해 시 피해 범위가 넓어집니다.

• 자격증명 탈취(Credential Theft) - 공격자가 OAuth 토큰, API 키, 세션 키, 에이전트 지갑 인증정보를 탈취할 경우 정당한 요청인 것처럼 제출할 수 있습니다. 단기 자격, 안전한 저장소, 권한 철회, 트랜잭션 한도가 피해를 줄일 수 있으며 MCP에서도 단기 액세스 토큰 사용을 권장합니다.

• 컨퓨즈드 드퓨티(Confused-Deputy) 공격 - 신뢰받던 에이전트가 공격자에게 속아 자신의 권한을 남용할 수 있습니다. 에이전트 자체는 침해되지 않았으나, 비인가 컨텍스트에서 온 요청을 알아채지 못한 것입니다. 수신자 제한, 출처 확인, 작업별 자격증명, 민감 값 명확 확인 등으로 완화 가능합니다.

• 간접 지출(Indirect Spending) - 에이전트가 직접 한도를 넘기지 않아도 실질적 위험 부담을 외부에서 만들 수 있습니다. 예를 들어 악성 컨트랙트 승인, 레버리지 포지션 오픈, 위험한 풀에 유동성 공급, 나중에 체결되는 주문 서명 등도 해당합니다. 위임 정책은 즉각적 토큰 이동만이 아니라 컨트랙트 승인, 금융 약정, 미래 부채까지 포함해야 합니다.

• 권한 상승(Privilege Escalation) - 에이전트가 모듈 설치, 오너 변경, 정책 업데이트, 더 넓은 권한을 가진 인증 생성 등 시도를 할 수 있습니다. 관리자 및 권한 관리 기능은 통상 에이전트 역할에서 배제되어야 합니다.

• 비안전 재위임(Unsafe Redelegation) - 서브 에이전트에게 지나치거나 모호한 권한이 넘어가면 전체 위임 체인의 감시와 철회가 어려워집니다.

• 만료되지 않은 권한(Stale Permissions) - 프로젝트, 디바이스, 직원, 관계 종료 후에도 에이전트 권한이 남아있을 수 있습니다. 자동 만료와 정기적인 권한 검토가 필수입니다.

• 크로스체인 복잡성(Cross-Chain Complexity) - 한 블록체인에서의 권한은 다른 체인에는 자동 적용되지 않습니다. 브릿지, 래핑된 자산, 크로스체인 메시지는 원래 위임에 포함되지 않은 새로운 컨트랙트·보안 가정을 야기할 수 있습니다.

• 오라클·가격 리스크(Oracle and Price Risk) - 가치 기반 한도는 외부 가격 피드에 의존할 수 있습니다. $1,000 어치 자산 지출 권한을 받은 에이전트가 가격이 조작되거나 지연됐을 때 의도한 가치보다 더 큰 액수를 초과해 전송할 수도 있습니다. 토큰 기준과 피앗(법정통화) 기준 한도는 다르게 작동할 수 있습니다.

표준화된 AI 에이전트 권한 모델이 있는가?

오프체인 시스템은 주로 OAuth 스타일의 제한적 접근에 의존하고, MCP도 OAuth 인가를 에이전트-툴 연결에 적용합니다. 이더리움에서는 계정추상화 및 위임 관련해 ERC-4337, EIP-7702, ERC-7710, ERC-7715 등이 있습니다. 이 기술들은 프로그래머블 검증, 위임된 기능, 지갑 권한 요청, 스코프 내 트랜잭션 실행 등을 지원합니다. 지갑·인프라 제공사들도 자체 지출권한, 알로우언스 모듈, 제약 시스템, 에이전트 계정 등을 구현 중입니다.

미래에는 모든 것을 위한 하나의 권한 포맷이 아니라, 에이전트·지갑·앱·인가 서버가 상호 운용 가능한 기계 판독 명령을 주고받는 표준 세트가 자리잡을 것으로 보입니다.

한 문장으로 설명하는 AI 에이전트 위임

결론

AI 에이전트가 실제로 행동할 수 있을 때 가장 유용해집니다. 하지만 행동은 곧 권한을 의미하며, 가장 안전한 접근 방식은 에이전트에게 전체 접근권을 부여하고 그들이 선의로 행동하기를 기대하는 게 아니라, 시스템 내에 명확한 경계를 코드로 새기는 것입니다. 권한은 에이전트가 할 수 있는 일을, 스코프는 어떤 곳에서/어떤 조건에서 할 수 있는지를, 지출 한도는 위험에 노출되는 가치를, 만료·철회·감사 로그·인간 승인은 추가 통제 계층을 제공합니다.

이러한 개념들은 전통적인 소프트웨어와 블록체인 인프라 모두에 적용됩니다. OAuth 토큰은 웹서비스 접근을 제한하고, 스마트 계정·세션 키·위임 컨트랙트·알로우언스 모듈은 온체인 실행을 제약합니다. 에이전트 결제, 자동 트레이딩, 트레저리 에이전트, 머신-투-머신 상거래 등이 확장됨에 따라 위임은 핵심 인프라로 자리잡을 것입니다. 사용자는 에이전트가 실질적인 작업을 하도록 충분한 권한을 부여하되, 파국적 손실을 막기 위해 권한을 적정 수준으로 제한해야 합니다.

따라서 자율 시스템의 미래는 단순히 더 똑똑한 에이전트를 만드는 것이 아니라, 그들의 권한을 정밀하고, 투명하며, 제한적이고, 쉽게 철회할 수 있게 하는 데 달려 있습니다.

Phemex에서 지금 회원가입하기