Security Blog

업계 전체가 방금 "에이전트가 키를 보면 안 된다"에 합의했습니다. 그런데 엉뚱한 곳에 숨기고 있어요.

#282

October 2, 2026 · By Marketing team

← All posts

일주일 사이에 Claude Code, Hermes, Codex가 모두 에이전트가 원시 자격 증명을 보지 못하게 하는 수정 사항을 내놓았어요. 수렴하는 패치는 아키텍처가 아닙니다. 키는 애초에 하니스 안에 있으면 안 돼요.

이번 주 Anthropic은 Claude Code 변경 로그에 조용한 한 줄을 넣었어요: "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" [1]. 쉽게 말하면 — Claude Code가 헤드리스 모드(CI와 자동화된 에이전트 파이프라인에서 도는 방식)로 실행될 때, 숨겨져 있어야 했던 인증 도구가 모델에 노출되고 있었던 거예요. AI가 인증 도구의 이름과 매개변수를 볼 수 있었고, 실제로 건드려 볼 수도 있었죠. 지구상에서 가장 많이 쓰이는 코딩 에이전트 — 별 133k — 에서 자격 증명 계층이 가장 보여서는 안 되는 곳, 바로 모델 자신의 컨텍스트로 새어 들어가고 있었던 겁니다.

수정은 됐어요. 하지만 수정 자체는 작은 이야기예요. 큰 이야기는 왜 모든 진지한 에이전트 하니스가 갑자기 같은 싸움을 하고 있는가입니다.

하니스 셋, 일주일, 같은 본능

24시간 안에 나온 것들을 보세요:

  • Claude Code는 위의 auth-stub 유출을 막고 MCP 인증 게이팅을 강화했어요 [1].
  • Hermes (v0.17.0)는 "Managed Scope"를 추가했어요 — 관리자가 고정하고 사용자가 변경할 수 없는 시크릿을 파일시스템 수준에서 잠가서 에이전트 운영자가 덮어쓸 수 없게 한 것 — 그리고 디버그 덤프에서 시크릿을 마스킹하고, 유출 형태의 MCP 설정이 시작되기 전에 차단합니다 [2].
  • Codex (v0.141.0)는 원격 실행 트래픽을 암호화된 Noise 채널로 감싸고, 플러그인을 인증 모드에 따라 라우팅하기 시작했어요 [3].

경쟁자 셋, 접근 방식 셋, 공통된 결론 하나: 하니스가 시크릿을 소유해야 하고, 에이전트는 원시 키를 절대 보면 안 된다. 경쟁자들이 같은 주에 이렇게 수렴한다면, 그건 유행이 아니에요. 그 카테고리가 자기가 무엇을 위한 것인지 마침내 인정한 겁니다.

다음 문제는 자격 증명의 확산입니다

함정이 있어요. 그 수정들 전부가 하니스 안에 삽니다. 그리고 Claude Code 버그가 그 증거예요. 인증이 하니스 안, 모델 바로 옆에 살면 "에이전트는 절대 보면 안 된다"는 사실이 아니라 계속 엔지니어링해야 하는 속성이 되고 — 헤드리스 모드처럼 아무도 지켜보지 않는 곳에서 가끔 실패합니다. 한 번 선언하면 끝이 아니에요. 릴리스마다 릴리스마다 지켜내야 합니다.

하지만 더 깊은 문제는 어떤 단일 유출이 아니라 — 모든 하니스, 모든 벤더, 모든 사용 사례가 각자만의 답을 내놓을 때 무슨 일이 생기는가입니다. Claude Code 안에 볼트 하나, Hermes 안에 볼트 하나, Codex 안에 볼트 하나, 여기에 OAuth 풀, 저기에 시크릿 파일 — 도구마다 별도의 자격 증명 저장소가 생깁니다. 그게 자격 증명의 확산이고, 해결된 문제가 아니라 다음 문제예요.

어떤 사일로도 새지 않아도 확산 자체가 실패입니다. 작동하게 하려면 시크릿이 각각에 복사돼야 해요 — 복사본이 늘고, 훔칠 곳이 늘어납니다. 회전은 N번 수동으로 해야 하고, 잊어버린 그 하나가 화를 내요. 그리고 실제로 중요한 유일한 질문 — 어느 에이전트가 어떤 키로, 무엇에, 언제 — 에 답할 수 있는 사람이 없어요. 답이 서로 대화하지 않는 열두 개 저장소에 흩어져 있으니까요. 벤더마다, 워크플로마다 새 볼트를 세울 수는 없어요. 확장되지 않아요. 그게 바로 깨지는 지점입니다.

