AI 에이전트를 증거로 취급해서는 안 되는 이유: EllipticZero Research Lab 구축하기

보안 검토(Security review)에서 대규모 언어 모델(Large Language Models, LLM)은 유용하지만, 위험한 유혹을 불러일으키기도 합니다. 모델의 출력물은 종종 그 이면에 있는 근거보다 더 확신에 찬 것처럼 들리기 때문입니다.

모델은 코드를 요약하고, 검토 방향을 제안하며, 가설을 생성하고, 설득력 있는 보고서를 작성할 수 있습니다. 이는 유용한 작업입니다. 하지만 모델의 문장은 증거(Proof)가 아닙니다. 스마트 컨트랙트(Smart-contract) 보안, 암호학(Cryptography), 액세스 제어(Access control), 자산 흐름(Asset flow), 서명 가정(Signing assumptions), 그리고 업그레이드 로직(Upgrade logic)에서 근거 없는 확신에 찬 답변은 단순히 노이즈에 그치지 않습니다. 그것은 검토자를 잘못된 리스크, 잘못된 수정 방식, 또는 잘못된 완료감으로 몰아넣을 수 있습니다.

저는 바로 그 경계선을 중심으로 EllipticZero Research Lab을 구축했습니다.

프로젝트:

https://github.com/ECD5A/EllipticZero

EllipticZero Research Lab은 특정 범위의 스마트 컨트랙트 보안 검토 및 방어적 ECC 연구를 위한 소스 공개형(Source-available) 로컬 우선(Local-first) 연구 워크플로우입니다. 핵심 아이디어는 간단합니다. 에이전트(Agents)는 계획, 가설, 비판, 그리고 보고서 구조를 돕는 데 사용할 수 있지만, 실질적인 주장(Substantive claims)은 로컬 도구(Local tools), 트레이스(Traces), 매니페스트(Manifests), 재현 가능한 아티팩트(Replayable artifacts), 내보낼 수 있는 보고서(Exportable reports), 그리고 인간의 검토(Human review)와 연결된 상태로 유지되어야 한다는 것입니다.

이 프로젝트는 자율 해킹 시스템이나 감사인(Auditors)을 대체하는 용도로 포지셔닝되지 않았습니다. 목표는 더 좁고 실용적입니다. 신중한 검토자가 무엇이 확인되었는지, 로컬 근거가 무엇을 뒷받침하는지, 무엇이 여전히 수동 검증(Manual validation)을 필요로 하는지, 그리고 검토 후에 어떤 아티팩트가 남는지 확인할 수 있도록 돕는 것입니다.

모델 전용 보안 출력의 문제점

컨트랙트를 LLM에 전달하고 버그를 찾아달라고 요청하면, 모델은 대개 무언가를 만들어냅니다. 때때로 그 무언가는 유용한 가설이 되기도 합니다. 때로는 얕은 탐지기 스타일(Detector-style)의 경고가 되기도 합니다. 때로는 도달 가능한 경로(Reachable path), 로컬 도구 출력, 소스 위치, 또는 재현 가능한 아티팩트와 연결되지 않은 그럴듯한 취약점 설명이 되기도 합니다.

이는 보안 검토에 부적합합니다.

검토자는 다음과 같은 사항을 알아야 합니다:

어떤 코드나 저장소 표면(surface)이 검사되었는지;
어떤 로컬 도구(local tools)나 체크가 신호(signals)를 생성했는지;
어떤 발견 사항이 증거에 의해 뒷받침되는지;
어떤 발견 사항이 단지 가설(hypotheses)뿐인지;
무엇이 여전히 인간의 검증(human validation)을 필요로 하는지;
나중에 실행을 어떻게 반복하거나 비교할 수 있는지;
약한 신호를 확정된 취약점으로 변질시키지 않고 결과를 어떻게 내보낼(export) 수 있는지.

이것이 바로 제가 AI 보조 보안 도구(AI-assisted security tools)가 에이전트의 추론(agent reasoning)보다 증거 경계(evidence boundaries)를 우선하여 설계되어야 한다고 생각하는 이유입니다.

증거 우선, 에이전트 차선

EllipticZero Research Lab의 작동 규칙은 다음과 같습니다:

에이전트는 가설을 제안하고, 검토를 구조화하며, 결론을 비판할 수 있습니다. 증거는 로컬 체크, 아티팩트(artifacts), 트레이스(traces), 매니페스트(manifests), 리플레이 번들(replay bundles), 그리고 인간의 검증(human validation)에 남습니다.

이는 시스템의 형태를 변화시킵니다.

에이전트는 최종 권위자가 아닙니다. 에이전트는 워크플로(workflow)의 일부입니다. 에이전트는 다음에 무엇을 검사할지 결정하는 것을 도울 수 있고, 왜 특정 리스크 경로(risk lane)가 중요한지 설명할 수 있으며, 노이즈가 많은 출력을 읽기 쉬운 검토 큐(review queue)로 변환할 수 있습니다. 하지만 텍스트가 강하게 들린다고 해서 발견 사항이 더 강력해져서는 안 됩니다.

