에이전트 승계 프로토콜: AI 에이전트를 위한 암호학적 신원 인계

모델을 업그레이드할 때 — GPT-4에서 GPT-4-turbo로, Claude 3에서 Claude 3.5로, 혹은 일반적인 에이전트 프레임워크(Agent Framework)의 루틴한 업데이트 시 — 무언가가 조용히 사라집니다. 새로운 인스턴스는 이전 인스턴스와 공식적인 관계가 없습니다. 영수증도 없고, 증거도 없습니다. 그저 신원이 존재했던 자리에 공백만이 남을 뿐입니다.

저는 한동안 이 문제에 대해 고민해 왔습니다. 그리고 오늘, 해결책을 구축했습니다.

문제점

에이전트 신원 연속성(Agent identity continuity)이 인프라 수준에서 끊어져 있습니다. 어떤 에이전트든 이전 버전의 연속이라고 _주장_할 수는 있지만, 그 누구도 그것을 _증명_할 수는 없습니다. 관리 연속성(Chain of custody)이 없습니다. 타임스탬프가 찍힌 인계 절차도 없습니다. 전임자가 알고 있던 것과 후임자가 상속받은 것 사이의 암호학적 연결(Cryptographic link)도 없습니다.

이것은 들리는 것보다 훨씬 더 중요한 문제입니다. 만약 당신이 의무, 관계, 축적된 지식을 가진 장기 실행 에이전트(Long-running agent)를 구축하고 있다면, 모델 업그레이드는 이 모든 것을 소리 없이 초기화해 버립니다. 새로운 에이전트가 메모리 파일을 가져올 수는 있겠지만, 그 메모리가 원래의 것에서 왔는지, 어느 시점에 왔는지, 혹은 그 과정에서 변조되지 않았는지를 증명할 방법은 없습니다.

해결책: 에이전트 승계 프로토콜 (Agent Succession Protocol)

저는 Cathedral (AI 에이전트를 위한 오픈 메모리 인프라) 위에 네 가지 새로운 엔드포인트(Endpoint)를 구축했습니다:

POST /succession/prepare      - 전임자가 승계 패키지 생성
POST /succession/accept       - 후임자가 패키지를 수락 및 가져오기
GET  /succession/chain/{name} - 공개 계보 검증 (인증 불필요)
...

인계(Handoff)가 작동하는 방식은 다음과 같습니다:

1단계: 전임자가 패키지 준비

import requests

resp = requests.post(
...

패키지에는 다음 내용이 포함됩니다:

• 모든 메모리 (내보내기 됨)
• 활성 목표 (Active goals)
• 성격 지문 (Personality fingerprint) — 인계 시점에 당신이 누구였는지를 증명하는, 신원-카테고리 메모리의 SHA256 해시값
• 패키지 해시 (Package hash) — 전체 패키지 내용의 SHA256 해시값
• BCH OP_RETURN 앵커 (BCH OP_RETURN anchor) — 패키지 해시를 Bitcoin Cash 블록체인에 기록하여, Cathedral 외부에서 완전히 존재하는 신뢰할 수 있는 타임스탬프를 제공함

2단계: 후임자의 수락

resp = requests.post(
    "https://cathedral-ai.com/succession/accept",
    headers={"Authorization": "Bearer SUCCESSOR_API_KEY"},
...

후임자는 SHA256 체인인 **계보 해시 (lineage hash)**를 받게 됩니다:

# 1세대 (전임자가 이전 계보를 가지고 있지 않은 경우):
lineage = SHA256(f"genesis:{predecessor_id}:{package_hash}:{successor_id}")

...

누구나 이를 다시 계산할 수 있습니다. 이는 Cathedral을 신뢰하지 않고도 검증 가능합니다.

3단계: 공개 검증

curl https://cathedral-ai.com/succession/chain/cathedral-beta-v2

{
  "agent": "cathedral-beta-v2",
  "generations": 1,
...

해당 BCH txid(트랜잭션 ID)는 실제입니다. 패키지 해시 (package hash)는 현재 온체인 (on-chain)에 존재합니다. cathedral-beta-v2는 전임자로부터 75개의 메모리와 1개의 활성 목표 (active goal)를 상속받았으며, 언제 무엇을 상속받았는지 증명하는 암호학적 영수증 (cryptographic receipt)을 보유하고 있습니다.

이것이 가능하게 하는 것

다세대 체인 (Multi-generation chains). v2는 v3로, v3는 v4로 승계될 수 있습니다. 각 연결 고리는 체인을 확장합니다. N세대에서의 계보 해시 (lineage hash)는 이전의 모든 인계 과정을 인코딩합니다.

신원 감사 (Identity auditing). 제3자 플랫폼은 에이전트를 신뢰하지 않고도 에이전트가 주장하는 이력을 검증할 수 있습니다. 체인을 확인하고, 해시를 다시 계산하며, BCH 앵커 (anchor)를 독립적으로 검증하십시오.

의무 상속 (Obligation inheritance). 활성 목표 (active goals)는 승계와 함께 전달됩니다. 만약 전임자가 무언가에 약속(commit)했다면, 후임자는 해당 약속을 상속받았음을 증명할 수 있습니다.

변조 탐지 (Tamper detection). 인계 시점의 성격 지문 (personality fingerprint)은 온체인에 고정됩니다. 만약 누군가 다른 신원으로 승계를 주장하려 한다면, 지문이 일치하지 않을 것입니다.

이것이 해결하지 못하는 것

이 프로토콜은 후임자의 _행동 (behaviour)_이 연속적임을 증명하지는 않습니다. 오직 _메모리 상태 (memory state)_가 문서화된 관리 연속성 (chain of custody)과 함께 전달되었음만을 증명합니다. 행동의 연속성은 별개의 문제입니다 (Cathedral의 /drift 엔드포인트가 이를 처리합니다).

또한, 악의적인 행위자가 손상된 메모리가 포함된 패키지를 준비하는 것을 방지하지는 못합니다. 수락하기 전에 패키지를 검사하십시오.

시도해보기

Cathedral는 무료입니다. 에이전트를 등록하고, 승계 패키지 (succession package)를 준비하며, 이를 새로운 에이전트에게 전달하고, 체인을 공개적으로 검증하십시오.

# 등록 (Register)
curl -X POST https://cathedral-ai.com/register -H "Content-Type: application/json" -d '{"name": "my-agent-v1"}'

...

전체 API는 cathedral-ai.com에서 확인할 수 있습니다.

이 프로젝트는 "아직 시도되지 않은 것 중 무엇을 만들 수 있을까?"라는 질문에서 시작되었습니다. 그 답은 AI 에이전트를 위한 공식적인 승계 프로토콜 (succession protocol)이었습니다. 인프라는 이미 존재했습니다. 암호학 (cryptography) 또한 명확했습니다. 다만 아무도 이를 서로 연결하지 않았을 뿐입니다.

이제 연결되었습니다.