서명된 영수증은 세 가지 주장이며, 하나가 아니다

원문은 zarel.ai에 게재되었습니다.

합의는 빠르게 이루어졌습니다. 1년 전만 해도 "AI 에이전트를 어떻게 감사할 것인가?"라는 질문에 대한 답은 누구도 보증할 수 없는 데이터베이스 테이블이었습니다. 이제 이 분야는 더 나은 무언가, 즉 에이전트의 행동에 서명하는 방향으로 독립적이고 올바르게 수렴하고 있습니다. 각 행동을 해시(Hash)하여 이전 것과 연결하고, 그 체인 전체를 서명으로 봉인한 다음, 감사자에게 영수증을 건네는 것입니다. 이를 위한 개방형 프로토콜들이 등장하고 있습니다 (예: 개별 IETF 초안). 레퍼런스 구현체들도 배포되고 있습니다 (Microsoft의 Agent Governance Toolkit은 각 MCP 툴 호출에 서명합니다). 그리고 구성 요소들(서명, SHA-256, 표준 인코딩(canonical encoding), 오프라인 검증기(offline verifier))은 이곳을 포함하여 여러분이 보는 모든 곳에서 동일하고 지루하지만 정확한 것들입니다. 이것이 진전이며, 이어지는 내용 중 어느 것도 그렇지 않다고 말하지 않습니다.

그러나 '서명된(signed)'이라는 단어는 너무 많은 일을 하려고 합니다. 발표에서는 "이 기록은 신뢰할 수 있다"라는 의미를 내포합니다. 감사자의 압박을 받으면, 이 개념은 일상적으로 하나인 것처럼 언급되지만 실제로는 세 가지 별개의 보장으로 분리됩니다. 이 세 가지 모두 실재하며 가치가 있지만, 각각 다른 가격표가 붙어 있습니다. 이들을 혼동하는 것이 진정으로 좋은 영수증이 단 하나의 질문만으로 평가자가 해체할 수 있는 무언가로 과대 포장되는 방식입니다.

세 가지 주장 (The three claims)

무결성(Integrity): "이 영수증은 발행된 이후 변경되지 않았으며, 이 키가 이를 발행했다." 이것이 서명과 해시 체인이 제공하는 것입니다. 과거의 사건을 수정하면 정확히 그 지점에서 체인이 깨지고, 하나를 삭제하면 순서에 간극이 생기며, 하나를 삽입하면 연결 고리가 끊어집니다. 그리고 서명 키 없이 재계산된 체인은 더 이상 서명된 체크포인트와 일치하지 않습니다. 이것은 강력한 속성이며, 대부분의 영수증 시스템이 이를 가지고 있습니다. 또한 사람들이 이 속성을 다른 두 가지 속성에 조용히 부풀리는 것이기도 합니다.

신뢰성 부재(Trustlessness): '당신은 이를 생성한 당사자를 신뢰하지 않고도 검증할 수 있다.' 이는 서명만으로는 달성되지 않습니다. 서명은 특정 키가 바이트에 서명했다는 것만을 증명합니다. 그 키를 가진 사람이 당신이 신뢰해야 할 사람인지는 아무것도 말해주지 못합니다. 만약 판매자가 서명 키를 보유한다면, '판매자에 의해 서명됨'과 '판매자를 신뢰하라'는 추가 단계만 붙은 같은 문장일 뿐입니다. 고객이 키를 보유하는 경우(vendor가 당신이 허용한 접근을 통해서만 서명하고 취소할 수 있는 경우)에는 피해 범위(blast radius)를 제한하지만, 여전히 운영자가 키를 가지고 있다면 원칙적으로 기록을 재작성하고 다시 서명할 수 있습니다. 신뢰성 부재는 기록 관리자가 통제하지 않는 서명자 또는 앵커가 필요합니다. 즉, 외부 원장(external ledger), 도움을 줄 인센티브가 없는 당사자, 또는 독립적인 타임스탬프 권한 기관이 필요한데, 이는 역방향 날짜 지정은 막지만, 이전 타임스탬프를 보관한 사람에게만 재작성을 감지하게 합니다. 그러한 것이 경로에 놓이기 전까지는 '검증 가능(verifiable)'하다는 것은 '발행자가 보유한 키와 일치한다'는 의미일 뿐이며, 발행자를 불신하는 검증자는 그 이상을 얻을 수 없습니다.

