OneCLI – AI Agent를 위한 Credential Vault (Rust 구현)

Who Should Read

AI 에이전트가 여러 외부 API를 호출하는 시스템을 개발 중인 백엔드/인프라 개발자. 특히 에이전트별로 API 키를 관리하다가 키 유출이나 권한 관리에 어려움을 겪고 있는 팀.

Core Mechanics

• OneCLI는 Rust로 만든 오픈소스 HTTP 게이트웨이로, AI 에이전트와 외부 서비스 사이에 위치한다. 에이전트에게는 'FAKE_KEY' 같은 플레이스홀더 키를 주고, 실제 요청이 게이트웨이를 통과할 때 진짜 API 키로 교체(swap)해서 외부로 내보낸다.
• 에이전트는 Proxy-Authorization 헤더에 액세스 토큰을 담아 게이트웨이에 인증하고, 게이트웨이는 AES-256-GCM으로 암호화된 시크릿 저장소에서 해당 자격증명을 꺼내 주입한다. 실제 API 키는 에이전트 코드나 로그 어디에도 노출되지 않는 구조다.
• 시스템은 세 컴포넌트로 구성된다. Rust로 만든 고성능 HTTP 게이트웨이, 에이전트·시크릿·권한을 관리하는 Next.js 웹 대시보드, 그리고 AES-256-GCM으로 암호화된 시크릿 저장소다.
• 설계 목적은 에이전트 수십 개가 각각 다른 API를 호출하는 환경에서, 키를 에이전트별로 하드코딩하지 않고 한 곳에서 관리·교체·감사할 수 있게 하는 것이다. 키 로테이션이나 액세스 로그 추적도 게이트웨이 레벨에서 일괄 처리된다.
• 현재 GitHub 스타 600개 이상을 받았으며, Apache-2.0 라이선스로 공개되어 있다. 리포지토리에는 Claude, GitHub Actions 등과의 통합을 위한 스킬 파일도 포함되어 있다.
• 가짜 키를 사용하는 방식이기 때문에, 기업 내 보안 스캐닝 도구(시크릿 스캐너 등)가 이 가짜 키를 실제 키로 오인해 오탐(false positive)을 발생시킬 수 있다는 실용적인 단점도 지적됐다.

Evidence

• 가장 많이 제기된 근본적 비판은 '가짜 키를 줘도 에이전트가 할 수 있는 일은 달라지지 않는다'는 것이다. 에이전트가 프록시 인증 토큰을 읽을 수 있다면 그 토큰 자체를 탈취당할 수 있고, 설령 키를 못 꺼내더라도 프록시를 통해 API를 자유롭게 호출할 수 있으므로 데이터 삭제·비용 유발·데이터 exfiltration은 여전히 가능하다는 주장이 여럿 나왔다.
• 보안을 제대로 하려면 에이전트 프로세스와 게이트웨이 사이를 mTLS로 연결하고, 에이전트가 접근할 수 없는 사이드카(sidecar) 컨테이너가 TLS 키를 관리해야 한다는 아키텍처 제안이 있었다. airutorg/airut를 직접 구현한 개발자가 실제 경험을 공유했는데, Node.js가 HTTP_PROXY 환경변수를 잘 따르지 않는 점, AWS SigV4 서명을 재구현해야 하는 복잡성, 에이전트가 프록시 프로세스 메모리를 읽을 수 없도록 별도 컨테이너에서 실행해야 하는 점을 배운 점으로 꼽았다.
• 이 문제는 에이전트 전용이 아니라 오래된 auth-proxy 패턴이라는 의견도 있었다. fly.io 팀의 tokenizer(상태 없이 동작하는 DB·대시보드 불필요 솔루션)나 Buzzfeed의 SSO 프록시가 이미 같은 문제를 해결하고 있으며, Hashicorp Vault나 AWS Secrets Manager로도 동일하게 구현 가능하다는 대안이 제시됐다. 실제로 Hashicorp Vault + OpenClaw 조합으로 시간 제한 만료 크리덴셜을 에이전트 스킬 스크립트 안에서 동적으로 가져오는 구성을 사용 중이라는 경험담도 나왔다.
• 실제 에이전트 파이프라인을 운영 중인 팀에서는 '태스크 단위로 단기 파생 토큰(short-lived derived token)을 발급하고, 태스크 완료 시 즉시 폐기하는 계층형 시크릿 모델'을 사용한다고 공유했다. 스케줄 기반이 아닌 태스크 완료 기반 폐기 방식 덕분에 일반 API 키 방식이었으면 발견하지 못했을 오남용 사례 2건을 잡아냈다고 한다.
• TLS 암호화 트래픽을 프록시가 어떻게 수정하는지에 대한 기술적 질문도 있었다. 이에 대해 airutorg 개발자는 MITM 방식의 투명 프록시를 별도 컨테이너에서 운영하고, 에이전트 컨테이너의 인증서 저장소에 프록시 인증서를 주입하는 방식으로 해결했다고 설명했다.

