AEX: Non-Intrusive Multi-Hop Attestation and Provenance for LLM APIs

이 논문은 기존 JSON 기반 LLM API 에 비침습적으로 통합되어 요청과 응답 간의 신뢰할 수 있는 관계를 증명하고, 중개자나 스트리밍 변환 과정에서도 데이터 무결성과 출처를 검증할 수 있는 새로운 증빙 프로토콜 'AEX'를 제안합니다.

핵심

AEX: AI 대화의 '진실된 영수증'을 만드는 방법

이 논문은 우리가 인터넷을 통해 거대한 인공지능 (LLM) 과 대화할 때, **"정말 내가 보낸 질문 그대로 답을 받았을까?"**라는 근본적인 의문에 대한 해결책을 제시합니다.

이해하기 쉽게 우편 배달과 요리사의 비유를 들어 설명해 드리겠습니다.

---

1. 문제: "내 편지가 중간에 변질되었나요?"

지금까지 우리는 AI 서비스에 질문을 보내고 답을 받았습니다. 하지만 이 과정은 마치 우편물을 보내는 것과 비슷합니다.

• 사용자 (나): 편지 (질문) 를 우체국에 보냅니다.
• 중간 과정: 편지는 우체국, 중개상, 그리고 최종 배달부 (서버) 를 거칩니다.
• 문제: 중간에 누군가 편지를 뜯어 내용을 바꾸거나, 아예 다른 편지를 대신 넣을 수도 있습니다. 혹은 "이 편지는 원래 이 내용이었어"라고 말하지만, 실제로는 다른 내용을 보냈을 수도 있습니다.

최근 연구에 따르면, 공식이 아닌 가짜 AI 서비스 (Shadow API) 들이 실제로는 다른 모델을 쓰거나, 답변을 임의로 조작하는 경우가 많았습니다. 기존 기술들은 "이 AI 가 진짜인가?"를 추측하거나, 복잡한 장비를 동원해야 했지만, 실제 대화 내용 (질문과 답변) 이 변조되지 않았음을 증명하는 쉬운 방법은 없었습니다.

2. 해결책: AEX (비밀스러운 도장 시스템)

이 논문에서 제안한 AEX는 기존 AI 서비스의 구조를 뜯어고치지 않고, 답변 위에 **"진실된 도장 (Attestation)"**을 찍는 방식입니다.

🍳 비유: "요리사의 레시피와 완성된 요리"

• 기존 방식: 손님이 "스테이크를 주세요"라고 주문하고, 식당은 요리를 해서 줍니다. 하지만 요리사가 중간에 소스를 바꿨거나, 손님이 원하지 않는 재료를 넣었는지 알 수 없습니다.
• AEX 방식:
  1. 주문서 (질문) 도장: 손님이 주문할 때, 주문 내용 자체를 암호화된 도장으로 찍습니다.
  2. 완성된 요리 (답변) 도장: 요리가 완성되면, "이 요리는 이 주문서와 정확히 연결된 것입니다"라는 도장을 찍어줍니다.
  3. 중간 과정 기록: 만약 요리사가 "소스를 살짝 바꿨습니다"라고 했다면, 그 변경 사항도 공인된 중개인이 "이건 합법적인 변경입니다"라고 도장을 찍어 증명합니다.

3. AEX 의 핵심 기능 3 가지

이 시스템은 세 가지 중요한 역할을 합니다.

① 변조 방지 (도장 대조)

AI 가 보낸 답변에 디지털 도장이 붙어 있습니다. 사용자가 이 도장을 확인하면, "내가 보낸 질문과 이 답변이 100% 일치한다"는 것을 수학적으로 증명할 수 있습니다. 중간에 누군가 내용을 바꿔치기하면 도장이 깨져서 바로 들통납니다.

② 합법적인 수정 인정 (공인된 중개인)

실제로는 질문이 중간에 조금씩 수정될 수 있습니다. (예: 보안 필터링, 오타 자동 수정 등)
AEX 는 이를 두 가지로 구분합니다.

