CAI가 존재하는 이유: 에이전트 결제 문제와 세 가지 역할 (수탁자, 승인자, 운영자)

에이전트-결제 문제는 에이전트보다 오래되었으며 명확한 형태를 가지고 있습니다. 이 게시물은 CAI가 해결하는 문제, 사용자 확인 패턴, 그리고 시스템을 작동하게 만드는 세 가지 역할을 독자가 '어떻게(how)'보다 '왜(why)' 이해하고 싶을 때 읽는 에세이 형식의 글입니다. 코드는 없으며, 명령어도 없습니다.

문제점

에이전트가 돈이 드는 작업을 수행하려고 합니다. 비용에 대한 책임은 사용자에게 있습니다. 에이전트는 지갑(wallet)이 없고, 사용자는 개인 키를 붙여넣거나(사용자가 절대 해서는 안 하는 행동), 처음부터 수탁 흐름(custodial flow)을 구축하는 방법 외에는 이를 제공할 방법이 없습니다(대부분의 팀들이 그렇지 않습니다). 그 결과 에이전트는 작업을 실패하거나 사용자에게 수동으로 처리해 달라고 요청합니다. 사용자는 어쨌든 비용을 지불하지만, 에이전트가 도움을 주지 못했습니다.

사이트 자격 증명(site credentials)에 대해서도 같은 문제가 존재합니다. 에이전트가 사용자를 대신하여 사이트에 로그인하려고 합니다. 사용자에게는 비밀번호가 있지만, 에이전트는 사용자가 비밀번호를 에이전트 대화창에 붙여넣거나(사용자가 절대 해서는 안 하는 행동), 금고(vault)를 처음부터 구축하는 방법 외에는 이를 검색할 방법이 없습니다. 그 결과 에이전트는 작업을 실패하거나 사용자에게 수동으로 처리해 달라고 요청합니다.

두 문제 모두 같은 형태를 가지고 있습니다. 에이전트는 사용자가 승인한 무언가를 할 _의도(intent)_를 가지고 있지만, 사용자가 절대 주어서는 안 되는 것을 제공하지 않고서는 그 행동을 _실행(execute)_할 방법이 없습니다.

역사적 실패 방식들

이 문제를 해결하려는 세 가지 시도가 있었습니다. 모두 잘 알려진 실패 모드를 가지고 있습니다.

시도 1: 에이전트가 사용자의 개인 키를 보유하는 경우. 사용자가 자신의 지갑에 대한 개인 키를 에이전트에게 제공합니다. 에이전트는 트랜잭션을 자율적으로 서명합니다. 사용자는 에이전트가 무엇을 서명했는지 가시성을 확보할 수 없습니다.

실패 모드: 손상된(compromised) 에이전트가 지갑을 고갈시킵니다. 사용자는 나중에 이를 알게 됩니다. 피해는 이미 발생했습니다.

시도 2: 에이전트가 사용자의 비밀번호를 보유합니다. 시도 1과 동일하지만, 사이트 자격 증명(site credentials)에 관한 것입니다. 사용자는 자신의 은행, 이메일, 소셜 미디어의 비밀번호를 에이전트에게 제공합니다. 에이전트는 자율적으로 로그인합니다.

실패 모드: 손상된(compromised) 에이전트가 사용자가 저장해 둔 모든 사이트에 로그인합니다. 사용자의 계정이 위험에 처합니다.

시도 3: 사용자가 비밀 정보를 에이전트 대화창에 붙여넣습니다. 사용자는 개인 키나 비밀번호를 채팅창에 붙여넣습니다. 에이전트 모델은 그 비밀 정보를 보게 됩니다. 이 모델은 이를 기록할 수 있습니다. 에이전트는 이 비밀 정보를 사용하여 행동을 수행합니다.

실패 모드: 비밀 정보가 모델의 컨텍스트 창(context window)에 남게 됩니다. 모델이 이를 기억할 수 있습니다. 사용자는 해당 비밀 정보를 주기적으로 변경해야 합니다.

