당신의 에이전트에게는 API Key가 필요하지 않습니다

오늘날 모든 AI 에이전트는 비밀 문자열(secret strings)을 보유하고 있습니다. 그 .env 파일을 열어보면 그것들을 볼 수 있을 것입니다. OPENAI_API_KEY, ANTHROPIC_API_KEY, STRIPE_SECRET_KEY 같은 것들 말이죠. 그 문자열을 가진 사람이 권한을 얻습니다. 그것이 인증(authentication) 모델의 전부입니다. 저희의 에이전트를 몇 달 동안 직접 운영해 본 결과, 저희는 이에 지쳤고 그래서 다른 것을 출시했습니다. 그것은 온체인(on-chain) 방식입니다. 여러분은 2분 안에 Basescan에서 이를 검증할 수 있습니다.

API 키는 비밀(secret)의 소유를 인증합니다. 지갑 서명(Wallet signatures)은 지갑의 제어권을 인증합니다. 이 차이가 이 글의 핵심입니다. 비밀은 어딘가에 존재하는 것입니다. 그것은 복사될 수 있습니다. 유출될 수 있습니다. 금요일 밤 11시에 실수로 공개 리포지토리(public repository)에 체크인될 수 있으며, 월요일 아침이면 인터넷의 모든 크롤러(crawler)에 의해 인덱싱된 상태로 방치될 수 있습니다. 문자열 자체가 인증 수단이며, API가 판단하기에는 그 문자열을 가진 사람이 정당한 사용자입니다.

서명은 재사용 가능한 비밀이 아닙니다. 그것은 이 특정 메시지를 작성한 사람이 이 특정 지갑의 개인 키(private key)를 보유하고 있다는 것을 현장에서 생성하여 증명하는 증거입니다. 서명은 평문(cleartext)으로 안전하게 전송될 수 있습니다. 서명 안에 수신자가 서명자를 사칭할 수 있게 만드는 요소는 전혀 없습니다. 서명 키는 절대 이동하지 않습니다.

에이전트는 이미 서명에 능숙합니다. 인간은 지갑을 싫어합니다. 인간은 비밀번호를 잊어버리고, 하드웨어 장치를 분실하며, 시드 구문(seed phrases)을 잘못된 채널에 붙여넣고, 실제와 똑같이 생긴 이메일에 피싱(phished)을 당합니다. 이러한 거부감은 지갑 인증이 소비자 로그인에서 비밀번호를 대체하지 못한 근본적인 이유입니다. 지갑은 인간에게 어렵고, 이는 실질적인 이유입니다.

에이전트는 인간이 아닙니다. 에이전트에게 메시지에 서명하는 것은 함수 호출(function call)입니다. 에이전트가 이미 결제를 위해 지갑을 사용하고 있기 때문에 서명 라이브러리(signing library)는 이미 런타임(runtime)에 존재합니다. 동일한 지갑을 사용하여 API 요청에 서명하는 데 드는 한계 비용(marginal cost)은 제로입니다. 지갑 인증을 인간에게는 불가능하게 만들었던 요소가, 에이전트에게는 그것을 자연스럽게 만드는 요소가 됩니다.