• 불법 변조: 알 수 없는 사람이 내용을 바꿨다면 -> 거부 (도장 깨짐)
• 합법적 수정: 신뢰할 수 있는 중개인이 "이 부분은 안전을 위해 바꿨습니다"라고 도장을 찍어 증명했다면 -> 수용
  이처럼 "무조건 변하면 안 된다"가 아니라, "누가, 왜, 어떻게 바꿨는지"를 투명하게 보여줍니다.

③ 실시간 스트리밍 증명 (조각난 퍼즐)

AI 가 답변을 한 번에 주는 게 아니라, 글자 하나하나씩 쪼개서 보내는 경우 (스트리밍) 가 많습니다.
AEX 는 이 조각들이 순서대로, 빠뜨림 없이 왔는지 확인합니다. 마치 퍼즐 조각을 하나씩 받으면서, "이 조각이 앞선 조각과 정확히 이어져야 한다"는 도장을 매번 확인하는 것과 같습니다.

4. 이 기술이 해결하는 실제 문제

• 가짜 AI 서비스 차단: "우리는 최신 AI 를 씁니다"라고 말하지만 실제로는 구형 모델을 쓰거나, 답변을 조작하는 사기성 서비스를 바로 잡아냅니다.
• 신뢰할 수 있는 중개: 기업 내부에서 AI 답변을 검토하거나 필터링하는 과정에서, "우리가 내용을 바꿨지만 그건 안전을 위한 합법적인 작업입니다"라고 증명할 수 있게 됩니다.
• 투명한 기록: "이 답변이 어디서 왔는지, 누가 어떻게 처리했는지"에 대한 **완전한 이력 (Provenance)**을 남깁니다.

5. 결론: "AI 가 말한 게 진실임을 믿을 수 있을까?"

AEX 는 AI 가 정답을 냈는지 (사실 여부) 를 증명하는 것은 아닙니다. 대신, **"내가 보낸 질문과 이 AI 가 보낸 답변이, 중간에 누구의 손도 타지 않고 정확히 연결되었다"**는 것을 증명합니다.

마치 신용 카드 영수증과 같습니다. 영수증 자체가 "내가 산 물건이 최고급인지"를 말해주지는 않지만, "내가 이 가게에서 이 물건을 이 가격에 샀다"는 사실을 변조할 수 없게 만들어줍니다.

이 기술이 보편화되면, 우리는 AI 와 대화할 때 **"내 질문이 그대로 처리되었는지"**를 의심하지 않아도 되며, AI 서비스의 신뢰도가 획기적으로 높아질 것입니다.

기술 요약

1. 문제 정의 (Problem Statement)

배경 및 현황:
대형 언어 모델 (LLM) 은 이제 로컬 실행이 아닌 원격 API 를 통해 주로 소비됩니다. 그러나 이 API 경계는 클라이언트가 보낸 요청과 서버가 반환한 응답 간의 직접적인 증거를 제공하지 못합니다.

핵심 문제:

• Shadow API 및 신뢰성 위기: 최근 연구 (Zhang et al.) 에 따르면, 공식 API 와 호환된다고 주장하는 비공식 또는 중개 엔드포인트 (Shadow APIs) 가 실제 모델의 동작과 다르게 작동하는 경우가 많습니다.
• 기존 기술의 한계:
  • 지문 인식 (Fingerprinting) 및 통계적 테스트: 모델의 정체성을 추론할 수는 있지만, 실제 응답이 요청과 일치하는지 직접적인 증거를 제공하지는 못합니다.
  • TEE(신뢰 실행 환경) 및 검증 가능한 추론: 환경이나 코드 실행에 대한 보장은 제공하지만, API 레벨의 구체적인 요청 - 응답 바인딩이나 중개자 (Middleware) 를 통한 변형을 추적하는 데는 한계가 있습니다.
