Cloak 데몬이 HTTPS를 맡고 원시 볼트 값은 나가지 않는다

Cloak 데몬이 실제로 하는 일 — 그리고 vault 안에 들어 있는 것

Cloak은 MCP 기반 AI 에이전트를 위한 오픈소스 로컬 우선 secrets 레이어다. 핵심 동작은 에이전트가 저장된 credential을 사용할 수는 있지만, 모델은 그 raw 값을 절대 받지 않는다는 점이다. Cloak v1.1.2 에서는 모델이 STRIPE_SECRET_KEY를 한 번도 보지 않은 채 에이전트가 Stripe API를 호출할 수 있다. 백그라운드 데몬이 outbound request에 credential을 붙이고, key가 아니라 upstream HTTP response만 반환한다. 이 분리가 제품의 전부다.

작업은 두 개의 로컬 컴포넌트로 나뉜다. cloakd — 데몬 — 은 encrypted vault, policy enforcement, outbound HTTPS 호출, audit log를 소유한다. cloak-mcp — MCP bridge — 는 호출 프로세스(Claude Desktop, Cursor, Codex 등)에 metadata와 proxy call만 노출한다. 모델은 "STRIPE_SECRET_KEY로 인증해서 이 요청을 proxy해 달라"고 요청할 수 있지만, secret 자체는 cloakd 안에 남아 있다.

이 프로젝트는 Apache-2.0 라이선스의 cloakward/cloak으로 배포되며, v1.1.2는 2026년 6월 18일에 릴리스됐다. 리뷰 시점 기준 repo에는 star 15개와 commit 148개가 표시됐다 . 로컬 전용이라 account, cloud sync, telemetry가 없다 .

이 시점은 우연이 아니다. 공식 MCP 2025-06-18 spec은 protocol 자체가 authorization을 강제할 수 없으며, implementor가 code 안에서 access control을 만들어야 한다고 경고한다 . Cloak은 그 공백을 메우는 separation-of-authority pattern의 구체적인 구현 중 하나다.

cloakd는 별도 binary다 — 그리고 Cloak의 threat boundary가 여기에 달린 이유

Cloak의 threat boundary는 process separation으로 강제된다. 서로 다른 세 binary가 작업을 나누기 때문에 model-facing component는 vault에 절대 닿지 않는다. 흐름은 cloak(CLI/admin tool), cloak-mcp(모델이 대화하는 MCP bridge), cloakd(encrypted vault, policy check, audit log, outbound HTTPS를 단독으로 소유하는 daemon)로 이어진다 . cloak-mcp는 local IPC(Unix domain socket)를 통해서만 cloakd에 접근하므로, bridge가 compromise되더라도 secret을 직접 읽을 수는 없다. 할 수 있는 일은 daemon에게 행동을 요청하는 것뿐이다 .

이 boundary가 유지되려면 daemon이 자신과 대화하는 상대를 신뢰할 수 있어야 한다. 그래서 cloakd는 session token을 발급하기 전에 호출 peer를 인증한다. 설치된 cloak과 cloak-mcp binary를 hash로 pin하며, 둘 중 하나라도 바뀌면 조용히 허용하지 않고 fail-closed로 동작한다 . Peer authentication은 OS별로 다르다. macOS에서는 audit token과 CodeDirectory hash를 사용하고, Linux에서는 kernel 6.5 이상에서 제공되는 SO_PEERPIDFD가 필요하다. 더 오래된 kernel에서는 fail closed된다 .

peer가 검증되면 daemon은 32 random byte를 base64url로 encoding한 session token을 발급하며, 기본 TTL은 30분이다 . Policy는 vault read 전에 평가되고, 거부된 call은 저장된 값을 decrypt하지 않은 채 audit log에 기록된다. 거부된 request에서는 secret이 sealed state를 벗어나지 않는다 .

이 설계의 선택은 권한을 하나의 audit 가능한 process에 두는 것이다. Prompt injection을 당한 agent도 cloakd에 허용된 action을 수행해 달라고 요청할 수는 있다. 하지만 cloakd를 우회해 raw value를 읽을 수는 없고, 이 daemon과 대화하는 binary가 tamper되면 fail-closed 경로가 작동한다 .

Cloak에 get_secret이 없는 이유와 호출형 함수들이 대신 하는 일