세 가지 시도 모두 같은 이유로 실패합니다. 사용자가 절대 제공해서는 안 되는 것을 에이전트에게 넘겨주고, 에이전트의 위험(compromise)이 곧 사용자의 위험이 됩니다.

세 가지 역할

CAI는 책임을 세 가지 역할로 분리합니다.

수탁자(The custodian). CAI가 개인 키를 보유합니다. CAI가 암호화된 자격 증명(encrypted credential)을 보유합니다. 사용자가 동의할 때 CAI가 거래에 서명합니다.

승인자(The approver). 사용자는 수신자, 금액, 체인(chain)을 확인하고 호스팅된 액션 페이지에서 한 번 탭하기만 하면 됩니다. 탭하지 않으면 아무 일도 일어나지 않습니다.

운영자(The operator). 에이전트가 CAI API를 호출하고, 호스팅된 액션 URL을 반환하며, 영수증(receipt)을 폴링합니다. 에이전트는 개인 키나 비밀번호를 보유하지 않습니다.

에이전트의 API 키는 _권한 부여(authorization)_입니다. 이는 사용자를 대신하여 CAI API를 호출할 수 있습니다. 호스팅된 액션 페이지에서 사용자의 탭은 _동의(consent)_입니다. 이는 특정 전송을 승인합니다.

이는 에이전트가 사용자가 절대 넘겨주어서는 안 되는 것을 제공하지 않고도 유용한 작업을 수행할 수 있는 유일한 구성 방식입니다.

사용자 확인 패턴

이 패턴은 CAI의 모든 상태 변경 작업에서 일관되게 적용됩니다.

1. 에이전트가 작업 상세 정보와 함께 CAI API를 호출합니다.
2. CAI는 호스팅 액션 URL을 생성합니다. 이것은 원탭(single-tap) 확인 페이지입니다.
3. 사용자가 페이지를 열고, 작업 상세 정보를 본 후, 한 번 탭합니다.
4. CAI가 작업을 실행합니다.
5. 에이전트가 영수증(receipt)을 폴링(poll)합니다.

송금의 경우, 페이지에는 수신자, 금액, 체인이 표시됩니다. 자격 증명 검색(credential retrieval)의 경우, 페이지에는 사이트와 사용자 이름이 표시됩니다. 사용자는 실제 작업이 실행되기 전에 이를 확인합니다.

해당 페이지는 HTTPS이며, 탭은 단일 작업에 바인딩되고, URL은 짧은 시간 안에 만료됩니다. 사용자가 아무 조치도 취하지 않으면, 작업은 실행되지 않습니다.

이 디자인이 작동하는 이유

사용자 확인 패턴은 사용자에게 가시성(visibility)과 동의(consent)를 제공하기 때문에 효과적입니다.

가시성. 사용자는 실제 작업이 실행되기 전에 이를 확인할 수 있습니다. 사용자는 수신자의 이름이나 주소, 금액, 체인을 볼 수 있습니다. 사용자는 지갑에서 나가는 실제 가치를 볼 수 있습니다.

동의. 사용자가 명시적으로 작업을 승인합니다. 탭 자체가 동의입니다. 탭이 없으면 아무 일도 일어나지 않습니다.

같은 패턴은 안전 제한(safety limits)에도 적용됩니다. 모든 지갑에는 에이전트가 시작한 송금에 대해 기본 USD 200/일 자동 한도가 있습니다. 새로운 수신자에게 보내는 모든 송금은 명시적인 사용자 확인을 필요로 합니다. 이것들은 선택적 설정이 아니라 제품 수준의 보호 장치입니다.

손상된 에이전트는 지갑을 고갈(drain)할 수 없습니다. 에이전트는 CAI API를 호출할 수는 있지만, API는 호스팅 액션 URL을 반환합니다. 사용자가 탭하지 않습니다. 아무 일도 일어나지 않습니다. 에이전트가 손상되었더라도, 사용자는 위험에 처하지 않습니다.

손상된 에이전트는 사이트에 로그인할 수 없습니다. 에이전트는 자격 증명을 검색하기 위해 볼트 API(vault API)를 호출할 수는 있지만, API는 호스팅 액션 URL을 반환합니다. 사용자가 탭하지 않습니다. 아무 일도 일어나지 않습니다. 사용자는 위험에 처하지 않습니다.