• 요구사항: 기존 LLM API 의 구조를 변경하지 않으면서도, 특정 클라이언트 요청이 특정 응답 객체나 스트리밍 출력 시퀀스에 직접적으로 바인딩되었음을 검증할 수 있는 경량화된 메커니즘이 필요합니다.

2. 방법론 및 설계 (Methodology & Design)

논문은 AEX (Attestation Extension) 라는 새로운 프로토콜 확장을 제안합니다. 이는 기존 JSON 기반 LLM API 에 비침투적 (Non-intrusive) 으로 적용됩니다.

핵심 설계 원칙:

1. 비침투성 (Non-intrusiveness): 기존 요청/응답의 비즈니스 로직, 도구 호출, 스트리밍, 오류 처리 semantics 를 변경하지 않습니다.
2. 분리된 증명 객체: 응답 JSON 의 최상위 레벨에 서명된 attestation 객체를 추가하여 비즈니스 페이로드와 분리합니다.
3. 표준화: JSON Canonicalization Scheme (JCS) 을 사용하여 공백이나 필드 순서와 무관한 일관된 바이트 표현을 보장하고, Ed25519 서명을 사용합니다.

주요 메커니즘:

• 요청 바인딩 (Request Binding):

  • 클라이언트가 보낸 요청을 해시하여 request_commit 를 생성합니다.
  • 명시적 바인딩 모드: 클라이언트는 full(전체 바인딩), top_level_exclude(일부 필드 제외), top_level_include(지정된 필드만 포함) 모드를 선택할 수 있어, 게이트웨이의 합법적인 필드 추가 (예: 추적 ID) 를 허용하면서도 악의적인 변조를 감지할 수 있습니다.
  • Nonce: 재전송 공격 방지 및 요청 프라이버시 보호를 위해 클라이언트에서 생성한 난수를 지원합니다.

• 스트리밍 무결성 (Streaming Integrity):

  • Dual-Anchor Hash Chain: 요청 아커 (Anchor) 로부터 시작하여 각 JSON 청크 (Chunk) 를 해시 체인으로 연결합니다.
  • 두 가지 증명 모드:
    1. Source-Stream Prefix Mode: 원본 스트림이 변조되지 않았을 때, 중간 지점 (Checkpoint) 에서 검증된 접두사를 증명합니다.
    2. Complete-Output Lineage Mode: 중개자가 스트림을 버퍼링, 재구성, 또는 집계하여 변형했을 때, 최종 완결된 출력의 계보 (Lineage) 를 증명합니다. 이 모드에서는 중간 체크포인트를 허용하지 않습니다.

• 신뢰할 수 있는 중개자 및 변환 (Trusted Transforms):

  • Request-Transform Receipts: 신뢰받는 중개자가 요청을 변형할 경우, 각 단계별 서명된 영수증 (Receipt) 을 체인으로 연결하여 원본 요청에서 유효한 요청 (Effective Request) 까지의 경로를 증명합니다.
  • Output-Transform Receipts: 출력 변형 (예: 민감 정보 마스킹, 스트림을 단일 객체로 변환) 이 발생했을 때, origin_output(원본 출력) 과 output_transforms(변환 체인) 를 통해 최종 출력의 출처와 변형 내역을 증명합니다.

3. 주요 기여 (Key Contributions)

1. 문제 정의 및 긴급성 제시: Shadow API 감사 결과를 바탕으로, LLM 서비스의 API 경계에서 직접적인 검증이 시급함을 주장했습니다.
2. AEX 프로토콜 제안: 기존 JSON API 에 비침투적으로 적용 가능한 증명 확장 프로토콜을 설계했습니다.
   • 요청/출력 커밋, 명시적 바인딩 모드, 서명된 변환 영수증, 출력 모드 인식 계보 메타데이터 등을 포함합니다.
3. LLM 특화 프로토콜 메커니즘 도입:
   • Dual-Anchor 스트리밍 해시 체인: 요청과 청크를 연결하여 무결성을 보장합니다.
   • 명시적 요청 변환 체인: 신뢰받는 중개자의 요청 변형을 검증 가능한 체인으로 만듭니다.
   • Source-Output / Output-Transform Receipt 모델: 신뢰받는 출력 재작성 및 변형을 추적합니다.