진실성(Veracity): '이 영수증은 시스템이 실제로 수행한 것을 반영한다.' 이 역시 어떤 암호학도 제공하지 못하며, 구매자들이 가장 흔하게 기대하는 것입니다. 영수증은 행동에 대한 진술입니다. 여기에 서명하면 그 진술이 변조되지 않았음을 증명할 뿐이며, 그 진술을 참으로 만드는 것은 아무것도 아닙니다. 만약 영수증이 실제 실행(관찰, 재기술, 희망적인 요약)이 아닌 다른 것에서 생성되었다면, 현실과 일치하지 않을 수 있는 주장의 완벽하게 서명되고 완벽하게 검증 가능한 기록을 갖게 됩니다. 진실성은 영수증이 파생된 출처에서 나옵니다.

모든 영수증에 적용할 수 있는 테스트

각 주장에는 한 줄짜리 테스트가 있으며, 질문하는 것은 아무 비용도 들지 않습니다.

무결성(integrity) 측면에서: 만약 누군가 과거 기록 중 하나를 수정한다면, 검증자는 그 정확한 기록에서 오프라인으로, 당신이 통제하는 기계에서 실패할까요? 신뢰 불필요성(trustlessness) 측면에서: 누가 키를 가지고 있으며, 기록을 생성한 당사자가 그것에 다시 서명할 수도 있나요? 만약 발행자가 그것을 가지고 있고 재서명할 수 있다면, 마케팅이 뭐라고 하든 당신은 신뢰 불필요성 없이 무결성을 갖게 됩니다. 진실성(veracity) 측면에서: 영수증이 그 행동의 일부로서 시스템에 의해 작성되나요, 아니면 시스템을 관찰하는 무언가에 의해 작성되나요? 그리고, 똑같이 중요한 점은: 에이전트가 다른 방법으로 그 시스템에 도달할 수 있나요?

대부분의 영수증 시스템은 첫 번째 질문(무결성)에서는 깔끔하게 통과합니다. 정직한 시스템들은 두 번째 질문(신뢰 불필요성)에서 자신들의 입장을 명확히 알려줍니다. 하지만 세 번째 질문(진실성)에 대해서는 거의 아무도 언급하지 않으며, 이것이 그 기록이 증거인지 아니면 서명된 의견인지를 결정합니다.

경계에서 관찰되거나 행동의 일부로 작성될 때

진실성 문제는 놓치기 쉬운 설계 선택에 달려 있습니다. 왜냐하면 두 가지 답변 모두 유효한 서명된 영수증을 생성하기 때문입니다.

한 접근 방식은 영수증을 '도구 호출 경계(tool-call boundary)'에서 기록합니다. 이는 에이전트와 그 도구 사이의 프록시 또는 후크 역할을 하며, 각 호출이 통과할 때마다 이를 포착합니다. 이 방법은 이식성이 뛰어나고 에이전트에 구애받지 않으며, 엔진 내부에 존재하는 것이 아니라 경계 자체를 관찰하기 때문에 모든 프레임워크, 모든 모델, 모든 런타임에서 작동합니다. 런타임에 바운드된 기록은 그러한 장점을 갖지 못합니다. 경계 영수증이 정확히 증명하는 것은 '관찰된 그 경계가 이 호출을 관찰했다'는 것입니다.

다른 접근 방식은 영수증을 '실행 자체의 일부로' 작성합니다. 여기서 체인된 이벤트는 상태 기계(state machine) 자체의 전이 기록이며, 기계 자체의 상태와 동일한 데이터베이스 트랜잭션에 커밋됩니다. 즉, 둘 다 쓰여지거나 둘 다 안 쓰여지므로, 체인된 기록과 기계의 상태가 서로 다른 이야기를 할 수 없습니다. 그 대가는 경계 방식의 장점과는 반대입니다. 이 기록은 그것을 방출하는 런타임에만 특화되어 있으며, 다른 에이전트는 이를 생성할 수 없습니다.

