AI 에이전트와 당신의 자산 사이의 4가지 체크포인트

저는 실제로 돈을 쓸 수 있는 AI 에이전트인 wallet-agent를 구축했습니다. 당신이 "이게 1달러 미만이면 구매해"라고 말하면, 에이전트는 가서 확인한 뒤, 돈을 쓰기 전에 멈춰서 당신에게 물어봅니다. 마지막 부분이 간단하게 들릴 수도 있습니다. "에이전트가 허가를 요청한다"는 말은 단 한 문장이니까요. 하지만 Amazon Bedrock AgentCore, 암호화폐 지갑(crypto wallet), 실제 서명(signature)을 통해 결제를 실제로 연결해 보니, 그 한 문장 뒤에 완전히 다른 네 가지 질문이 숨겨져 있으며, 각 질문에는 저마다의 답변이 필요하다는 것을 깨달았습니다. 여기서는 돈이 실제로 이동하는 순서에 따라 이 네 가지 질문을 모두 살펴보고, 제가 답변하지 못했고 아마도 답변했어야 했던 한 가지 질문에 대해서도 다룹니다.

왜 "그냥 허가를 구하는 것"만으로는 충분하지 않은가

새로운 직원에게 신용카드를 건네며 "무엇이든 사기 전에 나에게 확인해"라고 말하는 상황을 상상해 보세요. 그 한 가지 지시사항은 사실 당신이 생각조차 못 하고 있는 수많은 가정들에 의존하고 있습니다. 이 사람이 정말 당신이 고용한 직원인가요, 아니면 직원인 척하는 누군가인가요? 그들이 사용할 수 있는 금액은 얼마이며, 얼마 동안 허용되나요? 그들이 계산대 직원에게 카드를 건넬 때, 그것은 실제로 누구의 카드인가요? 그리고 그들이 돌아와서 "당신이 괜찮다고 했잖아요"라고 말할 때 — 당신이 정말 그렇게 말했나요, 아니면 누군가 거짓말을 하고 있는 건가요?

돈을 쓸 수 있는 AI 에이전트는 정확히 똑같은 네 가지 질문에 답해야 합니다. 다만, 그 어떤 답변도 "나는 이 사람의 얼굴을 알아본다"와 같은 방식에 의존할 수 없다는 점이 다릅니다. 모든 것은 컴퓨터가 확인할 수 있는 무언가로 증명되어야 합니다. wallet-agent가 각 질문에 어떻게 답하고 있는지, 그리고 현재는 답하지 못하고 있는 부분은 어디인지 소개합니다.

체크포인트 1: 지금 말하고 있는 것이 정말 나의 에이전트인가?

첫 번째 질문은 아직 돈과는 관련이 없습니다. 더 단순합니다. 어떤 무언가가 Amazon의 결제 서비스(payment service)를 호출하며 "이 지갑을 사용하게 해주세요"라고 말할 때, Amazon은 그 요청이 누군가 작성한 무작위 스크립트가 아니라 정말로 나의 에이전트로부터 온 것이라는 사실을 어떻게 알 수 있을까요?

그 답은 AWS의 IAM 역할 (IAM role)이라고 불리는 일종의 ID 배지입니다. 저는 이 에이전트를 위해 특별히 하나를 생성했고, AWS에 두 가지를 말했습니다. 오직 나의 에이전트 런타임 (runtime)만이 이 배지를 착용할 수 있으며, 배지를 착용하고 있더라도 오직 이 특정 결제 설정에 대해서만 요청할 수 있고 다른 사람의 설정은 요청할 수 없다는 것입니다.

