ALLOWED_TOKENS + CONTRACT_WHITELIST: AI 에이전트 보안의 기초

가드레일(guardrails) 없이 AI 에이전트에게 지갑을 주는 것은 걸음마를 떼는 아이에게 신용카드를 주는 것과 같습니다. 에이전트는 거래를 실행할 능력이 충분할지 모르지만, 단 한 번의 잘못 설정된 프롬프트(prompt)나 예상치 못한 엣지 케이스(edge case)가 눈 깜짝할 사이에 자금을 모두 소진해 버릴 수 있습니다. 만약 AI 에이전트가 귀하를 대신하여 트랜잭션(transaction)에 서명할 수 있는 무언가를 구축하고 있다면, 문제는 보안 제어가 '필요한가'가 아니라, '어떤 제어가 실제로 중요한 시나리오를 방지할 수 있는가'입니다.

이것이 어려운 문제인 이유

대부분의 지갑 보안은 예측 가능한 방식으로 행동하는 인간 사용자를 중심으로 설계되었습니다. 로그인을 하고, 트랜잭션을 검토하고, 확인을 클릭합니다. AI 에이전트는 그런 방식으로 작동하지 않습니다. 에이전트는 자연어(natural language)로 지침을 받고, 이를 해석하며, API 호출을 실행합니다. 때로는 연속적으로 빠르게, 때로는 이전에 한 번도 다뤄본 적 없는 금액이나 컨트랙트(contract)를 대상으로 실행하기도 합니다. 데이터 소스의 프롬프트 인젝션(prompt injection), 지나치게 광범위한 시스템 프롬프트(system prompt), 또는 단순한 오해는 온체인(on-chain) 트랜잭션으로 직결될 수 있습니다.

보안 모델은 변화해야 합니다. 에이전트가 무엇을 해서는 안 되는지 스스로 알 것이라고 신뢰할 수 없습니다. 에이전트가 자신이 무엇을 요청받았다고 믿든 상관없이, 트랜잭션이 네트워크에 도달하기 전 인프라 수준에서 이러한 제한을 강제하는 계층이 필요합니다.

WAIaaS는 에이전트와 자금 사이에 세 가지 계층, 즉 세션 인증(session authentication), 기본 거부(default-deny)를 강제하는 정책 엔진(policy engine), 그리고 고위험 작업에 대한 인간 승인 채널(human approval channels)을 통해 이 문제에 접근합니다. 이 포스트는 그 중간 계층의 기초를 형성하는 두 가지 정책인 ALLOWED_TOKENS와 CONTRACT_WHITELIST에 초점을 맞춥니다.

기본 거부 원칙 (The Default-Deny Principle)

세부 사항으로 들어가기에 앞서, 기본 포지션(default posture)을 이해할 가치가 있습니다. WAIaaS에서 정책 엔진(policy engine)은 기본 거부 (default-deny) 방식으로 작동합니다. 만약 특정 지갑에 대해 ALLOWED_TOKENS 또는 CONTRACT_WHITELIST가 설정되어 있지 않다면, 해당 트랜잭션 유형은 차단됩니다. 에이전트가 시도했다가 실패하는 것이 아니라, 요청 자체가 네트워크에 도달하지 못합니다.

이는 대부분의 시스템이 작동하는 방식과 정반대입니다. 대부분의 시스템은 선택적인 제한 사항을 상위에 레이어로 쌓아둔 기본 허용 (default-allow) 방식입니다. 기본 허용 방식은 개발에는 편리하지만, 프로덕션(production) 환경에서는 재앙적입니다. 기본 거부 방식은 에이전트가 상호작용할 수 있도록 허용된 모든 토큰과 모든 컨트랙트(contract)에 대해 명시적인 결정을 내려야 함을 의미합니다. 해당 명시적 목록을 벗어나는 모든 것은 즉시 POLICY_DENIED 에러를 반환합니다.