Cloak은 get_secret, read_secret, vault.show를 노출하지 않습니다. 모델이 비밀값을 다루기 위해 원문 값을 볼 필요가 없기 때문입니다. 문서화된 v1.x MCP 표면은 정확히 여섯 개의 호출 가능한 도구로 구성되며, 각각은 메타데이터, 계산된 헤더, 업스트림 응답, 파생 자격 증명, 감사 항목을 반환할 뿐 저장된 비밀값 자체는 절대 반환하지 않습니다 . 에이전트는 cloakd에 자격 증명으로 무언가를 해 달라고 요청하지, 자격 증명을 보여 달라고 요청하지 않습니다.

핵심 작업을 맡는 것은 프록시입니다. proxy_authenticated_http_request는 bearer, basic, custom-header 인증 모드를 지원하지만, URL은 서버 로그에 흔히 남기 때문에 query-string 인증은 명시적으로 비활성화되어 있습니다 . mint_short_lived_token은 의도적으로 둔 예외입니다. 파생 값을 MCP 클라이언트에 돌려줄 수 있습니다. AWS STS는 구현되어 있으며, GitHub App과 GitLab PAT 스키마는 존재하지만 v1.x 표면에서는 not-supported 오류를 반환합니다 .

"Extensible functionality should be handled in code, not exposed to the model" — Cloak은 무언가를 드러내는 도구가 아니라 실행하는 도구에 권한을 남겨 이 원칙을 운영 방식으로 구현합니다 (source: Cloak MCP tools spec).

기능을 갖췄다고 곧 권한이 생기는 것은 아닙니다. 저장된 모든 값은 처음에는 거부 상태이며, cloak allow <name> <host>로 이름별, 호스트별 접근을 허용하고 cloak deny로 철회합니다 . 따라서 에이전트가 여섯 도구를 모두 가지고 있어도, 특정 호스트에 키 범위를 지정하기 전까지는 아무것에도 접근할 수 없습니다. v1.1.0(2026년 6월 11일)은 정책 핫 리로드와 잘못된 정책 파일에 대한 fail-closed 처리를 추가했습니다. 깨진 규칙은 접근을 조용히 열어 주는 대신 거부합니다 .

볼트 암호화: XChaCha20-Poly1305, Argon2id, BIP-39 복구 시드

볼트는 SQLite WAL 데이터베이스이며, 각 레코드는 XChaCha20-Poly1305-IETF를 사용하는 AEAD로 봉인되고, 레코드별 하위 키는 Argon2id와 libsodium을 통해 파생됩니다 . 실질적인 의미는 이렇습니다. 디스크에 있는 파일만으로는 오프라인 공격을 걸기에 충분하지 않습니다. 키체인 기반 pepper가 데이터베이스 밖에 있기 때문에, 도난당한 SQLite 파일은 OS 키체인 항목까지 함께 추출하지 않는 한 사전 공격을 할 수 없습니다. 하나가 아니라 서로 다른 두 가지 침해가 필요합니다 .

복구는 일부러 가혹하게 설계되어 있습니다. 볼트를 만들 때 Cloak은 24단어 BIP-39 시드를 정확히 한 번만 보여 주며, 별도의 2차 복구 경로는 없습니다. 시드를 잃으면 암호화된 레코드는 복구할 수 없습니다 . 이는 실수가 아니라 설계 선택입니다. 백도어식 복구 메커니즘은 같은 비밀값을 겨냥한 두 번째 공격 표면이 되기 때문입니다.

아웃바운드 HTTP는 reqwest/rustls를 통해 데몬이 전적으로 소유합니다. 리디렉션은 비활성화되어 있고, 총 30초 타임아웃이 적용되며, SSRF 안전장치는 루프백, 사설, 링크-로컬, 클라우드 메타데이터 서비스, ULA 목적지를 거부합니다. 이는 원래 허용 목록에 있는 호스트명에 대해 DNS 리바인딩이 일어난 경우에도 마찬가지입니다 . 따라서 오염된 DNS 응답이 인증된 요청을 `169.254.169.254`로 돌려 클라우드 자격 증명을 빼내는 일은 할 수 없습니다.

감사 항목은 해시 체인으로 연결된 JSONL이며, `cloak audit verify`는 변경, 삭제, 재정렬된 줄을 감지합니다 . 이를 통해 어떤 비밀값이 어떤 호스트에 도달했는지에 대한 기록에 변조 증거성을 부여합니다.

