보안과 승인

기준일: 2026-07-26
문서 반영 버전: v2026.7.20
난이도: 고급
공식 기준: Security

Hermes는 로컬 명령, 파일, MCP, 메시징 플랫폼을 다룰 수 있으므로 보안 경계가 핵심입니다. 특히 터미널 권한을 가진 에이전트를 메신저까지 연결하면 “누가 말할 수 있는지”와 “무엇을 실행할 수 있는지”를 반드시 분리해야 합니다.

핵심 개념

공식 보안 모델은 여덟 층입니다.

층	질문
사용자 권한	누가 에이전트와 대화할 수 있는가 (allowlist, DM pairing)
위험 명령 승인	삭제·권한 변경 같은 명령은 어떻게 승인되는가
파일 쓰기 안전	보호 경로·HERMES_WRITE_SAFE_ROOT로 쓰기를 막는가
격리	Docker, Singularity, Modal, Daytona를 쓰는가
MCP credential filtering	MCP subprocess에 어떤 env가 전달되는가
컨텍스트 파일 스캔	프로젝트 파일의 prompt injection을 어떻게 다루는가
세션 격리	다른 세션 데이터에 접근하지 않는가
입력 검증	working directory와 명령 인자를 검증하는가

승인 모드 (기본값: smart)

# ~/.hermes/config.yaml
approvals:
  mode: smart                     # smart | manual | off  (기본 smart)
  timeout: 300
  cron_mode: deny                 # deny | approve
  mcp_reload_confirm: true
  destructive_slash_confirm: true
  deny:
    - "git push --force*"
    - "*curl*|*sh*"

mode	동작
smart (기본)	보조 LLM이 위험도를 판단. 저위험은 해당 명령만 자동 승인, 고위험은 자동 거부, 불확실하면 수동 프롬프트
manual	위험 패턴마다 항상 사용자 승인
off	승인 비활성 (--yolo와 동일 수준). 신뢰 환경에서만

v2026.7.20부터 smart approvals가 기본입니다. 판정은 그 정확한 명령 한 번에만 적용되며, 같은 패턴의 이후 명령은 다시 평가됩니다.

YOLO와 hardline blocklist

YOLO 활성화: hermes --yolo, 세션 중 /yolo, 또는 HERMES_YOLO_MODE=1.

그래도 hardline blocklist는 항상 적용됩니다 (rm -rf /, fork bomb, mkfs on root 등). YOLO·mode: off·cron approve로도 우회할 수 없습니다.

approvals.deny는 사용자 정의 hard deny입니다. YOLO/mode: off보다 먼저 매칭되며, 호스트에 닿는 백엔드(local, SSH, host-mounted Docker)에 적용됩니다.

파일 쓰기 보호

write_file / patch는 승인 프롬프트 없이 차단될 수 있습니다.

• 항상 차단: ~/.ssh/, ~/.aws/, Hermes auth.json/.env, 프로젝트 .env* 등
• 선택: HERMES_WRITE_SAFE_ROOT로 허용 루트 제한

터미널 도구는 동일 OS 사용자로 실행되므로, 쓰기로 막혀도 셸로 우회할 수 있습니다. 격리 백엔드가 진짜 경계입니다.

선택 기준

운영 환경	권장 기본값
개인 로컬 실험	smart 유지, 읽기 중심 시작
팀 프로젝트	allowlist, approvals.deny, MCP whitelist
메시징 게이트웨이	DM pairing 또는 allowed users 필수 (미설정 시 전원 거부)
자동화/cron	cron_mode: deny 기본 검토
민감 코드베이스	terminal.backend: docker + secret 분리

approvals.mode: off는 편하지만 로컬 파일과 외부 계정을 동시에 다룰 때 사고 범위를 키웁니다.

실습

현재 승인 설정 후보:

approvals:
  mode: smart
  timeout: 300
  cron_mode: deny
  deny:
    - "git push --force*"

게이트웨이 사용자 권한 (~/.hermes/.env):

TELEGRAM_ALLOWED_USERS=123456789
WHATSAPP_ALLOWED_USERS=15551234567
# GATEWAY_ALLOW_ALL_USERS=true  # 프로덕션 비권장

hermes pairing list
hermes pairing approve telegram ABC12DEF
hermes pairing revoke telegram 123456789

보안 리뷰 요청:

현재 작업을 실행하기 전에 위험한 명령, 민감 파일, 외부 API 호출 가능성을 분리해줘.
승인이 필요한 단계와 읽기 전용으로 가능한 단계를 나눠줘.

Hermes에 입력할 프롬프트

보안 리뷰어처럼 행동해줘.
이 작업에서 파일 삭제, 권한 변경, 토큰 노출, MCP env 전달,
메신저 사용자 권한 문제가 있는지 체크리스트로 검토해줘.
수정 명령은 아직 실행하지 마.

체크리스트

• 승인 모드가 smart(기본)인지, 의도적으로 manual/off인지 확인했다.
• 필요하면 approvals.deny로 YOLO 예외를 걸었다.
• MCP 서버에는 필요한 env만 전달한다.
• 메시징 게이트웨이에 allowlist 또는 pairing이 있다.
• 자동화/cron은 별도 승인 정책을 갖는다.
• 민감 운영은 Docker 등 격리 백엔드를 검토했다.
• 공개 대시보드 노출을 피한다.

다음 단계

• 메시징 게이트웨이에서 외부 플랫폼 연결 경계를 확인합니다.
• WhatsApp 연동에서 Baileys vs Cloud API 보안 차이를 봅니다.
• MCP와 도구에서 tool filtering을 적용합니다.