손상된 모델은 사용자의 비밀 정보(secrets)를 유출(exfiltrate)할 수 없습니다. 모델은 API 호출, URL, 그리고 사용자 확인 페이지를 볼 뿐입니다. 개인 키나 비밀번호는 보지 못합니다. 비밀 정보는 결코 모델의 컨텍스트 창에 들어가지 않습니다.

사용자 확인 패턴(user-confirmation pattern)은 '모든 특권 행위에서 사용자가 개입한다(the user is in the loop on every privileged action)'는 것을 실제로 구현한 것입니다.

에이전트의 역할

에이전트의 역할은 사용자에게 유용한 작업을 수행하는 것이지, 사용자의 비밀 정보를 보관하는 것이 아닙니다. 에이전트는 CAI API를 호출하고, 호스팅된 액션 URL(hosted-action URL)을 반환하며, 영수증(receipt)을 폴링합니다. 에이전트는 절대 개인 키나 비밀번호를 가지지 않습니다. 에이전트의 저장소는 API 키와 응답 페이로드이며, 이 둘 모두 범위가 지정되고 시간 제한적입니다.

이는 '에이전트가 사용자의 디지털 자아'라는 모델과는 다릅니다. CAI의 모델은 '에이전트는 사용자의 도구'입니다. 비밀 정보는 사용자에게 있습니다. CAI가 이를 보유하고, 에이전트가 이를 작동시킵니다. 사용자가 모든 특권 행위를 승인합니다.

이것이 에이전트 생태계에 중요한 이유

에이전트 생태계에는 신뢰 문제가 존재합니다. 사용자의 지갑, 사용자의 사이트 자격 증명(site credentials), 그리고 사용자의 정체성은 사용자가 가장 가치 있게 여기는 것들입니다. 동시에 사용자가 에이전트에게 접근을 허용하는 것을 가장 꺼리는 것들이기도 합니다. 비밀 정보를 포기하지 않으면서 에이전트에게 접근 권한을 줄 수 있는 방법 없이는, 에이전트는 유용한 작업을 수행할 수 없습니다.

CAI는 그 신뢰 문제에 대한 하나의 해답입니다. 사용자 확인 패턴, 세 가지 역할(three roles), 그리고 원탭 호스팅 액션 페이지(single-tap hosted-action page)가 신뢰를 작동하게 만드는 메커니즘들입니다. 에이전트 생태계는 시간이 지남에 따라 이러한 메커니즘들을 더 많이 필요로 할 것이며, CAI는 가장 먼저 출시하는 것 중 하나입니다.

전체 시스템은 cai.com에서 문서를 확인할 수 있습니다. 가입은 cai.com/app에서 하고, 계약(contract)은 cai.com/skill.md에 있습니다.

위에서 설명한 사용자 확인 패턴을 시도했지만 호스팅 액션 페이지가 렌더링되지 않았거나 사용자의 터치로 작업이 승인되지 않은 경우

아래에 댓글로 남겨주세요:

1. 실행한 내용(What you ran) -- 설치 명령어, 요청, MCP 호스트 설정 등. 실제 명령어나 요청을 복사해 주세요.
2. 기대했던 결과(What you expected) -- 한 문장으로 작성해 주세요.
3. 받은 결과(What you got) -- 오류 메시지, 빈 응답, 예상치 못한 동작 등을 붙여넣어 주세요. 원문 그대로 부탁드립니다.
4. 사용 환경(Your environment) -- OS, Node 버전, MCP 호스트(OpenClaw / Hermes / Codex / Cursor / 기타), 관련 시 CAI 계정 등급을 기재해 주세요.

이 아티클에 남겨주시는 모든 댓글은 읽힙니다. 버그 보고는 24시간 이내에 답변드릴 예정입니다. 사용자들이 불편함을 느끼는 지점들이 다음 문서화 주제를 결정합니다.

문서: cai.com/skill.md · cai.com/developers.html · cai.com/app에서 가입하세요.