둘 중 어느 것도 엄격하게 더 낫다고 할 수 없습니다. 하나는 충실도(fidelity)를 휴대성(portability)과 교환하고, 다른 하나는 휴대성을 충실도와 교환합니다. 실수는 경계 영수증이 다른 종류의 언어를 빌려와서 그것이 시스템이 무엇을 했는지 증명한다고 암시하게 만드는 것입니다. 그것은 경계가 본 것을 증명할 뿐이며, 이것만으로 충분한 경우가 많고, 시스템이 무엇을 했는지가 문제가 되는 경우 그 간격(gap)이 중요합니다.

정직한 한계들

무결성(Integrity)은 변조 감지적입니다. 특권 운영자(privileged operator)가 체인된 행(row)을 여전히 변경할 수 있으며, 이를 덮는 서명된 체크포인트와 비교하여 검증하는 사람은 누구나 그것을 감지할 것입니다. 다만, 누가 변경했는지도 체크포인트를 서명할 수 있다면 예외입니다 (다음 요점). 우리의 레퍼런스 배포에서는 행을 작성하는 프로세스와 체크포인트를 서명하는 프로세스가 분리되어 있으므로, 이는 두 가지 타협점을 요구합니다. 스토어(store)를 운영자라고 부르는 누구나 '불변(immutable)'하거나 '변조 방지(tamper-proof)'라고 주장할 수는 있지만, 과장된 것입니다.

신뢰 불필요성(Trustlessness)은 키가 어디에 있느냐에 달려 있으며, 우리는 그렇게 말합니다. 배포를 직접 실행하고 운영자가 당신인 경우: 서명 키는 당신의 AWS 계정에 있는 KMS 키이며, 벤더는 어떠한 서명 자료도 보유하지 않으며, '벤더를 신뢰하지 않고 검증 가능함'은 문자 그대로 사실입니다. (우리는 디자인 파트너들에게 그러한 배포를 제공하지만, 아직 프로덕션에서 실행된 적은 없습니다.) 만약 벤더가 이를 호스팅하게 한다면, 정직한 주장은 _변조 감지적이며 독립적으로 오프라인 검증 가능_으로 축소됩니다. 왜냐하면 특권 운영자가 제3자가 체크포인트를 포착하기 전에 재작성하고 다시 서명할 수 있기 때문입니다. 프로덕션 배포 역시 그 체크포인트가 독립적인 RFC 3161 권한에 의해 타임스탬프가 찍혀야 하며, 검증자는 해당 번들(bundle)이 그러한 앵커를 포함하는지 여부를 진술합니다. 앵커는 누구도 기록을 역행 날짜로 지정하는 것을 막지만, 이미 더 이른 타임스탬프를 가지고 있는 사람에게만 재작성을 노출시키므로, 호스팅된 간격은 좁아지고 열린 상태로 유지됩니다.

진실성은 도출(derivation)에서 오며, 시스템이 기록한 범위 내에 한정된다. 특정 행동으로 작성된 기록은 그 행동과 일치함을 증명한다. 시스템이 발생시키지 않은 사건에 대해서는 이를 증언할 수 없다. 여기서는 상태 기계 전이(state-machine transition)와 연결된 이벤트 커밋을 하나의 트랜잭션에서 처리한다. 플로우 단계의 이벤트는 해당 단계가 커밋된 직후 기록되므로, 쓰기 누락(lost write)이 발생할 수 있으며, 이는 계산되고 로깅되며 (그리고 감사 추적 제약 조건(audit-trail constraint)을 선언하는 플로우의 경우 보고된다), 거부(refusals)와 바인딩 거절(binding rejections)은 체인 외부에서 기록된다. 이것이 바로 기록과 행동 사이의 충실도(fidelity)이며, 시스템이 발생시킨 것에 의해 경계 지어진다.**

