자격 증명 프록시

에이전트가 API 호출을 할 때,
키를 직접 가지고 있어서는 안 돼요.

Clavitor Proxy는 AI 에이전트와 에이전트가 호출하는 API 사이에 위치해요. 자격 증명은 네트워크 계층에서 주입되므로 에이전트는 실제 시크릿을 보거나, 저장하거나, 로그에 남기지 않아요. 바이너리 하나, 환경 변수 하나, 코드 변경 제로.

이미 직면한 문제

환경 변수의 시크릿

에이전트는 환경에서 OPENAI_API_KEY를 읽어요. 해당 키는 /proc, 크래시 덤프, CI 로그, 에이전트가 호출하는 모든 도구에서 볼 수 있어요. 로그 한 줄만 유출되어도 키가 공개되는 거죠.

에이전트 메모리의 시크릿

에이전트가 런타임에 키를 가져오더라도 프로세스가 실행되는 동안 메모리에 키를 보유해요. 스킬이 손상되거나, 프롬프트 인젝션이 발생하거나, 디버그 덤프가 유출되면 키를 쉽게 탈취당할 수 있어요.

사용 내역에 대한 감사 부재

API 키가 문자열로 공유되면 어떤 에이전트가 언제, 어떤 목적으로 사용했는지 기록이 남지 않아요. 키가 유출되면 교체하고 무사히 넘어가기만 바랄 뿐이죠. 포렌식 추적 경로도 없어요.

겪지 않기를 바라는 문제

소스 코드의 API 키

구성 파일에 하드코딩되어 git에 커밋되고, 팀의 모든 개발자와 CI 러너가 클론해요. 공개 포크가 하나만 생겨도 GitHub의 시크릿 스캔 대시보드에 오르거나, 더 나쁘게는 아예 탐지되지 않을 수도 있어요.

Slack의 자격 증명

"Stripe 키 좀 보내줄래?" DM에 붙여넣으면 영원히 검색 가능하고 모든 규정 준수 아카이브로 내보내져요. Slack은 볼트가 아니에요. 이메일, Google Docs, 모니터에 붙은 포스트잇도 마찬가지죠.

모든 노트북의 .env 파일

개발자 12명이면 교체되지 않는 평문 파일에 프로덕션 자격 증명 사본이 12개 생기는 거예요. 노트북 한 대만 도난당하거나, ~/.bash_history가 유출되거나, 백업 도구가 과하게 작동하면 새벽 2시에 회사 전체 키를 교체해야 해요.

에이전트에서 자격 증명을 완전히 분리하세요.

프록시는 에이전트와 API 사이에 위치해요. 에이전트는 시크릿이 들어가야 할 자리에 clavitor://OpenAI/key 같은 참조를 작성해요. 프록시는 이를 로컬에서 확인하고 실제 자격 증명을 HTTPS 요청에 주입한 뒤 전달해요. 에이전트 로그에는 자리 표시자만 남고, API는 키를 수신해요. 그 사이 어디에도 저장되지 않아요.

환경 변수도 없고, 메모리에 시크릿도 없으며, 명령줄에 자격 증명도 없어요. 에이전트는 키를 알지 못하므로 키를 유출할 수도, 속아서 키를 노출할 수도 없어요.

$ export HTTPS_PROXY=http://127.0.0.1:1983

$ curl -H "Authorization: Bearer clavitor://OpenAI/key" \
    https://api.openai.com/v1/chat/completions

# The proxy resolved the placeholder. The agent never saw sk-proj-abc123.
# Neither did the logs, the crash dump, or the conversation history.

HTTPS 호출을 수행하는 모든 에이전트와 호환돼요: Claude Code, Codex, OpenClaw, CrewAI, LangChain, 커스텀 스크립트. 환경 변수 하나만 설정하면 에이전트의 API 호출이 프록시를 통해 흐릅니다. SDK도, 플러그인도, 코드 변경도 필요 없어요.

내부 작동 방식

요청별 로컬 복호화

프록시는 볼트에서 암호화된 자격 증명을 가져와 디바이스에서 복호화해요. 평문는 하나의 HTTP 요청 동안만 프로세스 메모리에 존재하다가 사라져요. 캐시되지 않고, 디스크에 기록되지도 않아요. 모든 요청은 새로 복호화돼요.

필드를 헤더에 매핑

Bearer 토큰, API 키, Basic 인증 등 프록시는 볼트 필드 레이블을 적절한 HTTP 헤더에 자동으로 매핑해요. 또는 에이전트가 clavitor:// 참조로 정확한 필드를 선택할 수도 있어요. 어느 쪽이든 에이전트가 보지 못한 채 자격 증명이 올바른 위치에 전달돼요.

범위, 속도 제한, 감사

볼트는 범위 경계와 속도 제한을 적용해요. 너무 많은 서로 다른 자격 증명에 접근하는 에이전트는 자동으로 잠겨요. 모든 접근은 로그에 기록돼요. 자리 표시자에 에이전트 ID를 포함하면(clavitor://agentid@Entry/field) 공유 프록시를 통해 에이전트별 감사 추적과 속도 제한을 적용할 수 있어요.

배포

바이너리 하나. 에이전트의 사이드카. 네트워크 인프라 변경 없음.

단일 에이전트 호스트

바이너리를 다운로드하고, 등록 토큰으로 clavitor-proxy init을 실행한 다음, 에이전트에 HTTPS_PROXY를 설정하면 끝나요. 기본적으로 프록시는 127.0.0.1:1983에 바인딩되며(단일 에이전트의 사이드카), 프라이빗 네트워크에서 하나의 프록시가 여러 에이전트를 서비스할 때는 CLAVITOR_PROXY_LISTEN을 설정해 다른 곳에 바인딩할 수 있어요.

다중 에이전트 호스트

각 에이전트는 고유한 사이드카 구성 파일과 함께 자체 바이너리 사본을 가져요. 각 사본에는 고유한 범위, 고유한 속도 제한, 고유한 감사 추적이 적용돼요. 에이전트 A는 에이전트 B의 자격 증명을 볼 수 없어요. 설계 단계부터 격리된 거죠.

클라우드 호스팅 프록시는 가치 높은 표적이에요.

클라우드에서 실행되는 모든 자격 증명 프록시(자사의 것이든 타사의 것이든)는 표적이에요. 프록시를 침해하면 모든 고객의 자격 증명을 손에 넣을 수 있죠. 이는 이론적인 위험이 아니에요. 모든 서비스형 자격 증명 프록시의 비즈니스 모델 그 자체예요.

Clavitor의 프록시는 사용자의 인프라에서 실행돼요. 로컬에서 복호화하죠. 자격 증명은 하나의 요청이 처리되는 동안만 프로세스 메모리에 존재해요. 평문 키를 보관하는 클라우드 서비스도, 시크릿을 제공하는 API 엔드포인트도 없어요. 침해할 대상 자체가 없어요.

에이전트는 이미 API 호출을 수행하고 있어요.
에이전트를 정해진 영역 안에 두세요.

사용자의 볼트, 사용자의 범위, 사용자의 감사 추적. 프록시는 에이전트 코드 변경 없이 네트워크 계층의 적용 지점을 추가해요.

시작하기 기술 심층 분석 →

에이전트가 API 호출을 할 때,키를 직접 가지고 있어서는 안 돼요.