"There has been no third-party security audit." — Cloak 프로젝트, THREAT_MODEL.md (source: cloakward/cloak)

암호화 스택은 신뢰할 만하고 구체적이지만, 가장 강한 보장은 여전히 외부 검토가 아니라 프로젝트 자체 저장소와 테스트에 머물러 있습니다 .

macOS와 Linux만 지원 — v1.1.2에는 Windows 데몬 설치 프로그램이 없습니다

Cloak은 플랫폼별 바이너리 세트로 배포되며, v1.1.2 기준 macOS와 Linux에서만 실행됩니다. Windows 데몬 설치 프로그램은 없습니다 . 릴리스 매트릭스는 macOS arm64, macOS x86_64, Linux glibc x86_64, Linux musl x86_64, Linux glibc arm64 등 다섯 가지 빌드 행을 포함합니다 . 위협 경계는 데몬이 HTTPS를 소유한다는 전제에 달려 있으므로, cloakd가 실제로 시작될 수 있는 환경은 그 뒤의 암호화만큼 중요합니다.

서명과 출처 증명은 이 빌드 행들 전체에서 균일하지 않습니다. 모든 릴리스에는 cosign 키리스 서명과 SLSA L3 출처 증명이 포함되며, macOS 안정 빌드는 추가로 Developer ID 서명과 공증을 거칩니다 . 두 비주류 Linux 티어도 더 얇습니다. Linux musl x86_64와 Linux glibc arm64는 CLI와 데몬 바이너리만 제공하며, MCP 브리지 바이너리는 해당 티어에 포함되지 않습니다. 따라서 에이전트가 사용하는 경로가 그 환경에서는 바로 쓸 수 있는 형태가 아닙니다 .

Windows에서는 cloakd가 시작을 거부하며, 이는 이슈 #2로 추적되고 있고 설치 아티팩트도 게시되지 않았습니다 . npm 배포 역시 플랫폼별 감사된 네이티브 바이너리가 준비될 때까지 중단되어 있어, 아직 npx 단축 경로도 없습니다 . 실행 가능한 환경에서는 cloak setup이 Claude Desktop, Claude Code, Cursor, Windsurf, Continue.dev, Zed, Codex를 자동 감지하고 MCP 설정까지 연결해 줍니다 .

인젝션은 여전히 남습니다 — Cloak 보호의 실제 빈틈

Cloak은 모델 컨텍스트에서 저장된 원시 값을 제거하지만, 탈취된 호출 프로세스를 무해하게 만들지는 않습니다. 권한 분리 설계는 장기 키가 모델과 제공자 로그에 들어가지 않게 막습니다. 하지만 이미 유효한 세션을 가진 프롬프트 인젝션 에이전트를 무력화하지는 못합니다. 그런 에이전트는 허용된 모든 프록시 함수를 여전히 호출할 수 있고, proxy_authenticated_http_request 호출로 실제 비용을 발생시킬 수 있으며, 자신에게 허용된 인증 요청을 통해 원격 상태를 변경할 수도 있습니다 . 볼트는 봉인된 채로 남지만, 허용된 행동의 피해 범위가 줄어드는 것은 아닙니다.

설계상 MCP 클라이언트에 보이는 표면은 두 가지입니다. mint_short_lived_token은 호출자에게 파생 자격 증명을 반환합니다. AWS STS 경로에서는 발급된 STS 자격 증명이 응답에 직접 노출됩니다. 또한 프록시된 HTTP 응답은 업스트림 페이로드를 반환하며, 그 안에도 민감한 데이터가 들어 있을 수 있습니다 . 이는 누수가 아니라 의도된 탈출구에 가깝지만, 에이전트를 장악한 공격자는 이 도구들이 정당하게 반환하는 내용을 읽을 수 있다는 뜻입니다.

위협 모델은 경계 밖에 무엇이 있는지도 명확히 밝힙니다. 루트 또는 커널 침해, 프로세스 메모리나 키체인 항목을 읽는 악성 동일 사용자 앱, 사용자가 붙여 넣은 비밀값, 사이드 채널, 그리고 멀티테넌트 또는 네트워크에 노출된 모든 데몬 구성은 보호 범위 밖입니다 .