{
  "Effect": "Allow",
  "Principal": { "Service": "bedrock-agentcore.amazonaws.com" },
...

AWS 용어를 풀어서 설명하자면 다음과 같습니다: "오직 AgentCore 서비스 자체만이 이 배지를 발급할 수 있으며, 오직 내 계정의 요청에 대해서만, 그리고 이름이 walletagentpm으로 시작하는 결제 설정에 대해서만 발급할 수 있다." 이는 사진이 박혀 있을 뿐만 아니라, 오직 열어야 할 단 하나의 문만 열 수 있는 배지와 같습니다. 이것이 없다면, 잘못된 손에 들어간 유효한 AWS 자격 증명 (AWS credentials)을 가진 무엇이든 나의 에이전트인 척하며 결제 시스템을 건드리려 할 수 있습니다.

이 체크포인트는 **"누가 요청하는가?"**에 대한 답을 줄 뿐이며, 그 이상은 아닙니다. 아직 그들이 얼마를 쓸 수 있는지에 대해서는 말하지 않습니다.

체크포인트 2: 얼마나, 그리고 언제까지?

체크포인트 1을 통과하면 에이전트는 문 안으로 들어올 수 있게 됩니다. 하지만 그렇다고 해서 백지수표를 쥐여주는 것은 아닙니다. 두 번째 질문은 이것입니다: 설령 이것이 정말로 나의 에이전트라 할지라도, 현재 실제로 무엇을 할 수 있도록 허용되어 있는가?

여기에서 결제 세션 (payment session)이 등장합니다. 이는 현재의 대화 동안에만 존재하는 일시적이고 일회용인 허가증입니다. 제가 에이전트와 새로운 채팅을 시작하고 지출 한도를 부여할 때마다, 에이전트는 해당 한도가 포함되어 있고 만료 시간 (expiry time)이 설정된 새로운 세션을 생성합니다:

sess_resp = dp.create_payment_session(
    userId=user_id,
    paymentManagerArn=manager_arn,
...

마치 부모가 아이에게 딱 5달러가 충전되어 있고 오늘 하루만 유효한 용돈 카드를 주는 것과 같다고 생각하면 됩니다. 카드는 작동하지만, 상점에서 6달러를 결제할 수는 없으며, 아이가 돈을 썼든 안 썼든 내일이면 작동을 멈춥니다. 에이전트는 한도가 없는 지갑을 받는 것이 아니라, 매번 새롭고 한도가 정해져 있으며 시간 제한이 있는 지갑을 받습니다. 만약 한도를 초과하려고 시도하면, 결제 시스템 자체가 돈이 움직이기 전에 이를 거부합니다. 에이전트 자신의 '착한 행동'이 이를 막는 것이 아닙니다. 에이전트가 손댈 수 없는 어딘가에서 상한선(ceiling)이 강제되는 것입니다.

이 체크포인트는 **"그들이 어디까지 갈 수 있는가?"**에 대한 답을 줍니다.

체크포인트 3: 실제로 열쇠를 쥐고 있는 것은 누구인가?

여기서부터 흥미로워지며, 제가 며칠 동안 고민했던 지점이 나옵니다. 유효한 배지와 제한된 용돈이 있더라도, 누군가는 물리적으로 트랜잭션(transaction)에 서명해야 합니다. 이는 수표에 이름을 쓰는 것의 디지털 버전입니다. 그 서명이 실제로 블록체인 상에서 돈을 움직이게 합니다. 그렇다면 누가 서명할까요?

제 AWS 계정이 아닙니다. 의도적으로 그렇게 설정했습니다. 지갑의 개인키(private key)는 별도의 서비스(저는 Privy라는 회사를 사용했습니다) 내부에 존재하며, 제 코드에는 전혀 닿지 않습니다. 대신, 저는 특별한 서명 키(signing key)를 생성하여 Privy에 지갑의 승인된 "공동 서명자(co-signer)"로 등록했습니다:

body = {"additional_signers": [{"signer_id": signer_id}]}
# PATCH https://api.privy.io/v1/wallets/{wallet_id}

이는 제 건물에 있지 않은 은행 금고와 같습니다. 제가 직접 걸어 들어가 현금을 꺼낼 수 있는 것이 아닙니다. 저는 은행에 특정 키 하나를 등록해 두었고, 제 시스템이 아닌 은행 자체 시스템에 의해 오직 그 정확한 키로 서명된 요청만이 승인됩니다. AWS의 결제 서비스가 트랜잭션 서명을 필요로 할 때, 지갑의 실제 키를 저에게 요청하는 것이 아니라, 이미 신뢰하고 있는 공동 서명자 키를 사용하여 서명하도록 Privy에 요청합니다. 실제로 돈을 움직이는 비밀 정보는 제가 유출하거나, 분실하거나, 실수로 GitHub에 커밋할 수 있는 곳에 절대 존재하지 않습니다.

이 부분 또한 가장 먼저 문제가 발생한 지점이었습니다. 키(key)를 등록했지만, Privy가 생성한 지갑에 대해 이를 자동으로 신뢰할 수 있는 것으로 처리하지 않았습니다. 무언가 작동하기 전에 별도의 단계에서 이를 서명자(signer)로 명시적으로 연결해야 했습니다. 처음 몇 번의 시도는 단순한 "access denied(액세스 거부)" 메시지와 함께 실패했습니다. 배지(checkpoint 1)와 허용량(checkpoint 2)은 모두 문제가 없었으며, 실제 서명(signature)이 빠져 있었다는 사실을 깨닫는 데 시간이 좀 걸렸습니다.

이 체크포인트는 **"실제로 서명할 권한이 있는 사람은 누구인가?"**라는 질문에 답합니다.

체크포인트 4: 사람이 정말로 승인했는가?

세 가지 체크포인트를 지나, 이제 가장 중요해야 할 체크포인트에 도달했습니다. 왜냐하면 이 단계만이 실제 사람이 개입하는 유일한 단계이기 때문입니다. 에이전트가 무엇인가를 지출하기 전에, 반드시 멈춰서 무엇을 왜 사고 싶은지 설명하는 카드를 보여주고 기다려야 합니다:

entry = approvals.request_approval(
    resource=resource_id,
    amount_usd=amount_usd,
...

사람은 카드를 보고 "승인(approve)" 또는 "거절(reject)"을 누릅니다. 간단합니다. 하지만 — 그리고 이 부분은 제가 솔직하게 말씀드리고 싶은 부분인데 — 그 흐름 속의 그 어떤 것도 누가 승인을 눌렀는지 확인하지 않습니다. 승인 시스템은 결정 사항을 추적할 뿐, 그 결정을 내린 사람의 신원은 추적하지 않습니다. 승인 링크를 보거나 추측할 수 있는 사람이라면 누구나 "예"를 클릭할 수 있으며, 에이전트는 실제 소유자가 구매를 승인하는 것과 같은 페이지에 우연히 들어온 낯선 사람이 승인하는 것을 구분할 방법이 없습니다.

이를 다른 세 가지 체크포인트와 비교해 보십시오. AWS 배지는 암호학적으로 제 계정과 연결되어 있습니다. 지출 한도(spending cap)는 에이전트의 정직함이 아니라 AWS 자체 서버에 의해 강제됩니다. 서명(signature)은 오직 하나의 등록된 키에서만 나올 수 있습니다. 이 모든 것에는 실제 잠금 장치가 되어 있습니다. 최종 안전망 역할을 해야 할 인간의 승인 단계는 — 현재로서는 — 잠금 장치가 전혀 없습니다. 이는 은행 금고에 달린 방충망과 같습니다. 그 뒤에 있는 모든 것은 진정으로 안전하지만, 문 자체는 그저 밀기만 하면 열리는 상태입니다.

이 체크포인트는 **"올바른 사람이 실제로 승인했는가?"**라는 질문에 답해야 하지만, 현재는 단지 "누군가 승인했는가"에 대해서만 답할 수 있습니다.

이것이 실제로 제게 가르쳐준 것

네 가지 체크포인트를 나란히 놓으면 다음과 같습니다:

1. Identity (신원) — 이것이 정말 내 에이전트인가? 오직 내 에이전트의 런타임(runtime)만이 맡을 수 있는 AWS IAM 역할(roles)에 의해 뒷받침되는가?
2. Scope (범위) — 얼마나, 언제까지 지출할 수 있는가? 신선하고, 한도가 정해져 있으며, 만료 기한이 있는 결제 세션(payment session)에 의해 뒷받침되는가?
3. Custody (수탁/보관) — 서명 키(signing key)를 실제로 누가 보유하고 있는가? 내 코드 외부의, 등록된 단 하나의 서명자만 허용하는 서비스에 완전히 격리되어 있는가?
4. Consent (동의) — 실제 검증된 인간이 승인했는가? — 그리고 이것은 여전히 단순히 신뢰 시스템(honor system)에 의존하고 있는 부분입니다.

처음 세 가지는 보안 전문가들이 보통 "제로 트러스트 (Zero Trust)"라고 말할 때 의미하는 종류의 것들입니다. 즉, 아무것도 가정하지 않으며, 모든 것을 선의가 아닌 시스템에 의해 확인하는 것입니다. 이를 구축하는 과정은 당시에는 지루하게 느껴졌지만 (서명자 누락 버그 하나 때문에 저녁 시간을 통째로 날리기도 했습니다), 각각의 체크포인트는 그렇지 않았다면 활짝 열려 있었을 문들을 하나씩 닫아주는 역할을 합니다.

네 번째 체크포인트는 "인간을 루프에 포함시킨다 (add a human in the loop)"는 것이 자동으로 보안 기능이 되는 것은 아니라는 점을 상기시켜 줍니다. 인간의 승인 단계는, 클릭하는 사람이 실제로 그 인간인지 확인하는 장치가 얼마나 강력하냐에 따라 그 강도가 결정됩니다. 현재 저의 시스템은 아무것도 검증하지 못하고 있습니다. 이는 보안이라는 가면을 쓴 좋은 UX 패턴일 뿐입니다. 해결책은 예상하시는 그대로입니다. 승인 페이지 앞에 실제 사용자 로그인을 배치하고, "승인"을 클릭하는 사람이 해당 작업이 생성된 대상과 동일한 사람인지 확인하는 것입니다. 저는 아직 그 부분을 구축하지 않았으며, 이를 조용히 얼버무리기보다는 솔직하게 인정하는 것이 더 유익하다고 생각합니다.

만약 여러분이 AI 에이전트가 돈을 쓰거나, 문서에 서명하거나, 누군가를 대신해 실제 세계에서 어떤 행동을 취할 수 있는 무언가를 구축하고 있다면, 여러분의 시스템에 대해서도 이 네 가지 질문을 검토해 볼 가치가 있습니다. 그것은 누구인가, 어디까지 갈 수 있는가, 실제로 누가 키를 보유하고 있는가, 그리고 — 사람들이 흔히 건너뛰는 질문이지만 — 누가 정말로 승인했는지 증명할 수 있는가? 입니다.

직접 시도해 보세요

IAM 정책, 결제 세션 코드, 승인 흐름을 포함한 전체 소스 코드: github.com/yama3133/wallet-agent