12. 보안, 권한, 샌드박스 전략
Hermes Agent는 똑똑합니다. 그런데 문제는, 똑똑한 에이전트가 터미널도 쓰고, 파일도 읽고, 웹도 뒤지고, 메시징 앱으로도 들어온다는 데 있습니다. 편리함은 곧 힘이고, 힘은 곧 위험이 됩니다. 그래서 Hermes를 오래 잘 쓰려면 모델 성능만큼이나 보안 설정을 신경 써야 합니다.
특히 이 장에서 기억해야 할 문장은 하나입니다. 강한 에이전트일수록 "무엇을 할 수 있나"보다 "어디까지 허용할 것인가"가 더 중요하다는 점입니다.
왜 보안은 옵션이 아니라 기본값인가
Hermes는 단순한 채팅봇이 아닙니다. 파일을 수정하고, 셸 명령을 만들고, 크론으로 혼자 일하고, 게이트웨이를 통해 외부 메시지도 받습니다. 이런 시스템에서 보안 사고는 보통 거창하게 시작되지 않습니다. rm 한 줄, 잘못 열린 허용 목록, 컨테이너에 넘긴 토큰 하나, 혹은 "잠깐만 YOLO 모드 켜둘까?" 같은 작은 편의가 출발점이 됩니다.
공식 문서가 강조하는 보안 철학은 심층 방어, 즉 한 겹이 뚫려도 다음 겹이 막아주는 구조입니다. Hermes는 사용자 인증, 위험 명령 승인, 컨테이너 격리, 자격 증명 필터링, 컨텍스트 파일 스캔, 세션 격리, 입력 검증 같은 여러 층을 겹쳐 두었습니다.1
쉽게 말해, Hermes 보안은 자물쇠 하나가 아니라 현관문, 도어락, 보조키, CCTV, 그리고 인터폰을 함께 두는 방식입니다.
Hermes 보안 모델의 큰 그림
실무에서는 이 보안층을 다 외우기보다, 세 가지 질문으로 이해하면 쉽습니다.
첫째, 누가 에이전트와 대화할 수 있는가입니다. 이것이 허용 사용자와 페어링 문제입니다.
둘째, 대화가 실제 시스템 명령으로 바뀔 때 누가 마지막 결정을 내리는가입니다. 이것이 승인 시스템입니다.
셋째, 명령이 실행되더라도 어디까지 피해가 퍼질 수 있는가입니다. 이것이 샌드박스와 자격 증명 관리 문제입니다.
이 세 가지가 맞물려야 안전합니다. 허용 사용자만 잘 막아도, 내부 사용자가 실수하면 사고가 납니다. 승인만 잘 받아도, 비밀 키가 컨테이너 안에 잔뜩 들어가 있으면 유출 위험이 커집니다. Docker만 써도, 누구나 봇에게 말을 걸 수 있게 열어 두면 다른 문이 열려 있는 셈입니다.
터미널 승인: 사람을 마지막 문지기로 두기
Hermes의 첫 번째 핵심 안전장치는 위험 명령 승인입니다. 터미널 명령을 실행하기 전에, 파괴적이거나 시스템에 큰 영향을 줄 수 있는 패턴을 감지하면 자동으로 멈추고 사용자 승인을 요구합니다.1
대표적으로 다음 같은 부류가 경고 대상입니다.
재귀 삭제나 루트 경로 삭제처럼 파일을 크게 날릴 수 있는 명령
chmod 777,chown -R root,mkfs,dd처럼 시스템 상태를 바꿀 수 있는 명령DROP TABLE,DELETE FROM처럼 데이터베이스를 망가뜨릴 수 있는 쿼리curl ... | sh같은 원격 스크립트 즉시 실행 패턴/etc,~/.ssh,~/.hermes/.env같은 민감 경로 덮어쓰기
중요한 점은, Hermes가 "명령 전체를 이해해서 완벽히 판정"하는 것이 아니라, 위험한 습관과 파괴 패턴을 먼저 잡아내는 방향이라는 것입니다. 즉, 똑똑한 판단 이전에 안전한 습관을 강제합니다.
CLI에서는 위험 명령이 감지되면 한 번만 허용할지, 현재 세션 동안 허용할지, 영구 허용 목록에 추가할지, 아니면 거부할지 고를 수 있습니다.1 여기서 가장 조심해야 할 선택은 "항상 허용"입니다. 오늘은 편해 보여도, 내일의 실수까지 통과시키는 문이 될 수 있기 때문입니다.
승인 모드 이해하기: manual, smart, off
Hermes의 승인 시스템은 보통 manual로 시작합니다. 이 모드에서는 위험 명령이 나올 때마다 사람이 직접 판단합니다.1
smart 모드는 보조 모델이 위험도를 먼저 가늠합니다. 비교적 안전한 명령은 자동 승인하고, 애매하거나 위험한 경우에만 사람에게 올립니다.1 체감상 덜 귀찮지만, 보안의 최종 책임은 여전히 사용자에게 있습니다. 똑똑한 비서가 문 앞에서 손님을 가려주는 것일 뿐, 집 열쇠를 맡긴 것은 아닙니다.
off는 이름 그대로 승인 장치를 끄는 모드입니다. 사실상 YOLO와 같은 의미입니다.1 자동화 파이프라인, 폐기 가능한 테스트 컨테이너, 완전히 신뢰되는 환경이 아니라면 권장하기 어렵습니다.
예를 들어 설정은 이렇게 잡을 수 있습니다.
approvals:
mode: manual # manual | smart | off
timeout: 60타임아웃도 중요합니다. 사용자가 응답하지 않으면 기본적으로 명령은 거부됩니다. 이것은 보안에서 자주 나오는 fail-closed, 즉 "확실하지 않으면 닫는다"는 원칙입니다.1
YOLO 모드: 빠르지만 안전벨트 없는 주행
Hermes에는 세션 단위로 YOLO 모드를 켜는 기능이 있습니다. CLI 플래그, 슬래시 명령 /yolo, 환경 변수로 활성화할 수 있습니다.1
이 기능은 편합니다. 정말 편합니다. 너무 편해서 문제입니다.
YOLO 모드가 켜지면 위험 명령 승인 프롬프트가 모두 사라집니다. 즉, 에이전트가 만든 명령을 사람이 한 번 더 보는 과정이 없어집니다.1 그래서 이 모드는 "능숙한 사용자용 고급 기능"이 아니라, 격리된 환경에서만 쓰는 위험 감수 기능으로 이해하는 편이 맞습니다.
실전 원칙은 단순합니다. 로컬 호스트에서는 끄고, 일회용 컨테이너 안에서만 잠깐 켜십시오.
Docker 격리: 명령을 믿지 말고 환경을 가둬라
에이전트 보안에서 가장 강력한 전략은 "나쁜 명령을 완벽히 막겠다"가 아니라, 혹시 실행되어도 피해 반경을 줄이겠다입니다. Hermes에서 그 역할을 하는 대표 수단이 Docker 백엔드입니다.12
Docker 백엔드를 쓰면 명령은 호스트가 아니라 컨테이너 안에서 실행됩니다. 공식 설정 문서 기준으로 Hermes는 Docker에서 기능을 덜어낸 최소 권한 원칙을 적용합니다. 모든 Linux capability를 제거하고 꼭 필요한 일부만 되돌리며, 권한 상승을 막고, 프로세스 수와 임시 파일 시스템 크기도 제한합니다.2
핵심은 이렇습니다.
컨테이너 안에서 실수한
rm -rf는 보통 호스트 전체가 아니라 컨테이너 범위 안에서 끝납니다.포크 폭탄 같은 무한 증식 시도도 PID 제한 덕분에 피해가 줄어듭니다.
/tmp,/var/tmp,/run같은 경로는 tmpfs와 옵션으로 제어되어 디스크 소진과 권한 상승 가능성을 낮춥니다.2
그래서 Hermes는 Docker, Singularity, Modal, Daytona 같은 컨테이너형 백엔드에서는 위험 명령 승인 검사를 생략할 수 있습니다. 이때의 보안 경계는 "명령 내용"이 아니라 "컨테이너 격리"가 되기 때문입니다.1
하지만 여기서 흔히 오해가 생깁니다. 컨테이너를 쓴다고 자동으로 안전해지는 것은 아닙니다. 컨테이너에 민감한 환경 변수를 잔뜩 넘기거나, CPU·메모리·디스크 제한을 사실상 무제한으로 풀어 두면, 격리의 의미가 크게 약해집니다.2
운영용으로는 보통 이런 식의 출발점이 좋습니다.
terminal:
backend: docker
docker_forward_env: []
container_cpu: 1
container_memory: 4096
container_disk: 20480
container_persistent: true
docker_network: false여기서 특히 눈여겨볼 값은 docker_forward_env: []입니다. 처음에는 비워 두고, 정말 필요한 변수만 하나씩 추가하는 편이 안전합니다.
샌드박스는 편의 기능이 아니라 피해 반경 제한 장치다
앞 장에서 Docker와 원격 백엔드를 배웠다면, 여기서는 관점을 조금 바꿔야 합니다. 성능이나 배포 편의보다 먼저 봐야 할 것은 "문제가 생겼을 때 어디까지 번지는가"입니다.
local 백엔드는 Hermes가 곧바로 내 운영체제 위에서 움직입니다. 내 사용자 권한 그대로 파일을 읽고 쓰게 됩니다.2 개발 중 빠르게 실험할 때는 편하지만, 상시 실행이나 메시징 게이트웨이 연결용으로는 부담이 큽니다.
ssh 백엔드는 실행 위치를 원격 서버로 분리할 수 있다는 장점이 있습니다. 다만 그 원격 서버가 실제 운영 서버일 수도 있으므로, 위험 명령 승인은 여전히 필요합니다.2
docker는 가장 균형이 좋습니다. 호스트를 직접 건드리지 않으면서도, 터미널 작업 자유도는 꽤 높습니다. 그래서 보안과 편의의 균형을 잡으려면 보통 Docker가 첫 선택이 됩니다.
한 문장으로 정리하면 이렇습니다. 로컬은 빠르지만 위험하고, SSH는 분리되지만 신중해야 하며, Docker는 일상 운영의 기본 샌드박스다.
허용 사용자 설정: 봇을 공개 계정처럼 두지 말기
메시징 게이트웨이를 쓰면 Hermes는 사실상 채팅 앱 안의 서버 인터페이스가 됩니다. 이때 가장 먼저 해야 할 일은 "누가 말을 걸 수 있는가"를 좁히는 것입니다.
Hermes 게이트웨이는 허용 사용자 목록과 페어링 시스템으로 접근을 통제합니다. 플랫폼별 허용 목록, 전역 허용 목록, 플랫폼 전체 허용, 전역 전체 허용 같은 규칙이 순서대로 적용되며, 아무 설정이 없으면 기본은 거부입니다.1
이 기본 거부는 아주 좋은 설계입니다. 초보자에게는 조금 불친절해 보여도, 보안에서는 "처음엔 아무도 못 들어오게"가 맞습니다.
예를 들어 .env에는 이런 식으로 넣을 수 있습니다.
TELEGRAM_ALLOWED_USERS=123456789
DISCORD_ALLOWED_USERS=111222333444555666
GATEWAY_ALLOWED_USERS=123456789반대로 아래 설정은 정말 조심해야 합니다.
GATEWAY_ALLOW_ALL_USERS=true
DISCORD_ALLOW_ALL_USERS=true이 값들은 테스트 중 "왜 봇이 내 말을 안 듣지?"라는 답답함을 즉시 해결해 줍니다. 그리고 동시에, 원하지 않던 사람의 메시지도 잘 듣게 만듭니다.1
DM 페어링: 미리 사용자 ID를 몰라도 안전하게 승인하기
Hermes는 낯선 사용자가 DM을 보내면 일회성 페어링 코드를 발급하고, 관리자가 CLI에서 그 코드를 승인하는 방식도 지원합니다.1 이것은 "처음부터 사용자 ID를 다 설정하기 번거롭다"는 현실적인 불편을 줄여 줍니다.
좋은 점은 두 가지입니다. 하나는 소유자가 직접 승인하기 전까지 접근이 열리지 않는다는 점이고, 다른 하나는 코드 만료 시간, 요청 빈도 제한, 실패 잠금 같은 보호 장치가 함께 들어 있다는 점입니다.1
즉, 페어링은 편의 기능이 아니라 통제된 온보딩 절차입니다. 팀에서 Hermes를 함께 쓸 때 특히 유용합니다.
만약 특정 플랫폼에서는 아예 응답조차 하지 않게 만들고 싶다면, 승인되지 않은 DM을 ignore로 처리하는 설정도 가능합니다.1
비밀 정보 관리: API 키는 기억이 아니라 금고에 넣기
Hermes를 오래 쓰다 보면 모델 키, 봇 토큰, GitHub 토큰, 패키지 레지스트리 자격 증명처럼 점점 더 많은 비밀 정보가 모입니다. 이때 가장 중요한 원칙은 비밀은 프롬프트가 아니라 환경 설정에 둔다는 것입니다.
Hermes의 설정 구조는 이를 명확히 나눕니다. 일반 설정은 ~/.hermes/config.yaml, 비밀 값은 ~/.hermes/.env에 두는 것이 기본입니다.2 hermes config set 명령도 API 키류는 자동으로 .env로 보내도록 설계되어 있습니다.2
즉, 다음은 좋은 습관입니다.
API 키, 봇 토큰, 비밀번호는
.env에 저장하기모델, 백엔드, 메모리, 표시 옵션은
config.yaml에 저장하기비밀 값을 대화창, MEMORY.md, SKILL.md, AGENTS.md에 직접 적지 않기
로그도 마찬가지입니다. 공식 설정 문서에 따르면 errors.log, gateway.log 같은 로그는 비밀 값이 자동 마스킹되도록 설계되어 있습니다.2 추가 문서에서는 로그, 도구 출력, MCP 오류 표면에서의 비밀 및 개인정보 마스킹까지 다루고 있습니다.3
하지만 자동 마스킹을 너무 믿으면 안 됩니다. 마스킹은 마지막 안전망이지, 비밀을 여기저기 뿌려도 된다는 면허증이 아닙니다.
환경 변수 전달은 최소화하기
Docker나 코드 실행 환경으로 환경 변수를 넘길 때는 특히 조심해야 합니다. 컨테이너 안의 코드도 결국 에이전트가 만든 코드일 수 있기 때문입니다.
Hermes는 기본적으로 명시한 변수만 전달하도록 설계되어 있습니다. Docker에서는 docker_forward_env, 일반 터미널 실행에서는 env_passthrough가 그 역할을 합니다.2 이 구조는 아주 바람직합니다. "전부 전달"이 아니라 "필요한 것만 전달"이 기본이기 때문입니다.
예를 들어 GITHUB_TOKEN이 꼭 필요하다면 괜찮지만, 범위가 지나치게 큰 클라우드 루트 키나 모든 저장소에 접근 가능한 만능 토큰은 피하는 편이 좋습니다. 에이전트가 유능할수록, 그 키도 유능한 공격 표면이 됩니다.
MCP 쪽도 같은 철학입니다. 공식 보안 문서는 MCP 하위 프로세스로 전달되는 자격 증명을 필터링하는 계층을 별도로 두고 있다고 설명합니다.1
위험 명령 차단 원칙: 패턴을 외우지 말고 원칙을 기억하기
Hermes가 막는 패턴을 전부 외울 필요는 없습니다. 대신 아래 원칙을 기억하면 대부분의 상황에서 올바르게 판단할 수 있습니다.
기본은 거부: 모르면 승인하지 마십시오. 특히 재귀 삭제, 권한 변경, 서비스 중지, 대량 SQL 수정은 한 번 더 확인합니다.
원격 스크립트 즉시 실행 금지:
curl | sh가 보이면 일단 멈춥니다. 내려받고, 읽고, 이해한 뒤 실행하는 습관이 안전합니다.13영구 허용은 아주 좁게: 자주 쓴다는 이유만으로 넓은 패턴을
command_allowlist에 넣지 마십시오. 오늘의 편의가 내일의 무심한 사고가 됩니다.1호스트보다 샌드박스 우선: 승인 절차를 줄이고 싶다면 YOLO보다 Docker를 먼저 선택하십시오.
비밀은 전달하지 않으면 유출되지 않는다: 가장 안전한 토큰은 잘 숨긴 토큰이 아니라, 애초에 그 실행 환경에 없는 토큰입니다.
이 원칙만 지켜도 보안 사고의 절반은 예방됩니다.
Tirith와 내용 기반 스캔: 명령 모양이 아니라 의도도 본다
패턴 기반 차단만으로는 부족한 경우가 있습니다. 예를 들어 겉보기엔 평범하지만, 유니코드 유사 문자 URL이나 터미널 이스케이프 시퀀스처럼 사람이 한눈에 놓치기 쉬운 위험도 있습니다. Hermes는 이런 영역을 위해 Tirith라는 사전 실행 스캐너를 추가 계층으로 둡니다.3
이 도구는 단순히 rm -rf 같은 노골적인 패턴만 보는 것이 아니라, 내용 수준의 위협을 탐지합니다. 대표적으로 동형 문자 URL, 파이프-투-인터프리터 체인, 터미널 인젝션 같은 문제를 다룹니다.3
중요한 해석은 이것입니다. Hermes 보안은 "나쁜 명령 리스트"만 운영하는 것이 아니라, 사람이 속기 쉬운 표현 방식까지 경계한다는 점입니다.
운영 환경별 추천 전략
보안 설정은 사용 환경에 따라 균형점이 달라집니다. 다음 세 가지 조합이 실전에서 많이 쓰입니다.
개인 노트북에서 실험할 때
빠른 테스트가 목적이라면 local 백엔드로 시작해도 됩니다. 다만 승인 모드는 manual로 유지하고, YOLO는 끄는 편이 좋습니다. 메시징 게이트웨이는 열지 않거나, 열더라도 본인 ID만 허용하십시오.
VPS에서 24시간 돌릴 때
이 경우는 docker 백엔드가 기본값에 가깝습니다. 승인 피로를 줄이기 위해서가 아니라, 사고 반경을 줄이기 위해서입니다. 허용 사용자는 플랫폼별로 명시하고, GATEWAY_ALLOW_ALL_USERS는 쓰지 마십시오. 비밀 값은 .env에만 두고, docker_forward_env는 가능한 한 빈 배열로 시작하십시오.
팀이 같이 쓰는 공유 인스턴스
가장 중요한 것은 사용자 분리와 승인 절차입니다. 허용 목록을 명확히 두고, DM 페어링으로 승인 흐름을 관리하는 것이 좋습니다. 명령 승인도 manual 또는 신중한 smart가 맞습니다. "팀 내부니까 괜찮겠지"보다 "팀 내부라서 더 명확해야 한다"가 운영 쪽 현실에 가깝습니다.
바로 적용하는 보안 체크리스트
설정을 마치고 마지막으로 아래 항목을 확인해 보십시오.
메시징 봇은 허용 사용자 목록이 설정되어 있는가
GATEWAY_ALLOW_ALL_USERS같은 전체 공개 옵션이 꺼져 있는가승인 모드는
manual또는 신중한smart인가호스트 대신 Docker 같은 샌드박스 백엔드를 쓰고 있는가
.env에만 비밀 정보를 두고, 대화나 메모리에 적지 않았는가docker_forward_env와env_passthrough는 최소한으로 줄였는가영구 허용 목록에 과도하게 넓은 패턴이 들어 있지 않은가
이 체크리스트는 화려하지 않습니다. 하지만 보안은 원래 화려함보다 반복이 강합니다.
마무리: 강한 에이전트일수록 더 작은 권한으로 시작하라
Hermes Agent의 매력은 강력함입니다. 도구를 쓰고, 작업을 자동화하고, 스스로 계속 일할 수 있다는 점이 바로 장점입니다. 그리고 같은 이유로, 보안은 부가기능이 아니라 사용법의 한가운데 있어야 합니다.
처음에는 답답해 보일 수 있습니다. 승인을 눌러야 하고, 허용 사용자를 넣어야 하고, 토큰 전달을 아껴야 하고, Docker까지 챙겨야 하니까요. 하지만 이 답답함이 바로 운영 안정성입니다. 브레이크가 좋은 차가 오래 타기 좋은 차이듯, 보안 설정이 탄탄한 Hermes가 결국 오래 믿고 맡길 수 있는 Hermes입니다.
다음 장에서는 실제 운영 중 자주 만나는 문제를 어떻게 진단하고 해결하는지, 체크리스트 중심으로 이어서 살펴보겠습니다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.