4. 보안 및 프라이버시 분석: TEE, 모델 지문 인식, HTTP 메시지 서명 등 기존 기술과의 차별성을 분석하고, 재전송 공격, 중개자 변조, 키 발견 악용 등에 대한 대응 방안을 제시했습니다.
5. 참조 프로토타입 및 검증: TypeScript 기반의 프로토타입을 구현하여 OpenAI 호환 Chat Completions API 시나리오에서 자동화된 일관성 테스트와 마이크로 벤치마크를 수행했습니다.

4. 실험 결과 및 성능 (Results)

• 프로토타입 검증:
  • 단위 테스트 (29 개), 통합 테스트 (25 개), 브라우저 E2E 테스트 (6 개) 를 모두 통과했습니다.
  • 요청 바인딩 모드, 스트리밍 체크포인트, 출력 계보 (Lineage) 검증, 부정적 경로 (Tampering, Truncation 등) 감지 등을 성공적으로 시연했습니다.
• 성능 오버헤드 (Microbenchmarks):
  • 단일 호스트 시뮬레이션 환경에서 측정된 결과, 암호화 작업으로 인한 오버헤드는 매우 낮았습니다.
  • 비스트리밍 성공: 클라이언트 완료 시간 약 2.287ms, 게이트웨이 검증 시간 약 0.495ms.
  • 스트리밍 성공 (체크포인트): 첫 번째 청크 도달 시간 약 1.736ms, 전체 완료는 시뮬레이션 지연으로 인해 약 243ms (암호화 오버헤드는 0.843ms 수준).
  • 변환 체인 및 계보: 추가적인 서명 검증과 JWKS(키 세트) 조회로 인해 검증 시간이 약간 증가했으나 (약 0.7~1.5ms), 전체 시스템에 미미한 영향을 미쳤습니다.

5. 의의 및 결론 (Significance & Conclusion)

• 실용적인 신뢰 계층 부재 해소: 기존 기술들이 모델의 정체성이나 실행 환경을 검증하는 데 집중했다면, AEX 는 API 트랜잭션 경계에서 "특정 요청이 특정 응답으로 이어졌음"을 증명하는 실질적인 계층을 제공합니다.
• 배포 용이성: 기존 API 형식 (JSON, SSE) 을 변경하지 않고 최상위 필드만 추가하므로, 기존 SDK 및 게이트웨이와 쉽게 통합할 수 있습니다.
• 신뢰 모델의 정교화:
  • 모든 변조를 '악의적인 변조'로 간주하는 것이 아니라, 신뢰받는 중개자에 의한 '명시적 변환'을 검증 가능한 체인으로 관리함으로써, 실제 배포 환경의 복잡성 (프록시, 필터링, 집계 등) 을 수용합니다.
  • 스트리밍과 비스트리밍, 그리고 그 사이의 변환을 명확히 구분하여 오해를 방지합니다.
• 한계 및 향후 과제:
  • AEX 는 모델의 사실성 (Truthfulness) 이나 숨겨진 프롬프트 존재 여부를 증명하지는 않습니다 (이는 TEE 나 모델 지문 인식 등 다른 기술과 보완적으로 사용되어야 함).
  • v1 버전에서는 변형된 출력의 '접두사 - 접두사' 증명 (Prefix-to-Prefix) 을 지원하지 않으며, 완전한 출력 계보 (Complete-Output Lineage) 만 지원합니다.
  • 표준화 (키 발견 메타데이터, 프로파일 레지스트리 등) 와 다양한 언어 간 상호운용성 검증이 필요합니다.

결론적으로, AEX 는 LLM API 생태계에서 발생하는 신뢰 위기에 대응하기 위해, 기존 인프라를 해치지 않으면서도 검증 가능한 요청 - 응답 바인딩과 출력 계보를 제공하는 혁신적인 프로토콜 제안입니다.