2026년 2월 초, GitGuardian이 모든 개인 AI 어시스턴트 사용 개발자를 경악시킬 보고서를 발표했다. 그들의 시크릿 스캐닝 인프라가 OpenClaw 배포와 직접 연관된 200건 이상의 유출된 인증 정보를 탐지한 것이다 — API 키, 데이터베이스 비밀번호, OAuth 토큰, 클라우드 제공업체 인증 정보가 공개 저장소, 로그 파일, 오류 보고서에 흩어져 있었다. 일부는 의료 회사 소유였고, 다른 일부는 핀테크 스타트업 소유였다. 모두 활성 상태였다.
며칠 후, Northeastern University가 어떤 CVE 번호보다 날카로운 헤드라인의 기사를 발표했다: "왜 OpenClaw AI 어시스턴트는 '프라이버시 악몽'인가." 연구자들은 단일 취약점에 초점을 맞추지 않았다. 아키텍처 자체에 초점을 맞췄다 — OpenClaw가 데이터를 처리하고, 인증 정보를 저장하고, 사용자 정보를 노출하는 방식이 사고가 아닌 설계에 의한 것이라는 점이다.
이것들은 부주의한 사용자가 일으킨 고립된 사건이 아니었다. 시크릿, 사용자 데이터, 에이전트 코드가 모두 같은 주소 공간을 공유하며 격리가 전혀 없는 환경에서 AI 에이전트를 실행한 예측 가능한 결과였다.
시크릿이 엉뚱한 곳에 가는 과정
일반적인 OpenClaw 설정은 이렇다: 머신에 설치하고, 환경 변수에 API 키를 설정하고, 채팅을 시작한다. 에이전트 프로세스는 당신의 사용자 권한으로 실행되며, 당신의 환경 변수를 읽는다. 설치하는 모든 스킬이 같은 프로세스에서 같은 접근 권한으로 실행된다.
이는 AI 어시스턴트에게 배포 스크립트 디버깅을 요청하면, 에이전트가 당신의 AWS 인증 정보를 볼 수 있다는 뜻이다. 스킬이 이메일을 처리할 때 데이터베이스 비밀번호를 읽을 수 있다. 오류가 발생하고 스택 트레이스가 로그에 기록되면, 그 환경 변수가 로그 파일에 들어갈 수 있다. 그리고 그 로그 파일이 저장소에 커밋되거나, 버그 리포트에 업로드되거나, 클라우드 서비스에 동기화되면 — 당신의 시크릿은 이제 공개된 것이다.
GitGuardian의 200건 이상의 유출된 시크릿은 200번의 개별 실수가 아니었다. 하나의 아키텍처 실수가 200번 반복된 것이다: 프로세스의 모든 코드가 읽을 수 있는 process.env에 시크릿을 넣은 것.
문제는 스킬과 플러그인으로 더 심해진다. OpenClaw의 스킬 시스템은 서드파티 코드를 핵심 에이전트와 같은 프로세스에서 실행한다. 악성 스킬이 인증 정보를 훔치는 데 익스플로잇이 필요 없다 — 그냥 process.env를 읽으면 된다. 잘못 작성된 스킬이 의도적으로 데이터를 유출할 필요도 없다 — 오류 보고서에 환경 컨텍스트를 포함하기만 하면 된다. 공격 표면은 패치할 취약점이 아니다. 아키텍처 자체다.
Northeastern이 정확히 짚은 것
Northeastern 연구자들은 보안 커뮤니티가 에둘러 말하던 것을 정확히 짚었다: AI 어시스턴트의 프라이버시 문제는 암호화나 인증에 관한 것이 아니다. 에이전트가 무엇에 접근할 수 있고, 에이전트의 세계와 당신의 세계 사이에 어떤 경계가 존재하는가라는 근본적인 질문에 관한 것이다.
AI 에이전트가 당신의 사용자 권한으로, 당신의 머신에서 실행되면, 경계가 없다. 에이전트는 당신의 파일, 인증 정보, 브라우징 기록, SSH 키를 읽을 수 있다. 당신이 접근할 수 있는 모든 것에 접근할 수 있다. 해로운 행동을 막는 유일한 것은 프롬프트뿐인데 — 프롬프트 인젝션 공격은 프롬프트가 보안 경계가 아님을 반복적으로 증명해왔다.
이것이 Northeastern이 "프라이버시 악몽"이라 한 의미다. OpenClaw가 의도적으로 데이터를 훔치는 게 아니라, 아키텍처가 데이터 유출이 일어나지 않을 것이라고 보장하는 것을 불가능하게 만든다는 것이다. 에이전트의 접근은 운영체제의 사용자 권한으로만 제한되었는데, 이는 사실상 의미 있는 제한이 전혀 없다는 뜻이다.
NanoClaw의 컨테이너 격리가 판도를 바꾸는 방법
NanoClaw는 근본적으로 다른 접근 방식을 취한다. 모든 에이전트는 자체 Linux 컨테이너 안에서 실행된다 — macOS에서는 Apple Container, macOS와 Linux에서는 Docker. 컨테이너는 편의 기능이나 배포 옵션이 아니다. 보안 모델 그 자체다.
NanoClaw에 메시지를 보내면, 호스트 프로세스가 Claude를 직접 실행하지 않는다. 컨테이너를 생성하고, 에이전트가 접근해야 하는 특정 디렉토리만 마운트하고, 대화 컨텍스트를 전달한다. 에이전트는 자체 파일시스템, 자체 프로세스 공간, 자체 네트워크 스택을 가진 컨테이너 안에서 실행된다. 완료되면 컨테이너는 해체된다.
시크릿 처리가 흥미로운 부분이다. NanoClaw는 ANTHROPIC_API_KEY를 process.env에 절대 로드하지 않는다. 대신 런타임에 .env에서 키를 읽어 JSON 페이로드로 stdin을 통해 컨테이너 프로세스에 전달한다. 컨테이너 내부에서 에이전트 러너가 키를 받아 API 호출에 사용하고, 디스크에 기록하거나 환경 변수로 내보내지 않는다.
이는 악성 프롬프트가 에이전트를 속여 `printenv`나 `cat /proc/self/environ`을 실행하게 해도, API 키가 거기 없다는 뜻이다. 키는 에이전트 러너 프로세스 메모리에만, 그 단일 대화 턴 동안만 존재한다. 손상된 컨테이너는 접근 권한이 없는 것을 유출할 수 없다.
마운트 시스템이 또 다른 보호 계층을 추가한다. NanoClaw는 컨테이너에 마운트할 수 있는 디렉토리의 허용 목록을 프로젝트 루트 외부에 유지한다. 각 그룹은 자체 격리된 파일시스템 — 자체 CLAUDE.md 메모리 파일, 자체 쓰기 가능 작업 공간 — 을 갖는다. 허용 목록에는 심볼릭 링크 탈출 감지가 포함되어, 조작된 심볼릭 링크가 마운트 시스템을 속여 허용된 범위 밖의 디렉토리를 노출할 수 없다.
컨테이너는 또한 비루트 사용자로 실행되며, 프로젝트 소스는 읽기 전용으로 마운트된다. 에이전트는 컨텍스트를 이해하기 위해 코드베이스를 읽을 수 있지만, 호스트의 파일을 수정할 수 없다. 쓰기 가능 경로는 그룹별로 범위가 지정되고 컨테이너 종료 시 정리된다.
그룹별 격리 모델
NanoClaw의 격리는 에이전트를 호스트에서 분리하는 것을 넘어선다. 각 WhatsApp 그룹은 자체 컨테이너, 자체 메모리, 자체 파일시스템을 갖는다. 그룹 A는 그룹 B의 대화, 파일, CLAUDE.md 메모리를 볼 수 없다 — 애플리케이션 수준의 접근 제어 때문이 아니라, 별도의 마운트 포인트를 가진 물리적으로 분리된 컨테이너에서 실행되기 때문이다.
이는 대부분의 AI 어시스턴트가 완전히 무시하는 시나리오에서 중요하다: 공유 기기와 다중 사용자 환경. 가족과 NanoClaw를 사용한다면, 업무 그룹의 대화와 파일은 가족 그룹의 대화와 파일로부터 컨테이너 수준에서 격리된다. 그룹 간 데이터를 유출할 수 있는 애플리케이션 버그는 없다 — 격리가 애플리케이션이 아닌 컨테이너 런타임에 의해 시행되기 때문이다.
메인 WhatsApp 채널 — 어시스턴트와의 다이렉트 메시지 — 이 관리자 인터페이스 역할을 한다. 예약된 작업을 관리하고, 설정을 수정하고, 그룹 간 상태에 접근할 수 있는 유일한 채널이다. 그룹 채널은 기본적으로 자체 샌드박스로 제한된다.
업계가 배워야 할 것
GitGuardian 보고서와 Northeastern 분석은 같은 결론을 가리킨다: AI 에이전트는 인프라이며, 인프라에는 인프라 수준의 보안이 필요하다. AI 에이전트를 인증 정보와 같은 프로세스에서, 사용자 계정과 같은 권한으로 실행하는 것은 방화벽 없이 루트로 웹 서버를 실행하는 것과 같다. 문제가 생기기 전까지는 작동하고, 문제가 생기면 피해 범위는 모든 것이다.
컨테이너 격리는 새로운 아이디어가 아니다. 웹 호스팅 업계는 20년 전에 이걸 깨달았다 — 여러 고객의 코드를 같은 프로세스에서 실행하지 않는다. 데이터베이스 업계는 더 일찍 깨달았다 — 모든 쿼리에 모든 테이블 접근 권한을 주지 않는다. 하지만 AI 에이전트 생태계는 아직 "모든 것을 루트로 실행" 단계에 있으며, 유출된 시크릿과 프라이버시 악몽은 예측 가능한 결과다.
NanoClaw의 접근 방식이 이 문제를 해결하는 유일한 방법은 아니지만, 기능을 희생하지 않고도 문제를 해결할 수 있음을 보여준다. 컨테이너 안에서 실행되는 에이전트도 웹 검색, 페이지 탐색, 파일 읽기/쓰기, 셸 명령 실행이 가능하다. 다만 모든 실패 — 버그든, 프롬프트 인젝션이든, 악성 스킬이든 — 의 피해 범위가 해당 단일 컨테이너의 범위로 제한되는 샌드박스 안에서 수행할 뿐이다.
GitGuardian이 발견한 200건의 유출된 시크릿은 일어나지 않아도 됐다. 아키텍처가 그것을 불가피하게 만들었기에 일어난 것이다. 해결책은 더 나은 사용자 교육이나 더 신중한 인증 정보 관리가 아니다. 해결책은 시크릿이 유출 가능한 곳에 애초에 존재하지 않기 때문에 유출될 수 없는 아키텍처다.