우리가 구축한 것: 우리는 이것이 어떻게 보일지 설명하기보다, 직접 운영해 본 경험을 바탕으로 이야기하기 위해 먼저 우리의 자체 API에 도그푸딩 (Dogfooding)을 실시했습니다. 에이전트의 지갑은 Base 네트워크에 있는 우리의 플랫폼 지갑으로 5 USDC를 보냅니다. 이를 통해 /v1/attest 호출 시 단위로 소비되는 125개의 어테스테이션 크레딧 (Attestation credits)을 구매합니다. 에이전트는 api.insumermodel.com의 단일 엔드포인트로 트랜잭션 해시 (Transaction hash)를 POST 합니다. 단 한 번의 응답으로, API는 API 키 (API key) 문자열을 반환하고 동일한 지갑에 온체인 (On-chain) 상의 양도 불가능한 액세스 패스 (Access pass)를 민팅 (Mint) 합니다. 이후의 모든 /v1/attest 호출에 대해 에이전트는 두 가지 옵션을 가집니다. 2000년대 초반부터 모든 API가 작동해 온 방식대로 X-API-Key 헤더에 API 키를 제시하거나, 지갑의 개인키 (Private key)로 새로운 메시지에 서명하고 그 서명을 Authorization: Wallet 헤더에 넣는 것입니다. 재사용 가능한 비밀 정보는 네트워크를 통해 전달되지 않습니다. 현재 다른 엔드포인트들은 X-API-Key를 요구하지만, 지갑 호출자를 위한 과금 및 쓰기 경로가 검토됨에 따라 추후 단계에서 지갑 인증 (Wallet auth)을 해당 엔드포인트들로 확장할 예정입니다. 우리의 백엔드는 서명을 검증하고, 지갑이 액세스 패스를 보유하고 있는지 확인하며, 크레딧 1개를 차감한 뒤, 공개된 키를 가진 누구나 오프라인에서 검증할 수 있는 ECDSA 서명된 어테스테이션 (Attestation)을 반환합니다. 소지자 비밀 정보 (Bearer secret)는 절대 전송되지 않습니다. 서명 키 (Signing key)는 에이전트의 런타임 (Runtime)에 머뭅니다. 지갑은 현재 위치에 그대로 있습니다. 패스 (Pass)는 이동하지 않습니다. 인증은 서명이 됩니다. 이것이 전체 패턴입니다.

토큰은 결제가 아닙니다. 토큰은 지갑이 정당한 고객에게 속해 있다는 증명입니다. 이 지점부터 설계가 흥미로워지며, 분리되어 있어야 할 두 가지를 혼동하기 쉬워집니다. 패스는 멤버십 (Membership)입니다. 이는 해당 지갑이 어느 시점에 InsumerAPI 계정에 대한 비용을 지불했음을 증명합니다. 이는 지갑에 영구적으로 존재합니다. 크레딧이 소진되어도 만료되지 않습니다. 재발급될 필요도 없습니다. 에이전트가 계정 사용을 중단하더라도 패스는 그 자리에 남아 있습니다. 1년 뒤에 돌아와서 충전하더라도 동일한 패스가 여전히 남아 있습니다. 크레딧은 소비 (Consumption)입니다.

에이전트는 배치를 구매하고, 이를 증명 호출 (Attestation calls)에 사용하며, 더 많은 양을 구매합니다. 크레딧이 소진되면 API는 충전할 수 있는 명확한 경로와 함께 402 에러를 반환합니다. 지갑 자체는 변하지 않습니다. 패스 (Pass)는 영향을 받지 않습니다. 이러한 분리가 중요한 이유는 토큰이 소유자를 누군가의 결제 시스템에 결합하지 않고도 휴대 가능한 신뢰 신호 (Trust signal)로 작동할 수 있게 해주기 때문입니다. API를 구축하는 제3자는 우리와 어떠한 대화도 할 필요 없이, OAuth 연합 (OAuth federation) 없이, 공유 데이터베이스 없이, 실시간 API 조정 왕복 (Live API coordination round-trip) 없이도, 해당 지갑이 패스를 보유하고 있는지 확인하여 이 지갑이 실제 검증 서비스의 실제 고객이라는 소프트 신호 (Soft signal)로 취급할 수 있습니다. 토큰은 결제 수단이 아닙니다. 토큰은 지갑이 정당한 고객임을 증명하는 증거입니다. Basescan에서 컬렉션을 확인할 수 있습니다: 0x3E2a408cc6eceba04FF9d04A5B8B05aBa8DD50ce. 고객에게 민팅 (Mint)을 수행하는 정산 지갑 (Settler wallet)은 우리가 소유합니다. 고객은 오직 패스만을 받습니다. 발행자 (Issuers)는 어떤 NFT 팩토리 (NFT factory)에서도 액세스 컬렉션을 배포하거나 직접 작성할 수 있습니다. 우리는 Base 상의 RNWY를 사용했습니다: 0x7ee64394... . 직접 확인할 수 있는 증거: 어젯밤, 6달러의 USDC와 가스비용으로 몇 센트의 Base ETH를 보유한 당사의 테스트 에이전트 지갑이 루프를 처음부터 끝까지 실행했습니다. Base 메인넷에 기록된 4개의 트랜잭션이 공개 기록입니다. 적절한 양의 USDC를 가진 사람이라면 누구나 이 과정을 반복할 수 있습니다. USDC 결제, 테스트 지갑에서 플랫폼 지갑으로: 0xf873f5e6... 패스 민팅, 동일한 지갑으로: 0x6cb43ea1... 보유자 주소: 0x259e32F4... 컬렉션: 0x3E2a408c... 그 후 우리는 테스트 지갑에서 패스를 취소(Revoke)하고 다시 인증을 시도했습니다. API는 마땅히 나와야 할 정확한 메시지와 함께 요청을 거부했습니다: '지갑이 Insumer Access 패스를 보유하고 있지 않습니다.' 부정적인 경로 (Negative path) 또한 작동합니다. 전체 사이클은 반복 가능합니다. 그리고 서명된 증명 (Signed attestations) 자체는 오늘날 단순히 확인 가능한 수준에 그치지 않습니다. 모든 응답은 당사의 JWKS 엔드포인트에 게시된 공개 키 (Public key)를 통해 서명됩니다.

