Hermes Agent의 기술 신뢰 모델은 4개 리포지토리 허용 목록 방식입니다

지금까지 저는 OpenClaw 에이전트만을 실행해 왔으며, 그 과정에서 가파른 학습 곡선을 경험했습니다. 이 여정 속에서 "자기 개선 (self-improvement)"은 매우 매력적인 용어가 되었습니다. 그래서 저는 Nous Research에서 만든 자기 개선 에이전트 런타임(runtime)인 Hermes Agent를 깊이 있게 살펴보았습니다. 제가 가장 먼저 이해하고 싶었던 것 중 하나는 리스크였습니다. 즉, 커뮤니티 기술 (skill)을 설치할 때 실제로 어떤 일이 발생하는가 하는 점입니다. 기술 (skills)은 에이전트가 실행할 코드와 지침이며, Hermes는 이를 개방형 생태계에서 가져옵니다. 그래서 저는 문서를 맹목적으로 믿는 대신 소스 코드에서 설치 경로를 직접 읽어보았습니다.

제가 발견한 것은 어떤 면에서는 기대보다 나았지만, 구조적으로는 제한적이었습니다.

Hermes가 이미 갖추고 있는 것

Hermes는 외부 기술 (external skills)을 맹목적으로 설치하지 않습니다. 외부에서 가져온 모든 기술은 디스크에 저장되기 전에 실제 게이트(gate)를 거칩니다. hermes_cli/skills_hub.py에서 설치 흐름은 다음과 같습니다: 가져오기(fetch) → 격리(quarantine) → 스캔(scan) → 정책 결정(policy decision) → 설치 또는 차단 및 감사(install or block-and-audit).

스캔 기능은 tools/skills_guard.py에 있으며, 알려진 악성 패턴에 대해 정규 표현식(regex) 기반의 정적 분석(static analysis)을 실행합니다: 비밀 정보 유출 (curl이 $API_KEY/$TOKEN/$SECRET를 보간하는 경우), 자격 증명 저장소 읽기 (~/.ssh, ~/.aws, ~/.gnupg, ~/.kube, 그리고 Hermes 자체의 ~/.hermes/.env), 파괴적인 명령, 지속성(persistence), 그리고 난독화(obfuscation) 등이 대상입니다. 만약 스캔이 설치를 차단하면, 격리된 복사본은 삭제되고 해당 이벤트는 감사 로그(audit log)에 기록됩니다.

이는 대부분의 에이전트 도구가 제공하는 것보다 더 많은 기능을 포함하고 있습니다. 경쟁 생태계들을 휩쓸었던 악성 기술 (malicious skills)의 물결을 기억하신다면, 그러한 유형의 공격 중 상당 부분이 실행되기 전에 여기서 차단되었을 것입니다. 누군가는 이 부분을 고려했던 것입니다.

제 생각에 확장성이 떨어지는 부분

스캐너는 safe (안전), caution (주의), 또는 dangerous (위험)라는 판결을 내립니다. 그 판결은 설치 여부를 결정하기 위해 _신뢰 수준 (trust level)_과 결합됩니다. 신뢰 수준과 그 정책은 다음과 같습니다:

