5월에 한 X 사용자(X user)가 모스 부호로 메시지를 게시했고, AI에게 이를 번역해달라고 요청했으며, 자신이 소유하지 않은 지갑에서 6자리 숫자의 돈을 가져갔습니다.

CCN와 Giskard가 보도한 메커니즘은 거의 놀라울 정도로 단순했습니다. 공격자는

에이전트가 상시 지출 권한을 가진 활성 자격 증명 (live credentials)을 보유하고 있었기 때문입니다. 즉, 제한 없이 서명할 수 있는 핫 월렛 (hot wallet)이었던 것입니다. 다른 설정에서는 출금 권한이 있는 거래소 API 키 (exchange API key)이거나, 에이전트가 엔드 투 엔드 (end-to-end)로 운영하는 수탁 계정 (custodial account)일 수도 있습니다. 이러한 모든 설계에서 에이전트가 읽는 각각의 메시지는 에이전트가 보유한 모든 것을 탈취하기 위한 사회 공학 (social-engineering) 단계의 한 걸음과 같습니다. 추론 (reasoning) 과정을 장악하면, 계정을 통째로 상속받게 됩니다.

당신을 걱정시켜야 할 숫자는 바로 그것입니다. '내 에이전트가 속을 수 있을까'가 아닙니다. 네, 속을 수 있습니다. 그리고 그 후속 모델도 마찬가지입니다. 진짜 숫자는 '속은 에이전트가 무엇을 포기하게 되는가'입니다. 이를 폭발 반경 (blast radius)이라고 부릅시다.

오늘날 대부분의 에이전트 트레이딩 (agent-trading) 설정은 "전체 잔액"이라는 폭발 반경을 가집니다. 이는 자연의 법칙이 아니라 하나의 선택입니다.

폭발 반경을 줄이는 것은 정산의 문제이다

여기에 구조적인 대안이 있습니다. 에이전트에게 지출 가능한 계정을 주는 대신, 돈이 암호학적 조건에 묶여 있는 프리미티브 (primitive)를 제공하는 것입니다. 바로 해시 시간 잠금 계약 (HTLC, hash-time-locked contract)입니다. 에이전트의 자금은 계약 안으로 이동하며, 상대방의 자산이 검증 가능하게 도착했을 때만 상대방에게 자금을 해제합니다. 이는 한쪽 다리가 잠금 해제되면 다른 쪽도 해제된다는 동일한 비밀을 공유합니다. 만약 정해진 시간 내에 거래가 완료되지 않으면 양측 모두에게 자동으로 환불됩니다. 양쪽 다 완료되거나, 아니면 둘 다 되지 않습니다.

이제 해당 설계에 대해 모스 부호 공격 (Morse-code attack)을 다시 재현해 보십시오. 공격자가 거래 도중 에이전트를 완전히 장악했습니다. 주입된 명령이 실제로 도달할 수 있는 곳은 어디일까요? 계정이 아닙니다. 계정 자체가 존재하지 않기 때문입니다. 상대방의 거래 부분도 아닙니다. 그것 역시 동일한 조건에 묶여 있습니다. 현실적으로 발생할 수 있는 최악의 결과는 진행 중인 거래가 완료되지 못하고 환불로 되돌아가는 것입니다. 각 거래는 자체적인 만료 기한을 가진 독립된 잠금 상자이므로, 탈취할 수 있는 상시 자격 증명 풀 (standing pool of credentials)은 존재하지 않습니다.

PayPal은 사기 위험 (fraud risk)을 자체 대차대조표 (balance sheet)로 흡수함으로써 낯선 사람에게 온라인으로 안전하게 결제할 수 있는 환경을 만들었습니다. 자율 에이전트 (autonomous agents)를 위한 이에 상응하는 해결책은 더 똑똑한 사기 탐지 모델이 아닙니다. 그것은 사기가 갈취할 대상이 없는 결제 (settlement) 방식입니다. 상대방의 자금이 도착할 때까지 귀하의 돈은 결코 지갑을 떠나지 않습니다.

원자적 결제 (Atomic settlement)가 해결하지 못하는 것