"제3자 보안 감사는 아직 없었습니다." — Cloak 위협 모델 (source: THREAT_MODEL.md)

2026년 6월 18일자로 나온 v1.1.2 기준, 이런 솔직함은 중요합니다 . 가장 강한 주장들, 즉 AEAD 봉인 정확성, 피어 고정, SSRF 차단 장치는 프로젝트 자체 저장소와 테스트에 들어 있습니다. 릴리스 프로세스에 문서화된 cosign 키리스 서명과 SLSA L3 출처 증명은 공급망 무결성을 다루며, 설치하는 바이너리가 소스와 일치함을 증명합니다 . 하지만 볼트 구현 자체가 올바른지에 대해서는 말해 주지 않습니다. 실무적인 보안 태세는 Cloak의 자체 불변 조건에서 이어집니다. 엄격한 호스트 허용 목록을 강제하고, 수명이 짧고 범위가 제한된 자격 증명을 우선 사용하며, 해시 체인 감사 로그를 감시하고, 고위험 작업에는 수동 검토를 요구해야 합니다.

Infisical, Runloop, Aegis: 이 분야의 또 다른 데몬 프록시 구현들

Cloak만 에이전트 컨텍스트에서 원본 시크릿을 제거하는 것은 아니다. 같은 권한 분리 패턴이 여러 독립 도구에서 나타나고 있으며, 각 도구는 서로 다른 배포 모델을 택한다. 공통된 아이디어는 일관된다. 브로커 프로세스가 실제 자격 증명을 소유하고 네트워크 경계에서 이를 붙이기 때문에, 모델은 자리표시자나 업스트림 응답만 보게 된다. 이 도구들이 갈리는 지점은 호스팅 방식(로컬 우선 vs. 클라우드), 라이선스(오픈소스 vs. 상용), 그리고 볼트 암호화 계층을 함께 제공하는지 여부다.

Infisical의 Agent Vault는 아웃바운드 호출에서 더미 토큰을 실제 자격 증명으로 바꿔 주는 자격 증명 브로커 프록시다 . 이 방식은 Cloak의 proxy_authenticated_http_request와 닮았지만, 배포는 로컬 우선이 아니라 호스팅형이다. 그래서 노트북 중심의 위협 모델 대신 중앙 관리의 이점을 택한다. Runloop의 Agent Gateway도 상용 호스팅 서비스로서 비슷한 런타임 주입 접근법을 취하며, 자격 증명을 에이전트에 노출하지 않고 네트워크 경계에서 주입한다 .

Aegis는 가장 가까운 유사 사례다. 인증 헤더를 네트워크 경계에서 주입하는 오픈소스 MCP 자격 증명 격리 프록시로, 범위는 Cloak과 비슷하다. 다만 레코드별 볼트 암호화는 없다. 즉 XChaCha20-Poly1305, Argon2id, BIP-39 복구 시드를 제공하지 않는다. 바로 이 지점이 Cloak을 구분한다 . Cloak은 프록시 패턴을 봉인된 로컬 볼트와 결합하지만, 다른 도구들은 대체로 경계 처리에서 멈춘다.

이러한 수렴은 제품을 넘어선다. 2026년 3월 arXiv의 한 헬스케어 논문도 컨테이너화된 에이전트 워크로드가 원본 시크릿을 읽지 못하게 하는 자격 증명 프록시 사이드카를 독립적으로 설명했다 . 학계와 상용 영역이 서로 조율하지 않았는데도 같은 통제 방식에 도달한 것이다. 도구를 고르는 사람에게 중요한 결론은 이렇다. 호스팅형인지 로컬 우선인지, 볼트급 암호화가 필요한지를 먼저 정하고, 어떤 프록시를 선택하든 엄격한 호스트 허용 목록과 단기 자격 증명을 강제해야 한다. 패턴은 자리를 잡고 있지만, 구현들은 아직 서로 바꿔 쓸 수 있는 수준이 아니다.

자주 묻는 질문

Cloak은 손상된 MCP 에이전트가 돈을 쓰거나 외부 API를 호출하는 것을 막을 수 있나?