INSTALL_POLICY = {
    #              safe      caution    dangerous
    "builtin":   ("allow",  "allow",   "allow"),
...

중요한 질문은 이것입니다: 스킬이 어떻게 community 이상의 신뢰 수준을 얻을 수 있는가? 그 답은 하드코딩된 리스트입니다.

TRUSTED_REPOS = {
    "openai/skills",
    "anthropics/skills",
...

_resolve_trust_level() 함수는 해당 소스를 그 집합과 대조하여 확인합니다. 네 가지 중 하나와 일치하면 trusted가 됩니다. 그 외 세상의 모든 것은 community로 결정되며, 이는 caution 또는 그보다 더 나쁜 결과가 발견될 경우 설치가 즉시 차단됨을 의미합니다.

구조적인 문제를 명확히 말씀드리자면 다음과 같습니다: 발행자 신원 (publisher identity)에 대한 개념이 없으며, 쌓아온 평판 (earned reputation)에 대한 개념도 없습니다. 1년 동안 깨끗하고 유용한 스킬을 배포해 온 커뮤니티 발행자는 5분 전에 생성된 계정과 정확히 동일한 지위를 갖습니다. Hermes 유지 관리자가 4개의 항목으로 구성된 Python set에 추가해 주는 것 외에는 community에서 벗어날 방법이 없습니다. 신뢰는 네 개의 조직에 중앙 집중화되어 있으며, 이는 정적 (static)입니다.

정적 허용 목록 (static allowlist)이 잘못된 기본 요소인 이유

소프트웨어 공급망 (software supply-chain) 세계는 이미 오래전에 "누가 이것을 발행했는가, 그리고 그들이 이를 증명할 수 있는가?"라는 문제를 해결했습니다. Sigstore와 cosign은 아티팩트 서명 (artifact signing)을 저렴하고 키리스 (keyless) 방식으로 만들었습니다. SLSA는 우리에게 출처 (provenance) 수준을 제공했습니다. NIST의 보안 소프트웨어 개발 프레임워크 (Secure Software Development Framework, SP 800-218)는 발행자 증명 (publisher attestation)을 있으면 좋은 기능이 아닌 기본 기대 사항으로 만들었습니다. 다른 모든 분야의 발전 방향은 선별된 이름 목록이 아니라, *검증 가능한 신원 (verifiable identity)과 증명 (attestation)*입니다.

또한 신원이 무엇을 해주고 무엇을 해주지 못하는지에 대한 뼈아픈 교훈도 있습니다. xz-utils 백도어 (CVE-2024-3094) 사례를 생각해 보십시오. "Jia Tan"이라는 페르소나 뒤에 숨은 공격자는 약 3년 동안 xz-utils에 정당한 작업을 기여하며 공동 유지 관리자 (co-maintainer) 지위를 얻었고, 그 후에야 백도어를 배포했습니다. 이는 수년간의 실제 기여 속에 숨겨진 약 8개의 악성 커밋이었습니다. 평판 시스템이 있었다면, 그 계정이 변절하는 순간 전까지는 해당 계정에 높은 점수를 부여했을 것입니다.

이 주장의 부정직한 버전은 어디에나 있습니다. 즉, 검증된 신원(verified identity)이 발행자를 안전하게 만드는 것은 아닙니다. 그럴 수는 없습니다. 신원이 하는 역할은 경제적 구조와 사후 처리 방식을 바꾸는 것입니다. 익명이며, 무료이고, 무한히 다시 생성할 수 있는 신원은 악의적인 기술(skill)을 비용이 들지 않고 반복 가능한 수단으로 만듭니다. 반면, 구축하는 데 비용이 드는 고정된 신원(Anchored identity)은 변절을 자산을 소진하게 만드는 단 한 번의 기회(one-shot)로 바꿉니다. 그리고 결정적으로, 무언가 잘못되었을 때 신원은 귀속(attribution), 취소(revocation), 그리고 사후 분석(post-mortem)을 가능하게 하는 근거가 됩니다. 신원이 없다면 누가 그것을 배포했는지조차 알 수 없으며, 그것을 신뢰한 모든 이들에게 취소 조치를 전파할 수도 없습니다. xz 사례는 압력을 가하던 가짜 계정(sock-puppet accounts)들이 빈약하고 최근에 생성된 이력을 가지고 있었다는 점을 상기시켜 주며, 이는 바로 신원 계층(identity layer)이 드러내 주는 신호와 정확히 일치합니다.

정직한 프레임워크는 다음과 같습니다. 신원 계층은 선함을 판별하는 신탁(goodness oracle)이 아니라, 피해 제한 인프라(damage-limitation infrastructure)입니다. 정적인 허용 목록(allowlist) 방식은 (당연하게도) 선함의 신탁도 제공하지 못하며, 피해 제한 기능도 제공하지 못합니다(귀속하거나 취소할 대상이 없기 때문입니다). 그것은 단지 보호해야 할 생태계와 함께 확장되지 못할 뿐입니다.

더 작은 발견 사항

정책을 읽는 동안 한 가지 기본 설정이 눈에 띄었습니다. 에이전트가 생성한(agent-created) 기술에 대한 게이트(skills.guard_agent_created)가 기본적으로 꺼져 있습니다. 이 설정이 꺼져 있으면, 에이전트가 스스로 작성한 기술은 dangerous-콘텐츠 게이트의 적용을 전혀 받지 않습니다. agent-created 정책 행은 존재하지만, 운영자가 직접 선택(opt in)해야만 실행됩니다. 에이전트가 자신의 기술을 직접 작성하고 재사용하는 것이 핵심 기능인 시스템에서, 이러한 기본 설정은 재검토할 가치가 있습니다.

대신 제안하는 사항

흥미로운 점은 Hermes가 이미 서명된 기술(signed skills)을 수용하고 있다는 것입니다. 다만 폐쇄적인 리포지토리별(per-repo) 방식으로 수행할 뿐입니다. NVIDIA/skills 항목은 서명된 skill.oms.sig와 거버넌스용 skill-card.md를 함께 배포하며, 동기화 파이프라인은 이들이 누락된 모든 것을 제외합니다. 이는 정확히 단 하나의 벤더만을 겨냥한 올바른 메커니즘입니다.

이를 일반화하십시오. 서명과 신원을 하드코딩하는 대신 개방형으로 만드십시오.

엔트리 포인트 (entry point)를 통해 로드되는 플러그형 출처 검증기 (pluggable provenance-verifier) 인터페이스를 추가하되, 기본적으로는 비활성화 (off by default) 상태로 유지합니다 (따라서 기존 동작은 변경되지 않으며 코어는 특정 벤더에 대한 의존성을 갖지 않습니다).
trusted와 동일한 정책인 ("allow", "allow", "block")을 가진 새로운 신뢰 수준 verified를 추가합니다. 이것이 핵심적인 설계 결정입니다. 검증된 게시자 (verified publisher)는 caution 허용치를 얻게 되며, dangerous 판정은 여전히 차단되며 --force로도 절대 무시할 수 없습니다. 신원 (Identity)은 모호한 결과에 대해 의심을 피할 수 있는 이점을 제공할 뿐, 위험한 코드를 실행할 수 있는 권한을 부여하지는 않습니다. 이것이 이 기술을 가짜 약 (snake oil)과 구분 짓는 경계선입니다.
커뮤니티 게시자가 탈중앙화 식별자 (decentralized identifier, DID)를 고정하고 자신의 기술 매니페스트 (skill manifest)에 서명하면, 검증기가 서명을 확인하고 해당 신원을 평판 (reputation)으로 해석합니다. 통과할 경우, 해당 소스는 누구의 하드코딩된 목록에도 추가되지 않고도 community 수준에서 벗어날 수 있습니다.

코어에 가해지는 변경 사항은 작고 정밀합니다. 선택적 검증기, 하나의 정책 행, 그리고 dangerous 판정에 대해 --force로 무시할 수 없는 세트에 verified를 추가하는 단 한 줄의 코드뿐입니다. 스캐너는 수정되지 않았으며 여전히 모든 대상에 대해 실행됩니다. 기존의 기본 설정을 약화시키는 경로는 존재하지 않습니다.

누군가 코드를 한 줄이라도 작성하기 전에 이 문제를 논의하기 위해 디자인 토론을 시작했습니다. 보안에 민감한 모듈에 갑작스러운 PR (Pull Request)을 보내는 것은 잘못된 시작 방식이기 때문입니다. 공급망 신뢰 (supply-chain trust)에 대해 고민해 본 분들의 피드백을 환영합니다.

공개 사항 (Disclosure)

저는 자율 에이전트를 위한 DID/검증 가능한 자격 증명 (Verifiable-Credential) 신원 계층인 MolTrust를 구축하고 있으므로, 에이전트가 검증 가능한 신원 스토리를 갖는 것에 직접적인 이해관계가 있습니다. 저는 위의 제안을 의도적으로 특정 벤더에 중립적으로 유지하려고 노력했습니다. 검증기 인터페이스는 범용적이며, 코어 변경 사항에는 MolTrust에 대한 의존성이 없고, MolTrust는 해당 인터페이스의 구현체 중 하나일 뿐 필수 요구 사항이 아닙니다. 메커니즘이 올바르다면, 누구의 검증기와도 작동해야 하며, 혹은 아무것도 사용하지 않을 때도 작동해야 합니다.