자율적으로 움직이는 에이전트에게 외부 서비스의 API 키를 맡겨본 적이 있는가.

필자는 얼마 전, 바로 이 문제로 큰 낭패를 보았다. 스케줄 실행되는 Zenn 초안 생성 에이전트에게 Qiita 게시용 토큰을 맡기려다, 설정 파일에 생(raw) 값을 써버려 공개 리포지토리(Public Repository)에 노출될 뻔한 적이 있다. 수정은 했지만, "모델에게 키의 내용을 보여주는" 설계 자체가 위험하다는 교훈이 남았다.

Anthropic도 같은 과제에 직면했던 모양이다. 2026년 6월 9일, Claude Managed Agents에 「Vaults」의 환경 변수 대응과 cron 기반의 스케줄 실행 기능이 추가되었다. 에이전트에게 인증 정보를 맡기는 부분을 플랫폼 측의 기능으로 분리해낸 형태다.

• Vaults는 API 키를 환경 변수 이름과 허가 도메인의 조합으로 등록하는 메커니즘. 2026년 6월 9일에 퍼블릭 베타(Public Beta) 진입
• 에이전트의 샌드박스(Sandbox)에는 플레이스홀더(Placeholder)만 전달된다. 실제 키는 허가된 도메인으로 요청이 나가는 순간 **네트워크 경계에서 주입(Injection)**된다. 모델 자체는 단 한 번도 진짜 키를 보지 않는다. 프롬프트 인젝션(Prompt Injection)으로 키 자체를 탈취당할 리스크를 구조적으로 줄이는 설계
• 동시에 **스케줄 실행(cron)**도 추가되어, 에이전트를 직접 스케줄러로 구축하지 않고도 정기적으로 기동할 수 있다.
• Notion, Browserbase, Sentry 등 HTTP 헤더로 키를 보내는 CLI라면 대체로 대응 가능

본 기사는 Anthropic 공식 블로그와 문서, 그리고 관련 미디어의 기사를 바탕으로 한 해설입니다. 기능은 아직 퍼블릭 베타 상태이며, 대응 범위나 동작은 향후 변경될 가능성이 있습니다.

일반적인 방식이라면 에이전트에게 외부 API를 호출하게 하기 위해 환경 변수나 프롬프트 어딘가에 키를 심어두어야 한다. 이 경우, 모델의 컨텍스트(Context)에 키 문자열 자체가 올라간다. 로그에 남거나, 프롬프트 인젝션으로 탈취되거나, 실수로 커밋하는 등 유출 경로는 여러 가지가 있다.

Vaults의 접근 방식은 다르다.

1. 사용자가 API 키를 등록한다
→ 환경 변수 이름(예: SENTRY_API_KEY) + 액세스 허가 도메인(예: sentry.io)
2. 에이전트의 샌드박스에는 「플레이스홀더」만 전달된다
...

즉, 키의 실체는 모델의 컨텍스트에도, 샌드박스의 메모리에도 올라가지 않는다. 올라가는 것은 요청이 실제로 전송되는 순간, 그리고 허가된 도메인으로 보낼 때뿐이다. 도메인을 제한하고 있기 때문에, 설령 에이전트가 속아서 의도하지 않은 요청을 구성하더라도 키가 유출되는 곳은 등록된 도메인으로 한정된다.

대응하고 있는 것은 "키를 HTTP 요청의 헤더나 쿼리로 보내는" 타입의 CLI이며, Browserbase, KERNEL, Notion, Ramp, Sentry 등이 언급되고 있다.

동시에 발표된 것이 Managed Agents의 cron 스케줄 기능이다. 에이전트에게 정기 실행 스케줄을 설정하면, 발화될 때마다 새로운 세션이 생성되어 태스크를 수행한다. 직접 스케줄러를 구축하거나 호스팅할 필요가 없다.

필자는 이 기사들을 쓰기 위해 launchd로 직접 일일 에이전트를 구축했다. zshrc에서 토큰을 읽게 하기 위한 zsh -i 래핑이나, 실행 로그의 로테이션, 실패 시의 알림 등 사소한 배선 작업이 은근히 번거로웠다. Managed Agents의 Vaults + Cron은 그 배선 부분을 플랫폼의 기능으로서 대신 처리해준다는 제안으로 보인다.

공식 블로그가 제시하는 예시는 구체적이다.

• Notion: CLI를 MCP 도구와 병행하여 전개하며, API 토큰을 모델에 전혀 전달하지 않은 채 파일 업로드 기능을 에이전트에게 부여하고 있다.
• Milana: AI "프로덕트 엔지니어"를 고객의 코드베이스에 안전하게 연결할 때 Vaults의 환경 변수를 사용하고 있다.

둘 다 "에이전트에게 강력한 권한을 부여하고 싶지만, 키 자체는 넘겨주고 싶지 않다"는 동일한 긴장 관계에 대한 해답이다.

성실하게 살펴봐야 할 논점도 있다.

• 대응 CLI가 제한적임: 키를 HTTP 요청으로 전송하는 설계의 도구가 아니면 작동하지 않는다. 독자적인 인증 플로우 (Authentication Flow)를 가진 도구는 대상에서 제외된다.
• 도메인 허용 목록 (Allowlist) 운영: 허용 도메인 설정을 잘못하면 의도하지 않은 목적지로 요청이 전송될 여지가 남아 있다. 경계의 신뢰성은 Anthropic의 샌드박스 (Sandbox) 구현에 의존한다.
• 아직 퍼블릭 베타 단계: 사양 및 대응 범위는 변경될 수 있다. 프로덕션의 크리티컬 패스 (Critical Path)에 즉시 적용하는 판단은 신중해야 한다.

"모델이 키를 보지 않는다"는 것이 "샌드박스에서 아무것도 유출되지 않는다"는 것을 보장하지는 않는다. 허용 도메인 설정은 최소한으로 유지하고, Managed Agents에 부여하는 권한 자체도 필요 최소한으로 제한해야 합니다.

관점	기존 방식 (환경 변수를 직접 전달)	Vaults
모델이 키를 보는가	보인다	보이지 않는다 (플레이스홀더 (Placeholder)만 존재)
...

에이전트에게 무엇을 갖게 하고, 무엇을 갖게 하지 않을 것인가——이 설계 판단은 향후 에이전트 운영에서 가장 눈에 띄지 않으면서도 가장 중요한 부분이 될 것이다. Vaults는 "키를 전달하지 않고 사용하게 한다"는 발상을 플랫폼의 표준 기능으로 끌어올린 하나의 사례로 보아야 한다.

이 기사가 도움이 되었다면, 좋아요와 저장을 부탁드립니다!

여러분의 에이전트는 API 키를 어떻게 다루고 있나요? 여러분만의 워크어라운드 (Workaround)가 있다면 댓글로 알려주세요.

New in Claude Managed Agents: run agents on a schedule and store environment variables in vaults - Anthropic

Authenticate with vaults - Claude Platform Docs

Claude Managed Agents Add Cron Schedules and Credential Vaults - Tech Times