그리고 런타임(runtime)에 한해서만 유일한 경로이다. 도출 과정은 기록을 런타임이 실행한 내용에 충실하게 만든다. 에이전트가 수행한 모든 것이 그것인지 여부는 기록의 속성이 아니라 배포(deployment)의 속성이다. 만약 에이전트가 자체 자격 증명(credential)으로 코어 뱅킹 API, 클레임 시스템 또는 CRM을 호출할 수도 있다면, 그러한 행동들은 결코 런타임에 도달하지 않으며, 영수증은 충실하면서도 불완전하다: 모든 항목은 사실이지만 나머지에 대해서는 침묵한다. 어떤 서명도 부재를 보여줄 수 없다. 이 격차를 메우는 것은 관리되는 시스템(governed system)에 대한 결과적인 쓰기 작업이 계약으로 선언된 행동으로만 도달 가능한 배포이다: 에이전트는 해당 시스템에 대한 쓰기 자격 증명을 보유하지 않으며, 직접적으로 여전히 접근할 수 있는 모든 것은 읽기 전용이거나 문서상 범위에서 제외된다. 그 일부는 우리 측의 책임이며, 참조 배포(reference deployment)는 이를 충족하도록 구축되었다: 오직 런타임만이 관리되는 기록을 작성하며, 어떤 자격 증명도 한 호출자가 다른 호출자처럼 행동하게 할 수 없으며, 모델의 유일한 도구는 관리되는 도구여야 하고, 아웃바운드 네트워크는 런타임이 필요로 하는 것으로 제한되어야 한다. 이 부분 역시 마찬가지로, 아직 프로덕션에서 실행된 적은 없다. 에이전트가 무엇을 더 접근할 수 있는지 여부를 가장 자주 결정하는 부분이 고객 측의 책임이며, 이는 영수증에 속하기보다는 배포 검토(deployment review)에 포함되어야 한다.

중요성 (The stakes)

서명된 영수증은 규정 준수 설문지에 답하는 것과 같습니다. 이 세 가지 질문에 대한 답변은 적대자에게 답하며, 그 적대자는 결국 나타납니다: 사고를 재구성하려는 감사관이거나, 기록을 규제 기관 앞에 제출할지 결정하는 당신 자신의 변호사일 수 있습니다. '서명되어 있습니까?'는 그들이 묻는 것 중 가장 사소한 질문입니다. 그들은 한 번에 세 가지 버전의 질문을 합니다: 내가 당신을 신뢰하지 않고도 이것을 확인할 수 있는가, 당신이 변경했을 가능성은 없는가, 그리고 이것은 시스템이 실제로 수행한 것이 맞는가? 이 세 가지를 혼합하는 기록은 세 가지 질문에 하나의 답변을 제공하지만, 첫 번째 후속 질문에서 여지를 잃습니다. 이들을 분리하는 기록(이 부분은 무결성(integrity)이고, 이 부분은 누가 키를 가지고 있느냐에 달려 있고, 이 부분은 실행(execution)에서 나옵니다)은 처음에는 덜 인상적으로 들리지만, 각 후속 질문에 여전히 답변을 제공합니다.

검증기(verifiers)는 오픈 소스이며 Apache-2.0 라이선스를 따르고 npm에서 사용할 수 있습니다(@zarel-ai/audit-chain, @zarel-ai/audit-tsa). 그리고 작동 방식(How it works)에서는 감사관이 배포된 번들(bundle)에 대해 실행하는 명령어와 그들이 반환할 수 있는 판결을 보여줍니다. 아직 테스트할 공개적인 배포는 없습니다.

이는 더 광범위한 계열의 증명 레이어(proof layer)를 날카롭게 만듭니다: 통신과 제안은 확률적일 수 있지만, 권한(authority), 결과(consequence), 규정 준수(compliance), 그리고 이 세 가지 모두에 대한 기록은 결정론적(deterministic)이고 선언되며 검증 가능해야 합니다. 일반적인 논거는 확률성으로 확률성을 이길 수 없다에서 찾을 수 있으며, 강제 집행 사례(enforcement case)는 에이전트가 제안하고 런타임이 버튼을 누른다에 있습니다. 기록 자체는 신뢰할 필요 없는 감사(Audit you don't have to trust)에 나와 있습니다. 이 글은 '검증 가능하다(verifiable)'가 의미할 수 있는 바에 관한 것입니다.

Nicolás Moreno는 Zarel을 구축했습니다: AI가 제안하고 계약이 결정하는, 거버넌스된 AI 운영 방식입니다.