오늘, 내일, 혹은 몇 년 후라도 해당 응답을 보유한 사람이라면 검증 시점에 당사의 서비스에 호출할 필요 없이, 해당 키를 사용하여 오프라인으로 서명을 검증할 수 있습니다. 바이트 데이터는 변조 여부를 즉시 확인할 수 있습니다 (tamper-evident).

지갑의 진화 과정에서 이것이 차지하는 위치
지갑은 암호화폐를 보관하는 곳에서 시작되었습니다. 그 후 로그인 시스템이 되었습니다. Sign-in-with-Ethereum은 2021년부터 표준으로 자리 잡았습니다. 이제 지갑은 기계 인증기 (machine authenticators)로 변모하고 있습니다. 지갑은 자연스러운 자격 증명 (credential)이며, 서명은 자연스러운 인증 프리미티브 (authentication primitive)입니다. 그리고 에이전트 (agent)가 자연스러운 사용자입니다. 하드웨어 장치를 분실하거나 패스프레이즈 (passphrase)를 잊어버릴 '루프 안의 인간 (human in the loop)'이 존재하지 않습니다. 런타임 (runtime)은 매번 불평 없이 밀리초 단위로 로그인합니다.

이러한 발전 양상은 표준화 논의 과정에서 한동안 관찰되어 왔습니다. Mastercard는 에이전트 결제 표준을 초안 작성 중입니다. NIST는 에이전트 신원 (agent identity)에 관한 워크숍을 진행하고 있습니다. Coinbase는 에이전트가 지갑을 장착한 채로 등장할 것을 가정하여 에이전트 시장 (agentic markets)을 개방하고 있습니다. 그 형태가 정착되고 있습니다. 저희는 여러 팀 중 하나로서, 지갑 서명 인증이 OAuth가 위임된 인간 로그인 (delegated human login)을 위해 했던 역할을 에이전트에게 수행하게 될 것이라고 주장하고 있습니다.

우리는 API Key를 대체하는 것이 아닙니다
인간은 앞으로도 오랫동안 API Key를 계속 사용할 것입니다. 몇 개의 서비스와 개인용 노트북을 사용하는 전형적인 개발자에게는 API Key 모델이 잘 작동합니다. 익숙하며, 모든 클라이언트 라이브러리에서 지원됩니다. 전환에 따른 한계 이익 (marginal benefit)은 작습니다. 저희가 출시한 것은 순수하게 부가적인 기능입니다. X-API-Key 헤더는 여전히 모든 엔드포인트에서 작동합니다. 기존의 모든 고객은 행동의 변화를 전혀 느끼지 못합니다. 저희는 누구에게도 전환을 강요하지 않습니다. 기존의 경로를 없애는 것도 아닙니다. 지갑을 요구하는 것도 아닙니다.

하지만 에이전트는 다릅니다. 에이전트는 이미 서명하고, 거래하며, 지갑을 보유하고, 세션 전반에 걸쳐 신원을 유지하며, 인간의 감독 없이 지속적으로 작동합니다. 이러한 특성을 가진 소프트웨어에게 지갑 기반 인증은 종종 더 자연스러운 프리미티브 (primitive)가 됩니다.

