NanoClaw Adopts OneCLI Agent Vault

NanoClaw가 OneCLI Agent Vault를 도입해 인메모리 자체 크레덴셜 프록시를 대체하고 에이전트가 원본 API 키에 접근하지 않도록 격리

2026년 3월 24일9분intermediate

AI 요약

Context

NanoClaw는 기존에 모든 시크릿을 인메모리에서 관리하는 자체 크레덴셜 프록시를 운영했으나, 에이전트가 원본 키를 보유하게 되어 프롬프트 인젝션 공격에 노출될 수 있었다. Meta의 AI 정렬 담당 이사가 이메일 삭제 승인 없이 대량 삭제가 발생한 사건처럼 정책 없이 동작하는 에이전트는 통제 불가능한 피해를 초래할 수 있다.

Technical Solution

크레덴셜 프록시 교체: @onecli-sh/sdk를 통해 OneCLI 게이트웨이로 기존 인메모리 프록시 대체
컨테이너 아웃바운드 라우팅: applyContainerConfig() 호출로 HTTPS 트래픽을 OneCLI 게이트웨이로 라우팅
에이전트별 정책 격리: 각 에이전트 그룹에 OneCLI 에이전트 ID를 할당해 크레덴셜 정책 차등 적용
호스트/경로 기반 매칭: onecli secrets create로 등록된 크레덴셜을 아웃바운드 요청의 호스트와 경로로 자동 매칭 후 주입
정책 레이어 구현: 호스트 패턴과 rate_limit 액션으로 Gmail API 호출을 시간당 3회로 제한하는 규칙 설정 가능 (예: onecli rules create --host-pattern "gmail.googleapis.com" --rate-limit 3 --rate-window 1h)

Impact

Meta 이메일 삭제 사건에서 시간당 3건 삭제 제한이 있었다면 피해를 3건으로 제한했을 수 있다.

Key Takeaway

에이전트 시스템의 보안은 런타임 격리(컨테이너)만으로 부족하며, 크레덴셜 접근 격리(프록시)와 정책 강제(rate limit, approval flow)의 다층 방어가 필요하다. 에이전트에게 실제 키를 전달하지 않고 게이트웨이를 통해 중개함으로써 에이전트 컨텍스트 내 키 추출을 근본적으로 차단할 수 있다.

실천 포인트

에이전트 기반 자동화 시스템을 구축하는 팀은 HashiCorp Vault나 AWS Secrets Manager 같은 시크릿 저장소만으로는 부족하며, 에이전트와 외부 서비스 사이에 정책 기반 프록시 계층을 삽입하고 rate limit, 시간 기반 접근 제한, 인간 승인 플로우를 구현하면 에이전트에게 실제 권한을 부여하면서도 피해 범위를 사전에 제한할 수 있다.

태그

#Access Control Policy #API Gateway #Credential Management #Agent Security

원문 읽기