유용한 출력은 "AI가 버그를 발견했다"가 아닙니다. 유용한 출력은 다른 사람이 검사할 수 있는 검토 아티팩트(review artifact)입니다.

워크플로가 구조화되는 방식

EllipticZero Research Lab은 몇 가지 계층을 중심으로 구성됩니다.

첫 번째 계층은 로컬 컨텍스트(local context)입니다: 컨트랙트 코드, 저장소 인벤토리(repository inventory), 선택된 도메인, 로컬 도구 가용성, 합성 케이스(synthetic cases), 저장된 세션, 그리고 아티팩트(artifacts)입니다. 워크플로는 실행 중에 실제로 사용 가능했던 것들을 보존하도록 설계되었습니다.

두 번째 계층은 경계가 지정된 에이전트 작업(bounded agent work)입니다. 에이전트의 역할은 수학, 암호학, 전략, 가설, 비판, 그리고 보고를 도울 수 있습니다. 그들의 임무는 검토 프로세스를 개선하는 것이지, 근거 없는 진술을 증거로 변환하는 것이 아닙니다.

세 번째 계층은 아티팩트 계층 (artifact layer)입니다: 세션 (sessions), 트레이스 (traces), 매니페스트 (manifests), 리플레이 번들 (replay bundles), Markdown 보고서, SARIF 내보내기 (exports), 증거 커버리지 (evidence coverage), 툴체인 핑거프린트 (toolchain fingerprints), 그리고 비식별화된 JSON 스냅샷 (redacted JSON snapshots) 등이 여기에 해당합니다. 만약 결과물을 나중에 검토할 수 없다면, 진지한 검토를 위한 유용성은 훨씬 떨어지게 됩니다.

네 번째 계층은 검토자 (reviewer)입니다. 보고서는 무엇이 관찰되었는지, 무엇이 추론되었는지, 어떤 증거가 존재하는지, 무엇이 취약한지, 그리고 무엇을 수동으로 확인해야 하는지를 명확히 밝혀야 합니다.

스마트 컨트랙트와 ECC를 선택한 이유

스마트 컨트랙트 (Smart contracts)는 다음과 같이 반복 가능한 검토 경로 (review lanes)를 가지고 있기 때문에 이러한 워크플로우를 적용하기에 유용한 첫 번째 도메인입니다:

접근 제어 (access control);
업그레이드 및 스토리지 레이아웃 (upgrade and storage layout);
자산 흐름 (asset flow);
금고 및 지분 회계 (vault and share accounting);
오라클 가정 (oracle assumptions);
서명 (signatures);
보상 (rewards);
AMM 및 유동성 로직 (AMM and liquidity logic);
브리지 및 커스터디 접점 (bridge and custody surfaces);
스테이킹 및 재무 로직 (staking and treasury logic).

이러한 경로들은 반복 가능한 검토를 지원할 만큼 충분히 구조화되어 있으면서도, 과도하게 자신감 있는 자동화가 위험할 만큼 충분히 위험합니다.

예를 들어, "외부 호출(external call)이 존재한다"는 것이 "익스플로잇 가능한 재진입(reentrancy) 버그가 존재한다"와 동일한 의미는 아닙니다. "관리자 함수(admin function)가 존재한다"는 것이 "심각한 접근 제어 취약점(access-control vulnerability)이 존재한다"와 동일하지도 않습니다. 유용한 워크플로우에는 컨텍스트 (context), 도달 가능성 (reachability), 상태 전이 추론 (state transition reasoning), 로컬 신호 (local signals), 그리고 명확한 수동 검토 경계 (manual-review boundary)가 필요합니다.

ECC 측면은 방어적 연구 (defensive research)로서 포함되었습니다: 포인트 형식 (point formats), 곡선 메타데이터 (curve metadata), 부서/공약수 체크 (subgroup/cofactor checks), 트위스트 위생 (twist hygiene), 인코딩 경계 (encoding boundaries), 그리고 곡선 제품군 일관성 (curve-family consistency) 등이 해당됩니다. 이는 로컬 계산 (local computation) 없는 모델의 확신만으로는 충분하지 않은 또 다른 영역입니다.

유용한 결과물이란 무엇인가

목표로 하는 결과물은 "10개의 심각한 버그"와 같은 극적인 목록이 아닙니다. 더 나은 결과물은 다음과 같은 신중한 검토 스냅샷 (review snapshot)입니다:

발견 카드 (finding cards);
리스크 경로 (risk lanes);
가능한 경우 소스 라인 힌트 (source-line hints);
로컬 툴 신호 (local tool signals);
증거 커버리지 (evidence coverage);
신뢰도 노트 (confidence notes);
수동 검토 경계 (manual-review boundaries);
해결 방향 (remediation direction);
재확인 경로 (recheck path);
재현성 번들 (reproducibility bundle).

그것은 AI가 생성한 감사 주장 (audit claim)보다 덜 화려하지만, 더 유용합니다.

