【#10】Hermes Agent 해독하기

연재 「Hermes Agent 해독하기」 제10회 (최종회).

지금까지 9회에 걸쳐 Hermes의 능력을 찬양해 왔다. 대화 루프 (Conversation loop), 기억의 재주입, 71개의 도구 (Tools), 멀티 에이전트 (Multi-agent), Kanban, 40개 이상의 노출면, 확장 메커니즘. 하지만 이것들은 모두 양날의 검이다. 도구를 호출할 수 있는 에이전트는 잘못된 도구를 호출할 수도 있다. 다면적으로 열려 있는 코어는 다면으로부터 공격받을 수 있다. 최종회에서는 지금까지 "제10회에서"라며 미뤄두었던 리스크를 청산하고, 안전 운용 지침을 정리한다.

SECURITY.md

가 중심적으로 다루는 위협은 **프롬프트 인젝션 (Prompt Injection)**이다. 신뢰할 수 없는 입력 (웹 페이지, 수신 메시지, 도구의 반환값) 속에 에이전트에 대한 명령이 섞여 들어가고, 그것이 **파괴적인 명령 실행 (Destructive command execution)**으로 이어지는 것——이것이 최대의 우려 사항이다.

여기에서 중요한 설계 사상이 있다. Hermes의 프로세스 내 휴리스틱 (Heuristics) (제5회의 DANGEROUS_PATTERNS 등)은 "경계 (Security boundary)가 아니라 사고 방지 (Accident prevention)"로 위치 지어지고 있다. 즉, "rm -rf를 차단하는 것"은 악의적인 공격자를 막는 방벽으로서가 아니라, 에이전트의 실수를 줄이는 안전장치로서 설계되었다는 뜻이다. 진심인 공격자를 전제로 한 경계는 프로세스 외부 (OS 권한, 컨테이너, 네트워크 분리)에서 그어야 한다는 절단이다. 이 구분을 오해하면 "Hermes가 패턴 매칭을 하고 있으니 안전하다"라고 과신하다가 사고를 친다.

리스크	내용
평문 자격 증명	.env / auth.json이 평문 (제1회). 읽히면 모든 키가 유출됨
--yolo	모든 승인을 스킵 (제5회). 프롬프트 인젝션과 결합되면 최악
서명 없는 자동 업데이트	hermes update가 서명 검증이 없으면 업데이트 경로가 공격면이 됨
공개 바인딩	Gateway를 0.0.0.0으로 노출하거나, API를 루프백 외부로 내보냄 (제8회)

가장 위험한 조합은 --yolo × 프롬프트 인젝션이다. 승인 게이트를 전부 제거한 상태에서 악의적인 입력에 "rm -rf ~를 실행하라"라고 적혀 있다면, 막을 수 있는 것이 없다. --yolo는 "사고 방지조차 끄는" 스위치라고 이해해야 한다. 실운용에서 최소한으로 지켜야 할 8가지 항목.

• chmod 600: .env / auth.json의 권한을 소유자에게만 제한
• yolo 무효화: --yolo를 상용하지 않는다. 승인은 번거롭더라도 남겨둔다
• gateway 루프백: OpenAI 호환 API는 127.0.0.1 상태로 유지. 외부로 내보낸다면 인증 필수
• 스킬 / 플러그인 리뷰: 제9회의 4가지 소스, 특히 user / project / pip를 넣기 전에 내용을 읽을 것
• terminal 백엔드 격리: 쉘 실행은 컨테이너나 전용 사용자로 격리. HERMES_HOME 프로파일 분리 (제9회)도 활용
• 업데이트 리뷰: hermes update의 차분을 확인한 후 적용. rolling main은 하루 만에 크게 변한다
• allowlist: 도구나 명령은 허용 리스트 방식으로 제한
• 로그 모니터링: ~/.hermes/logs를 모니터링하여 예상치 못한 도구 실행을 감지

이 리스트는 "Hermes를 신뢰할 수 없어서" 만드는 것이 아니다. 에이전트에게 terminal이나 computer_use를 맡기는 이상, 인간 측이 경계를 그릴 책임이 있다는 이야기다. 제1절의 "휴리스틱은 경계가 아니다"라는 점이 여기서 적용된다.

10회에 걸쳐 Hermes의 코드를 읽어왔다. 마지막으로 총괄한다.

거대 모놀리스 (Monolith) vs 모듈화의 공존. gateway/run.py는 19,741행, cli.py는 15,994행, conversation_loop.py는 4,836행——주요 파일은 나란히 거대하다. 반면 tools/는 1개 도구당 1개 파일에 가깝고, plugins/의 kind별 로드나 MemoryProvider ABC와 같이 확장점은 깔끔하게 추상화되어 있다. **"코어는 두껍게, 주변부는 느슨한 결합 (Loosely coupled)"**이라는 구조로, 읽기 쉬움과 통짜의 무게감이 공존하고 있다.

승인의 휴리스틱 의존 (Heuristic dependency). 제5회 및 이번 회차에서 보았듯이, 안전 기제(Safety mechanism)의 상당수가 패턴 매칭(Pattern matching)에 의존한다. 이는 '사고 방지'로서는 타당하지만, 이를 '경계 (Boundary)'와 혼동해서는 안 된다. 설계자 스스로가 이를 명시하고 있다는 점은 정직하다.

신구 CLI의 병존. cli.py (15,994행)와 hermes_cli/main.py (15,674행)가 공존하고 있다. 이는 이행 과정 중의 흔적으로, rolling main을 읽을 때 혼란을 주는 원인이기도 하다 (제1회의 버전 삼층 문제와 뿌리가 같은 '계속해서 움직이는 코드베이스'의 숙명이다).

제4회에서 내세웠던 테제(Thesis)로 돌아가 보자. 인격 = 지능 × 기억.

Hermes의 코드를 10번에 걸쳐 읽으며 확신한 것은, 에이전트의 '다움'은 모델(지능)만으로 결정되지 않는다는 사실이다. 대화를 접는 압축, 그것을 다시 불러오는 기억의 재주입, SOUL.md의 씨앗, 프로파일에 의한 문맥(Context)의 분리——이러한 요소들이 결합되어야 비로소 휘발되는 context 위에 연속적인 인격이 세워진다.

그리고 최종회의 주제였던 보안(Security)은, 그 인격에 **경계 (Boundary)**를 부여하는 작업이다. 무엇이든 할 수 있는 에이전트는, 무엇을 해서는 안 되는지를 인간이 결정하지 않으면 위험하다. 지능과 기억이 인격을 만들고, 경계가 그것을 안전하게 세상과 연결한다.

자신의 에이전트 내부를 읽는다는 것은, 결국 자신이 무엇을 맡기고 무엇을 맡기지 않을지를 결정하는 일이었다. 이 연재가 독자 여러분 자신의 '상자 안'을 들여다보는 데 도움이 되기를 바란다.

연재 제1회는 이쪽

대응 맵 장: §7, §8 / 행 번호는 hermes update에 따라 어긋날 수 있음