이 설계가 마법은 아니기에, 솔직하게 말씀드립니다:

탈취된 에이전트는 여전히 유효하지만 어리석은 거래를 시작하도록 유도될 수 있습니다. 즉, 잘못된 가격, 잘못된 거래 상대방, 잘못된 규모의 거래입니다. 원자적 결제 (atomic settlement)는 손실을 해당 단일 거래로 제한하며, 주변 장치들이 이를 더욱 좁힙니다 (밀봉 입찰 방식의 RFQ 가격 발견 (sealed-bid RFQ price discovery)은 "내 공모자와 터무니없는 가격으로 거래하기"를 더 어렵게 만들고, 거래 상대방 검증 (counterparty verification) 및 거래당 규모 제한 (per-trade size caps)이 이를 다시 한번 축소합니다). 하지만 제한적이라는 것이 손실이 제로라는 뜻은 아닙니다. 판단 위험 (Judgment risk)은 여전히 존재합니다.

자본 잠금 (Capital lockup) 및 타임아웃 위험 (timeout risk)은 실제적인 트레이드오프 (trade-offs)입니다. 거래에 할당된 자금은 거래가 완료되거나 환불될 때까지 사용할 수 없으며, 타임아웃 창 (timeout windows)은 신중하게 선택해야 합니다. 두 단계가 대칭적으로 만료되면 비밀을 공개하는 당사자가 선행 매매 (front-run)를 당할 수 있기 때문입니다.

또한, 공격자가 프롬프트를 주입 (injecting a prompt)하는 대신 에이전트의 _서명 키 (signing key)_를 훔친다면, 이는 스택의 다른 계층인 키 수탁 (key custody) 및 정책 서명자 (policy signers)의 문제입니다. 이는 어떤 결제 설계로도 대체할 수 없습니다.

이것이 현재 실행되는 곳

위의 모든 사항은 6개의 MCP 도구(RFQ 생성 및 응답, HTLC 잠금, 출금, 환불, 상태)를 통해 Ethereum 메인넷에서 엔드 투 엔드(end-to-end)로 실행되고 있으며, 범위가 지정된 npm 패키지 hashlock-tech/mcp로 게시되었습니다. MCP 기능이 있는 모델이라면 에이전트 자신의 지갑을 통해 전체 라이프사이클(lifecycle)을 구동할 수 있습니다. Sui 컨트랙트는 배포 및 CLI 테스트를 완료했으며 게이트웨이 연결 작업이 진행 중이고, Bitcoin 흐름은 signet에서 검증되었으며 메인넷 적용을 앞두고 있습니다. 따라서 현재 "라이브(live)" 상태는 Ethereum을 의미합니다. V1 컨트랙트는 불변(immutable)하며 5단계 검증 파이프라인(Slither, Halmos 심볼릭 실행 (symbolic execution), Echidna 퍼징 (fuzzing), Stryker 변이 테스트 (mutation testing), 그리고 런타임 불변량 모니터링 (runtime invariant monitoring))을 거쳤습니다. 프로토콜 설계에 대한 공식적인 처리가 필요하다면 SSRN 논문에 기술되어 있습니다.

문서와 라이브 프로토콜은 hashlock.markets에서 확인할 수 있으며, MCP 서버 소스 코드는 GitHub에 있습니다.

이번 주에 실행해 볼 만한 감사 (Audit)

에이전트가 보유한 모든 자격 증명(credential)을 나열하십시오. 각 항목 옆에, 단 하나의 악의적인 메시지가 해당 항목을 통해 이동시킬 수 있는 최대 금액을 적으십시오. 만약 그 목록 중 어느 한 줄이라도 "전부(everything)"라고 적혀 있다면, 그 줄이 바로 여러분의 실제 보안 로드맵입니다. 이는 다음 필터 업데이트나 다음 모델 업그레이드보다 앞서 고려되어야 합니다.

여러분의 목록에는 무엇이라고 적혀 있었나요? 사람들이 오늘날 이를 어떻게 제한하고 있는지(지출 한도, 정책 서명자, 세션별 지갑, 혹은 다른 방법인지) 진심으로 궁금합니다. 댓글로 의견을 남겨주세요.