키는 애초에 하니스에 속하지 않습니다

한 번도 내놓을 필요가 없는 수정은, 에이전트가 처음부터 인증을 쥐지 않게 하는 것입니다. 자격 증명을 모든 하니스 바깥에 있는 하나의 권한 기관에 두세요 — 벤더마다 볼트가 아니라, 그들 모두 아래에 있는 하나. 에이전트가 — Claude Code든, Codex든, Hermes든, 상관없어요 — 이름 붙은 동작 하나를 요청하면, 정확히 그 동작에만 한정되고 짧은 수명의 자격 증명이 실시간으로 주입되고 끝나면 사라집니다. 실수로 노출할 auth-stub이 모델 컨텍스트에 없어요. 인증이 애초에 하니스에 없었으니까요. 확산도 없어요. 도구마다 하나가 아니라 저장소가 하나니까 — N번이 아니라 한 번 회전하면 됩니다. 그리고 모든 접근이 서로 누가 무엇을 썼는지 답할 수 없는 열두 개 사일로에 흩어지는 대신 단일 감사 추적에 남습니다. (코드가 실행되는 곳에서 시크릿을 떨어뜨려 두는 것은 자격 증명 도구가 지켜야 할 규칙의 맨 위 근처에 있어요 — 업계가 방금 일주일 동안 그걸 발견한 겁니다.)

그리고 이 부분은 편의가 아니라 보안 경계입니다: 자격 증명은 에이전트와 같은 시스템에 있으면 안 됩니다. 같은 곳에 두면 파괴 반경을 공유해요 — 프롬프트 인젝션, 오염된 MCP 서버, 공유된 디버그 덤프, 다음 auth-stub 버그, 그리고 에이전트에게 닿는 것은 키에도 함께 닿습니다. 그래서 가시성만으로도 유출인 겁니다. 시크릿이 에이전트가 볼 수 있는 곳에 떨어지는 순간, 이미 새어 나갔다고 보고 회전해야 해요 — 신중한 팀들이 그 Claude Code auth-stub을 출시된 날 그렇게 다뤘던 것처럼요. 자격 증명을 팔 길이만큼 떨어뜨려 두세요. 에이전트가 요청만 할 수 있는 시스템에 — 읽을 수 없고, 쥘 수 없게. 완전히 장악당한 에이전트도 손에 닿지 않았던 것을 유출할 수 없습니다. 동작은 요청할 수 있어요. 키를 들고 나갈 수는 없어요. 그 거리가 곧 방어예요. 프로세스 안의 볼트는 어떤 대가를 치러도 그 거리를 갖지 못합니다.

그 선이 Clavitor가 긋는 선이에요. 방금 이 분야 전체가 그 원칙을 증명했어요 — 에이전트는 키를 보면 안 된다. 우리는 다만, 당신이 실행하는 모든 하니스 안에서 그걸 반복해서 증명해야 한다고 생각하지 않고, 키를 쥔 것이 방금 공격자가 장악한 바로 그 것이어서도 안 된다고 생각해요.

하니스 팀들에게 공을 돌립니다: 관리자 고정 시크릿, 암호화된 릴레이, fail-closed 기본값은 진짜 훌륭한 엔지니어링이에요. 하지만 계속 다시 나타나는 유출에 대한 그 주의 임시 처방은 아키텍처가 아니에요 — 증상입니다. 아키텍처는 새어 나갈 키가 애초에 거기 없는 것입니다.

경쟁자 셋이 같은 주에 같은 상처를 봉합한다면, 그 상처는 설계입니다. 에이전트는 키를 보면 안 돼요 — 그러니까 볼 수 있는 곳에 두지 마세요.

Clavitor (@clavitorai)는 AI 에이전트를 위해, 그리고 그들을 대항해 만들어진 자격 증명 볼트입니다. clavitor.ai

출처

[1] Claude Code v2.1.183 — "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" — https://github.com/anthropics/claude-code/releases/tag/v2.1.183

[2] Hermes Agent v0.17.0 — Managed Scope (관리자 고정 시크릿), 시크릿 마스킹, 유출 설정 차단 — https://github.com/NousResearch/hermes-agent/releases

[3] OpenAI Codex v0.141.0 — 암호화된 Noise 릴레이 채널, 인증 모드 플러그인 라우팅 — https://github.com/openai/codex/releases