NanoClaw, OneCLI Agent Vault 도입
Source: Hacker News
NanoClaw은 기본 자격 증명 및 프록시 계층으로 OneCLI를 채택하고 있습니다. 모든 NanoClaw 에이전트는 OneCLI의 Agent Vault를 통해 외부 서비스에 접근하며, 이 게이트웨이는 자격 증명 주입, 접근 정책 및 승인 절차를 처리하여 에이전트가 원시 API 키를 보관하지 않도록 합니다.
NanoClaw은 이미 각 에이전트를 자체 Docker 컨테이너에 격리하고 있습니다. OneCLI의 Agent Vault를 사용하면 해당 에이전트가 무엇을 어떻게 접근할 수 있는지에 대해 세밀한 제어가 가능합니다.
통합 작동 방식
NanoClaw는 이전에 모든 비밀을 메모리에 보관하는 자체 인증 프록시를 실행했습니다. 우리는 이를 @onecli-sh/sdk 로 교체했습니다. NanoClaw가 컨테이너를 시작할 때 applyContainerConfig() 를 호출하여 OneCLI 게이트웨이를 통해 외부 HTTPS 트래픽을 라우팅하고, 게이트웨이가 실제 인증 정보를 주입합니다:
import { OneCLI } from '@onecli-sh/sdk';
const onecli = new OneCLI({ url: ONECLI_URL });
// Configure container to route through the gateway
await onecli.applyContainerConfig(containerArgs, {
agent: agentIdentifier, // per-agent credential policies
});
각 NanoClaw 에이전트 그룹은 자체 OneCLI 에이전트 ID를 갖게 되므로, 영업 에이전트와 지원 에이전트가 서로 다른 인증 정책을 가질 수 있습니다. onecli secrets create 로 한 번만 인증 정보를 등록하면, 게이트웨이가 호스트와 경로에 따라 외부 요청을 매칭합니다.
왜 이것이 중요한가
OpenClaw는 사람들이 실제 작업을 대신 수행해 주는 에이전트의 가치를 얻기 위해 이메일, 캘린더, 코드 저장소, 데이터베이스에 대한 접근 권한을 기꺼이 넘겨준다는 것을 입증했습니다. 수백만 명이 정확히 그렇게 했으며, 대부분의 경우 문제없이 잘 작동합니다. 하지만 그렇지 않을 때는 현실적인 위험이 발생합니다.
Meta의 AI 정렬 담당 이사에게 OpenClaw가 자신의 이메일에 접근하도록 허용했으며, 승인 없이 어떠한 행동도 하지 말라고 명시했습니다. 그럼에도 불구하고 에이전트는 대량 삭제를 시작했습니다. 그녀는 휴대폰으로 이를 멈출 수 없었고, 직접 컴퓨터 앞에 달려가 프로세스를 종료해야 했습니다.
이 이야기는 에이전트가 경계 없이 작동할 때 어떤 일이 일어나는지를 보여줍니다. 에이전트의 가치는 실제 시스템과 실제 데이터에 접근할 수 있게 함으로써 얻어집니다. 아무것도 건드릴 수 없는 에이전트는 단지 챗봇에 불과합니다. 그러나 정책도 없고, 속도 제한도 없으며, 승인 흐름도 없는 상태에서 모든 것을 건드릴 수 있는 에이전트는 위험 요소가 됩니다. 문제는 위험 없이 Claw 잠금을 해제하는 방법을 찾는 것입니다.
Source:
비밀 관리 그 너머
오늘날 에이전트를 사용하는 대부분의 사람들은 API 키를 환경 변수에 하드코딩하거나 비밀 관리자에서 가져옵니다. HashiCorp Vault나 AWS Secrets Manager와 같은 비밀 관리자는 저장을 해결하지만, 에이전트가 실제로 자격 증명을 사용할 때 발생하는 문제는 해결하지 못합니다. 에이전트가 키를 가져오면 그 순간부터 키는 에이전트의 환경, 즉 컨텍스트에 존재하게 되며, 프롬프트 인젝션을 통해 추출될 수 있습니다. Vault는 휴식 상태의 비밀을 보호했지만, 에이전트가 키를 손에 넣으면 Vault는 더 이상 관여하지 않게 됩니다.
Agent Vault는 에이전트와 에이전트가 호출하는 서비스 사이에 위치합니다. 여러분의 자격 증명은 여전히 현재 보관하고 있는 곳에 존재합니다. 원시 키를 에이전트에 직접 전달하는 대신, Vault가 요청을 프록시하고, 호스트와 경로를 기준으로 매칭한 뒤 실제 자격 증명을 삽입하고 전달합니다. 에이전트는 키를 절대 보지 못합니다. 절대 보관하지도 않으며, 절대 로그에도 남기지 않습니다.

정책, 프록시만이 아니라
에이전트 볼트가 키를 교환하는 것만으로도 유용하지만 제한적일 것입니다. 더 중요한 부분은 그 위에 있는 정책 레이어입니다.
에이전트가 시간당 몇 개의 이메일만 전송하거나 삭제하도록 속도 제한을 설정할 수 있습니다:
# Rate-limit Gmail API calls to 3 per hour
onecli rules create \
--name "Gmail rate limit" \
--host-pattern "gmail.googleapis.com" \
--action rate_limit \
--rate-limit 3 \
--rate-window 1h
시간 제한 접근, 인간이 개입하는 승인, 그리고 더 고급 정책 제어가 곧 제공됩니다. 메타 사건을 다시 떠올려 보세요: 만약 시간당 세 개의 이메일 삭제 제한이 있었다면, 피해는 전체 받은 편지함이 아니라 세 개의 이메일에 그쳤을 것입니다. 에이전트는 제한에 도달했을 것이고, 사용자는 알림을 받았을 것이며, 수백만 명이 보는 교훈적인 이야기가 아니라 사소한 불편에 그쳤을 것입니다.
팀과 조직의 경우, 이러한 정책은 두 단계에서 작동할 수 있습니다: 조직은 가능한 범위의 외부 경계를 설정하고, 개별 사용자는 그 프레임워크 내에서 권한을 부여합니다. 심지어 자신의 컴퓨터에서 NanoClaw를 실행하는 단일 사용자라도 “내 이메일에 접근할 수는 있지만, 시간당 세 개의 메시지만 삭제할 수 있다”는 말을 할 수 있는 능력은 에이전트에게 허용할 수 있는 범위에 대한 계산을 크게 바꿔줍니다.
전체 스택
NanoClaw는 런타임 격리를 해결합니다. 모든 에이전트는 자체 파일 시스템과 프로세스 공간을 가진 별도의 컨테이너에서 실행되며 호스트에 대한 주변 접근이 없습니다. OneCLI의 Agent Vault는 자격 증명 격리와 정책 시행을 해결합니다. 이 두 요소가 결합되어 에이전트는 가시적이고, 감사 가능하며, 강제할 수 있는 경계 내에서 작동합니다.
두 프로젝트 모두 오픈 소스입니다. NanoClaw는 에 있고 OneCLI는 에 있습니다.