아니다. Cloak은 저장된 원본 값을 모델 컨텍스트 밖에 두지만, 탈취된 호출 프로세스를 무력화하지는 않는다. 프롬프트 인젝션을 당한 에이전트는 여전히 허용된 함수를 호출할 수 있다. 여기에는 proxy_authenticated_http_request와 mint_short_lived_token도 포함된다. 그 결과 아웃바운드 HTTP 호출을 만들고, 돈을 쓰고, 원격 시스템을 변경하거나, 민감한 업스트림 응답을 읽을 수 있다 . Cloak이 제공하는 보호는 좁고 구체적이다. 자격 증명 유출 위험을 줄이는 것이지, 실행 위험을 없애는 것이 아니다. 그래서 이 프로젝트는 프록시에 더해 엄격한 호스트 허용 목록, 범위가 제한된 단기 자격 증명, 감사 로그 모니터링, 고위험 작업에 대한 수동 검토를 권장한다.

Cloak의 MCP 표면에 read_secret이나 get_secret 함수가 있나?

없다. 의도된 설계다. Cloak은 모델이 호출할 수 있는 함수를 정확히 여섯 개만 노출한다. list_secret_names, get_secret_metadata, sign_request, proxy_authenticated_http_request, mint_short_lived_token, query_audit이며, 이 중 어떤 것도 저장된 원본 값을 반환하지 않는다. 대신 메타데이터, 계산된 헤더, 프록시된 HTTP 응답, 파생 자격 증명, 감사 항목을 반환한다. 표면 어디에도 read_secret, get_secret, vault.show 도구는 없으며, 시크릿은 기본적으로 거부된다. mint_short_lived_token은 의도적인 예외다. 파생 자격 증명을 돌려줄 수는 있지만(AWS STS는 구현됨. GitHub App과 GitLab PAT 스키마는 존재하지만 not-supported를 반환), 장기 저장 키 자체를 반환하지는 않는다 .

Cloak은 저장된 볼트 항목을 보호하기 위해 어떤 암호화를 쓰나?

Cloak은 각 볼트 레코드를 XChaCha20-Poly1305-IETF AEAD로 봉인한다. libsodium 위에서 Argon2id KDF를 통해 파생한 레코드별 서브키와 키체인 기반 pepper를 함께 사용한다 . 볼트 자체는 SQLite WAL 데이터베이스다. 복구 수단은 볼트 생성 시 한 번만 표시되는 단일 BIP-39 24단어 시드뿐이다. 보조 복구 경로가 없으므로 그 시드를 잃으면 볼트도 잃는다 . 인증된 피어에 발급되는 세션 토큰은 32바이트 난수이며 base64url로 인코딩되고, 기본 TTL은 30분이다. 감사 항목은 해시 체인으로 연결된 JSONL이며, cloak audit verify가 변경, 삭제, 재정렬 여부를 검사할 수 있다.

Cloak은 Windows에서 작동하나?

v1.1.2에서는 아니다. cloakd 데몬은 Windows에서 시작을 거부하며, 해당 플랫폼용 설치 아티팩트도 제공되지 않는다 . 현재 지원 대상은 문서화된 다섯 개 빌드 행에 걸친 macOS(arm64 및 x64)와 Linux(glibc x64, musl x64, glibc arm64)다 . Linux musl과 Linux arm64는 현재 CLI/데몬 전용 아티팩트만 제공하며, macOS arm64/x64와 Linux glibc x64가 주요 퀵스타트 경로를 담당한다. Windows 개발자에게는 현재 1차 제공 옵션이 없고, 이 제한은 공개 이슈로 추적되고 있다.

Cloak은 정확성에 대해 독립 감사를 받았나?

아직 아니다. 2026년 6월 18일에 릴리스된 v1.1.2 기준으로 , 이 프로젝트의 위협 모델 문서는 제3자 보안 감사가 완료되지 않았다고 명시한다 . 가장 강한 정확성 주장은 여전히 Cloak 자체 저장소, 테스트, 릴리스 프로세스 안에 있다. 공급망 통제는 더 강하다. 빌드는 cosign 키리스 서명과 SLSA L3 출처 증명으로 문서화되어 있고, macOS 안정 빌드는 Developer ID 서명 및 공증을 받는다 . 하지만 출처 증명과 서명은 다운로드한 것의 무결성을 보호할 뿐이다. 볼트 구현 자체가 건전한지에 대해서는 아무 말도 해 주지 않는다.