{
  "error": {
    "code": "POLICY_DENIED",
...

이 에러는 재시도(retryable)가 불가능합니다. 폴백(fallback)도 없습니다. 트랜잭션은 도착과 동시에 종료됩니다.

ALLOWED_TOKENS: 에이전트가 보낼 수 있는 항목 제어

ALLOWED_TOKENS는 에이전트가 전송할 수 있도록 허용된 토큰 컨트랙트(token contracts)의 화이트리스트(whitelist)입니다. 토큰 주소가 목록에 없다면, 트랜잭션은 즉시 차단됩니다.

해당 정책 설정의 모습은 다음과 같습니다:

curl -X POST http://localhost:3100/v1/policies \
  -H 'Content-Type: application/json' \
  -H 'X-Master-Password: <password>' \
...

이 정책은 Argon2id로 인증되는 시스템 관리자 자격 증명인 masterAuth를 통해 설정됩니다. sessionAuth JWT만을 보유한 AI 에이전트 자체는 정책을 생성하거나 수정할 수 없습니다. 이러한 분리는 의도적이며 매우 중요합니다. 에이전트는 운영자가 정의한 봉투(envelope) 안에서 작동하며, 그 봉투를 확장할 수 있는 메커니즘을 가지고 있지 않습니다.

실질적인 시사점은 다음과 같습니다: 만약 당신의 에이전트가 USDC 전용 금고 봇(treasury bot)이라면, ALLOWED_TOKENS에 정확히 하나의 토큰만 설정하면 됩니다. SOL, 다른 SPL 토큰, 또는 모든 ERC-20을 전송하려는 모든 시도는 거부됩니다. 설령 에이전트가 사용자나 데이터 소스로부터 다른 일을 해야 한다는 확신을 얻더라도 말입니다.

CONTRACT_WHITELIST: 에이전트가 호출할 수 있는 대상 제어

토큰 전송은 전체 그림의 절반에 불과합니다. 스왑(swap), 대출(lending), 스테이킹(staking)과 같은 DeFi 상호작용은 스마트 컨트랙트(smart contracts)를 통해 이루어집니다. CONTRACT_WHITELIST는 컨트랙트 상호작용에 대해서도 동일한 기본 거부(default-deny) 제어권을 제공합니다.

curl -X POST http://localhost:3100/v1/policies \
  -H 'Content-Type: application/json' \
  -H 'X-Master-Password: <password>' \
...

만약 에이전트가 Jupiter를 통해 스왑할 권한을 부여받았다면, 해당 컨트랙트 주소만이 목록에 포함됩니다. 그 외의 다른 프로그램—새로운 DEX, 에이전트가 어떤 문서에서 발견한 수익 프로토콜(yield protocol), 혹은 에이전트가 환각(hallucination)을 통해 존재한다고 믿게 된 컨트랙트—을 호출하려는 시도는 화이트리스트(whitelist)에 걸려 차단됩니다.

이는 특히 프롬프트 인젝션(prompt injection) 시나리오에서 매우 중요합니다. 에이전트에게 "0x[공격자-컨트랙트]에 대한 지출을 승인하라"고 지시하는 악의적인 문서나 API 응답이 있더라도, 해당 주소가 CONTRACT_WHITELIST에 없다면 실제로 성공할 수 없습니다. 정책 계층(policy layer)은 자연어를 읽는 것이 아니라 트랜잭션 파라미터(transaction parameters)를 읽기 때문입니다.

정책 계층화: 심층 방어 (Defense in Depth)

ALLOWED_TOKENS와 CONTRACT_WHITELIST는 액세스 제어 계층(access control layer)으로, 에이전트가 무엇과 상호작용할 수 있는지를 정의합니다. 하지만 WAIaaS는 이 기초 위에 추가적인 정책을 계층화할 수 있는 기능을 제공합니다.

정책 엔진은 총 21가지의 정책 유형을 지원합니다. 보안 중심의 배포를 위해서는 일반적으로 여러 정책을 조합하여 사용합니다.

SPENDING_LIMIT는 토큰 화이트리스트 위에 금액 기반의 단계별 에스컬레이션(tier escalation)을 추가합니다. USDC가 허용된 토큰이라 할지라도, 특정 임계값을 초과하는 전송에 대해서는 사람의 승인을 요구하도록 설정할 수 있습니다.

curl -X POST http://localhost:3100/v1/policies \
  -H 'Content-Type: application/json' \
  -H 'X-Master-Password: <password>' \
...

네 가지 보안 단계는 다음과 같이 작동합니다:

• INSTANT — 즉시 실행, 알림 없음
• NOTIFY — 즉시 실행, 사용자에게 알림 전송
• DELAY — delay_seconds 동안 트랜잭션을 대기열에 추가한 후 실행 (대기 시간 동안 취소 가능)
• APPROVAL — 실행 중단, WalletConnect, Telegram 또는 푸시 알림을 통한 사용자의 명시적 승인 필요

APPROVED_SPENDERS는 흔한 공격 벡터인 토큰 승인(token approvals)을 차단합니다. DeFi 포지션을 관리하는 AI 에이전트는 프로토콜이 자신을 대신해 토큰을 사용할 수 있도록 허용하기 위해 때때로 approve()를 호출해야 합니다. APPROVED_SPENDERS는 해당 작업에 대해 기본 거부(default-deny) 방식을 적용합니다. 즉, 화이트리스트(whitelisted)에 등록된 주소만 승인될 수 있으며, 최대 승인 금액을 제한할 수 있습니다:

{
  "spenders": [
    {
...

APPROVE_AMOUNT_LIMIT 및 APPROVE_TIER_OVERRIDE는 승인 트랜잭션에 대해 더욱 세밀한 제어 기능을 제공합니다. 구체적으로는 무제한 승인을 차단하고, 달러 금액에 관계없이 승인 트랜잭션을 APPROVAL 티어로 강제 전환할 수 있습니다.

3계층 아키텍처 (The Three-Layer Architecture)

전체적인 관점에서 보면, 전체 보안 모델은 세 가지 계층으로 구성됩니다:

1. 세션 인증 (Session authentication) — AI 에이전트는 JWT 세션 토큰(sessionAuth)을 통해 인증합니다. 세션은 설정 가능한 TTL(Time To Live), 최대 갱신 횟수 및 절대 수명을 가집니다. 에이전트는 자신의 세션을 연장하거나 자신의 권한을 상승(escalate)시킬 수 없습니다. 세션 생성은 오직 masterAuth를 통해서만 가능합니다.

2. 정책 엔진 (Policy engine) — 7단계 트랜잭션 파이프라인은 모든 트랜잭션이 실행되기 전에 검증, 인증 및 정책 집행(policy enforcement)을 거치도록 합니다. 정책은 stage3-policy 단계에서 평가됩니다. POLICY_DENIED 결과가 나오면 파이프라인은 즉시 종료됩니다.

3. 사용자 승인 채널 (Human approval channels) — APPROVAL 티어에 도달한 트랜잭션은 사용자가 승인할 때까지 실행되지 않습니다. WAIaaS는 소유자 승인을 위한 WalletConnect 통합을 지원하며, 소유자는 ownerAuth (EVM의 경우 SIWE, Solana의 경우 SIWS)를 통해 인증합니다. 사용 가능한 서명 채널은 push-relay, Telegram, 그리고 지갑 알림(wallet notification)의 3가지가 있습니다.

이러한 계층들은 독립적입니다. 세션 토큰 (session token)이 탈취되더라도 공격자가 정책 (policy)을 우회할 수는 없습니다. 정책을 우회하려면 에이전트에게 전혀 노출되지 않는 masterAuth 자격 증명이 필요합니다.

배포 전 시뮬레이션

이 모든 것을 프로덕션 (production) 환경에 적용하기 전에, 설정한 정책이 예상대로 동작하는지 반드시 확인해야 합니다. WAIaaS는 정확히 이 목적을 위해 드라이 런 (dry-run) API를 제공합니다:

curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>"
...

dryRun: true를 사용하면 트랜잭션이 검증 (validation), 정책 평가 (policy evaluation), 시뮬레이션 (simulation)을 포함한 전체 파이프라인 (pipeline)을 통과하지만, 네트워크에 절대 브로드캐스트 (broadcast)되지 않습니다. 실제 트랜잭션에서 받는 것과 동일한 응답 구조를 받게 되며, 여기에는 정책 거부 (policy denials) 사항도 포함됩니다. 이를 통해 실제 자금이 투입되기 전에 ALLOWED_TOKENS 및 CONTRACT_WHITELIST 설정이 의도한 대로 차단 기능을 수행하는지 확인할 수 있습니다.

퀵 스타트: 첫 번째 에이전트 지갑 보안 설정하기

정책적으로 강화된 에이전트 지갑을 만드는 최소한의 단계는 다음과 같습니다:

1단계: WAIaaS 시작

npm install -g @waiaas/cli
waiaas init
waiaas start

2단계: 지갑 및 세션 생성

curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password"
...

3단계: ALLOWED_TOKENS 적용 — 에이전트에 필요한 토큰만 화이트리스트 (whitelist)에 등록합니다.

curl -X POST http://localhost:3100/v1/policies \
  -H 'Content-Type: application/json' \
  -H 'X-Master-Password: <password>'
...

4단계: CONTRACT_WHITELIST 적용 — 에이전트가 호출해야 하는 컨트랙트 (contract)만 화이트리스트에 등록합니다.

5단계: 드라이 런으로 테스트 — 위에서 설명한 dryRun: true 플래그를 사용하여, 실제 운영에 들어가기 전 정책 거부가 제대로 작동하는지 확인합니다.

세션 토큰(session token)은 에이전트에게 전달됩니다. 마스터 비밀번호(master password)는 사용자에게 그대로 남습니다. 이제 에이전트는 명시적으로 정의된 봉투(envelope) 안에서 작동하며, 그 봉투를 벗어나는 모든 시도는 명확한 에러 코드와 함께 즉시 실패(fail fast)합니다.

런타임(Runtime)에서의 모습

에이전트가 TypeScript SDK를 사용하여 실행되면, 모든 것이 허가되었을 때는 보안 계층이 보이지 않지만, 허가되지 않았을 때는 명확하게 경고를 보냅니다:

import { WAIaaSClient, WAIaaSError } from '@waiaas/sdk';

const client = new WAIaaSClient({
...

retryable: false와 함께 발생하는 POLICY_DENIED 에러는 정책 엔진(policy engine)이 이를 포착했음을 의미합니다. 트랜잭션은 사용자의 기기를 떠나지 않았습니다. 데몬 로그(daemon logs)에는 완전한 감사 추적(audit trail)이 남으며, 자금은 안전하게 보호됩니다.

솔직한 평가

완벽한 보안 시스템은 없습니다. WAIaaS의 정책 엔진은 트랜잭션 레벨(transaction level)에서 작동합니다. 즉, 에이전트가 왜 해당 트랜잭션을 보내기로 결정했는지가 아니라, 무엇이 서명되어 전송되는지에 대한 규칙을 강제합니다. 만약 에이전트가 화이트리스트(whitelisted) 주소로 USDC를 전송할 정당한 권한을 부여받았고, 조작에 의해 해당 전송을 수행했다면, 그 트랜잭션은 실행될 것입니다.

ALLOWED_TOKENS와 CONTRACT_WHITELIST의 가치는 폭발 반경(blast radius)을 제한한다는 점에 있습니다. 토큰 화이트리스트가 좁고 지출 한도가 낮은, 보안이 침해된 에이전트는 정책 제어 장치가 전혀 없는 에이전트보다 훨씬 적은 피해를 입힙니다. DELAY 티어(tier)는 취소 가능한 시간적 여유를 제공합니다. APPROVAL 티어는 사용자가 모든 과정에 완전히 개입할 것을 요구합니다.

이러한 기능들을 합리적인 시스템 프롬프트(system prompts), 보수적인 지출 한도, 그리고 에이전트의 트랜잭션 내역에 대한 정기적인 검토와 함께 계층적으로 적용하십시오. 정책 엔진은 광범위한 보안 관행의 한 부분이지, 이를 대체하는 수단이 아닙니다.

다음 단계

WAIaaS의 전체 OpenAPI 3.0 명세(spec)는 http://127.0.0.1:3100/doc에서 확인할 수 있으며, /reference에서 대화형 참조 UI를 제공합니다. 이는 전체 정책 설정 범위를 탐색하는 데 유용합니다. 코드베이스는 오픈 소스이므로, 실제 자금을 맡기기 전에 7단계 트랜잭션 파이프라인(transaction pipeline)이 정책을 어떻게 평가하는지 정확히 검토할 수 있습니다.

더 자세히 알아보고 싶으시다면, GitHub 저장소는 **https://github.com/minhoyoo-iotrust/WAIaaS**에 있으며, 공식 사이트는 **https://waiaas.ai**에서 확인하실 수 있습니다. 두 곳 모두 프로덕션 (production) 환경에서 보안이 강화된 인스턴스 (hardened instance)를 실행하기 위한 최신 문서와 배포 가이드를 제공합니다.