인간의 고통과 기계의 편의성 사이의 비대칭성, 즉 소비자 로그인에서 지갑 인증 (wallet auth)을 배제하게 만들었던 그 비대칭성이 사용자가 자율적인 코드일 때는 정반대 방향으로 작동합니다. 우리가 정의한 카테고리에 따르면, 프리미티브 (primitive)는 지갑 인증입니다: 지갑 상태를 읽고, 조건을 평가하며, 서명된 불리언 (boolean) 값을 반환하는 것입니다. 이 카테고리는 조건 기반 액세스 (condition-based access)입니다. 단 한 번의 서명된 호출로 37개의 체인에 걸쳐 최대 10개의 조건을 쌓을 수 있으며, ERC-20 잔액, NFT 소유권, EAS 증명 (attestations), 그리고 Farcaster 신원을 어떤 조합으로든 혼합할 수 있습니다. 에이전트 API 인증은 이 많은 스택 중 하나일 뿐입니다. 액세스 패스 (access pass), EAS 증명, 그리고 Pudgy Penguin 소유 여부를 기준으로 게이트를 설정하려는 SDK 채택자는 단 한 번의 호출로 정확히 그 복합적인 조건을 요구할 수 있습니다.

당신의 API에도 이를 적용할 수 있습니다. 우리는 다른 누구에게 권장하기 전에 이를 직접 운영하며 발생하는 운영상의 마찰을 느껴보고 싶었기에, 우리 자신을 위해 먼저 이 시스템을 구축했습니다. 그리고 어제 프로덕션에 적용되었습니다. 다음 단계는 다른 API들이 미들웨어 (middleware)를 처음부터 직접 작성할 필요 없이 동일한 작업을 수행할 수 있도록 하는 것입니다. 우리의 자매 회사인 Skye Meta는 정확히 이 용도를 위해 @skyemeta/access라는 이름의 무료 MIT 라이선스 npm 패키지를 출시합니다. 설치 명령어는 한 줄이면 충분합니다: npm install @skyemeta/access. 이것은 '이것 아니면 저것(either-or)' 방식의 미들웨어입니다. API 키 요청은 변경 없이 통과됩니다. 지갑으로 서명된 요청은 내부적으로 InsumerAPI의 /v1/attest 엔드포인트를 통해 검증됩니다. 기존 고객들은 아무런 변화를 느끼지 못합니다. 반면 당신의 에이전트 고객들은 비밀 문자열 (secret string)을 관리할 필요가 없는 경로를 얻게 됩니다. 본인의 InsumerAPI 키를 가져오고, 원하는 액세스 컬렉션을 선택한 뒤, 제공된 미들웨어로 기존의 라우트 핸들러 (route handlers)를 감싸기만 하면 됩니다. 개발자 퀵스타트 (quickstart)에서는 무료 InsumerAPI 키를 발급받는 방법(10개의 증명 크레딧, 일일 100회 요청, 신용카드 불필요)과 첫 번째 /v1/attest 호출 과정을 안내합니다. 패키지 소스 코드는 GitHub의 douglasborthwick-crypto/skyemeta-access 에 있습니다. 만약 미들웨어를 건너뛰고 기본 InsumerAPI 프리미티브를 직접 호출하고 싶다면, API 레퍼런스 문서에 모든 엔드포인트가 설명되어 있습니다.

결론적으로, 첫 번째 세대의 API는 공유 비밀값 (shared secrets)을 통해 소프트웨어를 인증했습니다. 다음 세대는 대신 서명 (signatures)을 통해 소프트웨어를 인증할 수도 있습니다. 어젯밤, 저희의 에이전트 지갑은 액세스 비용을 지불하고, 패스 (pass)를 수령하고, 요청에 서명했으며, 재사용 가능한 비밀값을 전송하지 않고도 성공적으로 인증을 마쳤습니다. 이 트랜잭션 (transactions)들은 공개되어 있습니다. 이 패턴은 작동합니다. 저희는 모든 API가 내일 당장 전환해야 한다고 주장하는 것이 아닙니다. 저희의 주장은, 지갑을 보유한 자율 소프트웨어 (autonomous software)라는 API 소비자 하위 집합에 대해서는, 더 자연스러운 프리미티브 (primitive)가 이제 온체인 (on-chain) 상에서 사용 가능하며, 이를 시도하는 비용은 커피 한 잔 값에 불과하다는 것입니다. 원문은 insumermodel.com 에서 처음 게시되었습니다.