How to Apply

• 에이전트가 OpenAI, Stripe 등 여러 외부 API를 호출하는 구조에서 키 로테이션을 자동화하고 싶다면, OneCLI 게이트웨이를 별도 Docker 컨테이너로 띄우고 에이전트에는 FAKE_KEY만 환경변수로 전달하도록 구성하면 된다. 키 변경 시 에이전트 배포 없이 대시보드에서만 교체할 수 있다.
• 다만 보안 요구 수준이 높다면 에이전트 컨테이너와 게이트웨이 컨테이너를 반드시 분리하고, 에이전트가 게이트웨이 프로세스 메모리에 접근할 수 없도록 네트워크 정책으로 격리해야 한다. 그렇지 않으면 프록시 인증 토큰 자체가 탈취될 수 있다.
• Hashicorp Vault나 AWS Secrets Manager를 이미 사용 중이라면 OneCLI 대신 기존 인프라를 확장하는 것이 더 나을 수 있다. AWS STS 기반의 시간 제한 임시 크리덴셜을 에이전트 스킬 호출 시점에 동적으로 발급하는 방식이 보안 측면에서 더 강력하다.
• Node.js 기반 에이전트를 사용 중이라면, Node.js는 HTTP_PROXY 환경변수를 기본적으로 따르지 않으므로 글로벌 fetch/http 모듈을 프록시 설정으로 패치하는 추가 작업이 필요하다는 점을 사전에 고려해야 한다.

Code Example

# vault_get.sh (Hashicorp Vault에서 시크릿 가져오기 - 댓글에서 언급된 대안)
# 에이전트 스킬 스크립트 내부에서 호출해 LLM 컨텍스트에 키가 노출되지 않게 함
# https://gist.github.com/sathish316/1ca3fe1b124577d1354ee254a...

# OneCLI 사용 시 .env.example 구성 예시
# 에이전트에는 FAKE_KEY만 전달, 실제 키는 OneCLI 대시보드에 저장
OPENAI_API_KEY=FAKE_KEY
STRIPE_SECRET_KEY=FAKE_KEY

# 에이전트 HTTP 호출 시 Proxy-Authorization 헤더 포함
# curl -x http://onecli-gateway:8080 \
#   -H 'Proxy-Authorization: Bearer <access-token>' \
#   -H 'Authorization: Bearer FAKE_KEY' \
#   https://api.openai.com/v1/chat/completions
# 게이트웨이가 FAKE_KEY를 실제 키로 교체 후 외부로 전달

Terminology

Related Resources

• https://github.com/onecli/onecli
• https://github.com/superfly/tokenizer
• https://github.com/buzzfeed/sso/blob/549155a64d6c5f8916ed909...
• https://github.com/airutorg/airut
• https://gist.github.com/sathish316/1ca3fe1b124577d1354ee254a
• https://timebound-iam.com