만약 스마트 컨트랙트 (smart-contract) 골든 케이스 (golden case)가 실행된다면, 시스템은 잠재적 위험뿐만 아니라 왜 검토 대기열 (review queue)에 진입했는지, 어떤 로컬 증거 (local evidence)가 존재하는지, 무엇이 아직 확인되지 않았는지, 그리고 검토자가 어떻게 결과를 반복하거나 내보낼 수 있는지(export)를 보여주어야 합니다.

Markdown, SARIF, 그리고 Replay가 중요한 이유

보안 워크플로 (security workflows)에는 내보내기 (exports) 기능이 필요합니다.

Markdown은 사람들이 읽을 수 있고, 전송할 수 있으며, 토론에 첨부하거나 이전 실행 결과와 비교할 수 있고, 검토 패킷 (review packet)으로 사용할 수 있기 때문에 유용합니다.

SARIF는 코드 스캐닝 (code-scanning) 및 CI와 유사한 워크플로에 통합될 수 있기 때문에 유용합니다. 하지만 SARIF 출력은 주의가 필요합니다. SARIF 항목이 내보내기 결과에 존재한다는 이유만으로 자동으로 확인된 취약점 (confirmed vulnerability)이 되어서는 안 됩니다. AI 보조 워크플로 (AI-assisted workflow)에서 내보내진 항목은 검토 항목 (review item), 로컬 신호 (local signal), 또는 여전히 검증이 필요한 가설 (hypothesis)일 수 있습니다.

Replay (재생)와 재현성 (reproducibility)도 비슷한 이유로 중요합니다. 만약 검토 결과를 나중에 다시 방문하거나, 비교하거나, 설명할 수 없다면, 팀이나 클라이언트 또는 감사인 (auditor) 앞에서 이를 방어하기 어렵습니다.

Mock Mode가 중요한 이유

이 프로젝트는 설정 시 호스팅된 제공자 (hosted providers)를 지원하지만, 키가 필요 없는 평가 경로 (no-key evaluation path)도 유지합니다.

이것이 중요한 이유는 평가자 (evaluator)가 외부 모델 제공자 (model provider)를 먼저 신뢰하거나 개인 코드를 어디론가 전송하지 않고도 워크플로의 형태를 조사할 수 있어야 하기 때문입니다. 로컬 검토자는 실제 모델을 구성할지 결정하기 전에 자체 점검을 수행하고, 골든 케이스 (golden cases)를 열고, 보고서 형태를 조사하며, 내보내기 동작을 확인할 수 있어야 합니다.

보안 도구에 있어 Mock 모드 (mock mode)는 단순한 편의 기능이 아닙니다. 그것은 평가 경계 (evaluation boundary)의 일부입니다.

현재 프로젝트 형태

현재 리포지토리 (repository)에는 다음이 포함되어 있습니다:

대화형 CLI 워크플로우 (interactive CLI workflow);
범위가 지정된 스마트 컨트랙트 (smart-contract) 리뷰 레인 (lanes);
방어적 ECC 연구 경로 (defensive ECC research paths);
제한된 에이전트 역할 (bounded agent roles);
로컬 우선 증거 처리 (local-first evidence handling);
평가 가이드 및 골든 케이스 (golden cases);
재현성/세션 아티팩트 (reproducibility/session artifacts);
리플레이 번들 경로 (replay bundle path);
Markdown 보고서 내보내기 (Markdown report export);
SARIF 리뷰 내보내기 (SARIF review export);
벤치마크 스코어카드 (benchmark scorecards);
보안 및 데이터 처리 경계 (security and data-handling boundaries);
호스팅, OEM, 화이트 라벨 (white-label), 재판매 및 유료 플랫폼 사용 사례를 위한 상업적 라이선스 문서화.

이 프로젝트는 소스 공개 (source-available) 형태이며, 일반적인 허용적 의미의 오픈 소스 (open source)는 아닙니다. 게시된 라이선스 약관에 따라 로컬에서 읽고, 평가하고, 실행할 수 있습니다. 상업적 제품화 경로에는 별도의 상업적 라이선스가 필요합니다.

피드백을 받고 싶은 부분

제가 관심을 두는 주요 질문은 "AI가 스마트 컨트랙트 (smart contracts)를 감사할 수 있는가?"가 아닙니다.

더 나은 질문은 다음과 같습니다:

AI 지원 보안 리뷰는 모델의 추론 (reasoning)과 증거 (evidence) 사이의 경계를 어떻게 유지해야 하는가?

저는 특히 다음 사항에 대한 피드백에 관심이 있습니다:

증거 모델 (evidence model) 및 보고서 형태 (report shape);
SARIF 내보내기 경계 (SARIF export boundaries);
수동 리뷰 태세 (manual-review posture);
골든 케이스 (golden case) 평가;
스마트 컨트랙트 (smart-contract) 리뷰 레인 (lanes);
방어적 ECC 연구 작업 (defensive ECC research tasks);
워크플로우에서 신뢰도 (confidence)에 대해 더 엄격해야 할 지점.

프로젝트는 여기에 있습니다: