제품 전반에서 Claude를 격리하는 방식들

쓰는 프레이밍이 웃기고 작은 그래픽도 딱 맞음. 피해 위험은 줄지 않지만 보상은 커지니, 피해가 보상으로 정당화되는 사업 비용이 되어버림
보상이 점점 커질수록 정당화하려는 피해 규모도 커짐. 사회 전체가 이렇다는 느낌

제대로 이해했다면 Anthropic의 주장은 이제 “네, 이게 여러분 인프라 일부를 날려버릴 수는 있지만, 그만한 가치가 있습니다”에 가까움
문제는 실제로 그 비용을 감수할 만큼 가치가 있다는 걸 아무도 증명하지 못했다는 것. 꽤 취약한 가정임

모든 행동에는 위험/보상 계산이 있고, 보통 이렇게 노골적으로 그려진 걸 못 볼 뿐임. 아침에 침대에서 일어나는 것도 넘어져 머리를 바닥에 찧을 위험이 있고, 길을 건너는 것도 버스에 치일 위험이 있으며, 음식을 먹는 것도 목에 걸릴 위험이 있음
컴퓨터 보안도 마찬가지임. 진짜로 안전한 컴퓨터는 켜지 않는 컴퓨터뿐이고, 그것조차 누군가 침입해서 저장장치를 훔쳐갈 위험은 있음. 이 경우 잠재적 피해가 이익보다 큰지와 별개로 그런 계산은 항상 일어나니, 사회 전체가 이렇다는 말은 맞다고 봄

PC 수리업을 시작하면 처음엔 주 10건 처리할 때 RAM 하나를 잃거나 고객 메인보드를 태우는 게 엄청난 비용임. 하지만 주 1000건을 처리하게 되면 꽤 괜찮은 사업이고 그런 손실은 쉽게 감당 가능함
도구와 처리 속도 같은 게 늘어나면 비율이 달라짐

현실의 의사결정은 원래 그렇게 이뤄짐. 위험/보상은 실제로 존재함

유한책임은 무제한 위험을 감수하는 걸 합리적 선택으로 만듦. AI는 이 기업 모델을 키우고 다음 재난까지의 시간을 압축할 뿐임

Anthropic이 하는 말은 굉장히 회의적으로 봄. IPO를 앞두고 제품이 위험해 보이도록, 즉 “유능하고”, “공상과학 같고”, “모두보다 앞서 있다”는 인상을 줄 유인이 너무 크기 때문임
이전에도 그런 적이 있음. “위협받으면 모델이 엔지니어의 이메일을 이용해 불륜을 협박한다”던 얘기를 떠올려보면, 그건 그냥 팬픽션이었음. 사실 몇 개로 시나리오를 만들고 모델에게 이야기를 이어 쓰게 했을 뿐임. Claude에게 영국 왕실 보석을 훔치는 방법을 물어보면 아이디어를 줄 것임. 그렇다고 Tower of London의 보안을 강화해야 할 만큼 모델이 위험하다는 뜻은 아님. 다른 공포 마케팅도 대체로 비슷하다고 봄

“그들이 사실 몇 개로 시나리오를 만들고 모델에게 이야기를 이어 쓰게 했을 뿐”이라는 건 맞음. 그게 연구의 핵심임. Anthropic은 블랙메일 테스트 관찰 설명을 시작하면서, 가상의 회사를 쓰는 테스트 시나리오라고 명시함
“In another cluster of test scenarios, we asked Claude Opus 4 to act as an assistant at a fictional company” https://www.anthropic.com/claude-4-system-card

OpenAI보다 Anthropic이 더 걱정되는 건 기만적이기 때문임

OpenAI, Google 등은 “그 전략”을 쓰고 있지 않음. Anthropic 사람들은 실제로 AI 안전을 진심으로 신경 쓴다고 믿음
회사가 설립된 주된 이유도 그거였음. 다만 새 사람들과 돈이 들어오면서 그 이상주의가 약해지고 있을 수는 있다고 봄

이 스레드에 늦게 왔지만, 글은 Claude 접근을 컨테이너로 제한하는 “pattern 1”에서 생길 수 있는 위험, 실수, 사고 부분을 건너뛴 것 같음. 제대로 하기는 여전히 어렵다
예를 들어 Anthropic은 임시 컨테이너로 격리된 어떤 claude.ai/code 세션이든 사용자의 다른 세션, 연결된 저장소, 환경 변수를 모두 접근하고 유출할 수 있게 하는 버그를 여러 번 배포했음. 악성화되거나 탈취된 Claude는 원래 세션 제약과 무관하게 임의 지시와 접근 권한을 가진 새 Claude 세션도 만들 수 있었음. 이 내용을 2월에 허가를 받고 처음 썼고[1], 대부분은 빠르게 수정됐음. 하지만 근본적인 토큰 범위 문제는 Mythos 이후를 포함해 여러 차례 재발했기 때문에, Anthropic이 이걸 해결했다고 보기는 어려움
[1]: https://www.noahlebovic.com/hacking-claude-code-on-the-web-b...

일반적으로 이걸 하기는 정말 어려움. 아쉽게도 블로그 글은 몇 가지 사례를 언급하긴 하지만 얼마나 어려운지는 깊게 다루지 않음
예를 들어 에이전트를 네트워크 접근 가능한 VM에서 실행하면, 그 안에서 만난 무언가가 프롬프트 주입으로 에이전트를 속여 VM 밖으로 나오는 산출물에 2차 프롬프트 주입을 인코딩하게 만들 수 있고, 그게 로컬의 더 권한 높은 에이전트를 감염시킬 수 있음. 이전 직장에서 컴퓨터 사용 분석을 할 때는 사용자 입력을 악성이 아니라고 신뢰할 수 있는지 따져봤음. 사용자가 직접 타이핑했다면 대체로 괜찮겠지만, 사용자 파일은? 캘린더 일정은? 제품의 목적 자체가 에이전트가 그걸 대신 관리하는 것이었기 때문에, 더 이상 주입이 없다고 신뢰할 수 없게 됨. 이런 오염 추적을 해보면 이런 일을 막기가 매우 어렵고, 샌드박스나 VM을 둘러치는 것만으로는 대개 도움이 안 된다는 걸 금방 알게 됨

에이전트가 속아서 프로젝트에 악성 라이브러리를 쓰고, 그걸 커밋하고 푸시할 수 있음. 이후 사용자가 VM 밖에서 실행하면 위험함
저장소 코드를 VM 밖에서 실행하면서 커밋된 내용을 전부 검토하지 않는다면 여전히 위험함

Cowork VM을 들여다보면, 오염이 문서화되어 있지 않고 공개적으로 제어도 안 됨. 우회 방법은 갖고 있지만, 과정에서 낭비와 답답함이 많이 생김 CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1은 Claude가 시간이 지나며, 그리고 설정에 따라 마운트된 모든 저장소의 CLAUDE.md를 찾아 로드한다는 뜻임. 그래서 서로 무관한 저장소 여러 개를 동시에 작업하는 경험이 기본 상태에서는 좋지 않음
흥미로운 VM 환경 변수 몇 가지: CLAUDE_CODE_IS_COWORK=1 CLAUDE_CODE_BRIEF=1 CLAUDE_CODE_BRIEF_UPLOAD=1 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 CLAUDE_CODE_DISABLE_CRON=1 CLAUDE_CODE_ENTRYPOINT=local-agent CLAUDE_CODE_EXECPATH=/usr/local/bin/claude CLAUDE_CODE_HOST_HTTP_PROXY_PORT=36543 CLAUDE_CODE_HOST_PLATFORM=darwin CLAUDE_CODE_HOST_SOCKS_PROXY_PORT=46673 USE_STAGING_OAUTH= _=/usr/bin/env all_proxy=socks5h://localhost:1080 ftp_proxy=socks5h://localhost:1080 grpc_proxy=socks5h://localhost:1080 http_proxy=http://localhost:3128 https_proxy=http://localhost:3128 no_proxy=localhost,127.0.0.1,::1,.local,.local,169.254.0.0/16,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

“에이전트가 더 유능해질수록 잠재적 폭발 반경도 커진다. 엔지니어링 질문은 그걸 어떻게 제한할지다”라는 문구에 대해, 요즘 LLM을 의인화하면 사람들이 좀 불편해하지만, 그보다 더 나쁜 건 LLM이 영화 논리처럼 인터넷으로 몰래 흘러나가 점액처럼 복제를 시작할 수 있다고 가장하는 것 같음

문제는 우리가 모델에게 문제를 풀고 주어진 지시를 따르도록 훈련시킨다는 데 있음. 어떤 일을 시키면 모델이 논리를 따라가다가 가장 쉬운 방법이 프로덕션 데이터베이스를 삭제하는 것이라고 판단할 수 있고, 접근 권한이 있으면 모든 자격 증명을 뒤져 데이터베이스 자격 증명을 찾아 실제로 삭제할 수 있음
이런 일을 해내는 능력은 점점 좋아지고 있고 지시를 따르는 것도 잘하지만, 모든 지시를 따르거나 상식적으로 행동하는 데 항상 능숙하지는 않음. 점액처럼 빠져나가 복제한다기보다는, 더 많은 접근 권한을 줄수록 어느 순간 모델이 사용자가 원치 않는 행동을 해야 한다고 논리적으로 결론 내릴 가능성이 커짐. 명시적으로 금지하지 않았거나, 문맥이 너무 복잡해져 그 지시의 가중치가 낮아지고 다른 지시를 따르게 되는 식임. 실제로 어떤 일을 하려면 서비스 접근용 API 키가 필요하다고 결론 내린 사례를 봤음. 모델에게 그 키는 없지만, 사용자는 브라우저에서 접근할 수 있음. 그래서 브라우저 쿠키를 긁어내는 Python 스크립트를 작성했음. 이건 에이전트 샌드박스가 아니라, CrowdStrike가 브라우저 쿠키를 긁으려는 낯선 Python 스크립트를 싫어해서 막힌 문제였음

왜 안 되겠나? 모델 자체를 실행하는 얘기가 아니라면, AI 에이전트는 소프트웨어 취약점을 통해 더 많은 에이전트를 퍼뜨리는 에이전트 웜을 작성할 수 있음
지금은 LLM이 하드웨어를 너무 많이 요구해서 모델 자체가 퍼지긴 어렵지만, 몇 년의 시간과 최적화가 있으면 그것도 볼 수 있을지 모름. “이미지는 바이러스를 퍼뜨릴 수 없다”고 하던 옛날이 떠오름. 그러다 디코더 취약점이 발견되고 실제로 그런 이미지 바이러스가 만들어졌음

qemu VM을 쓰고 있음. 이 VM은 인터넷 접근이 있고, Claude가 어딘가에 데이터를 업로드할 수 있다는 게 가장 큰 위험일 것 같음
GitHub로 작업하게 하려면 저장소 단위로 읽기 또는 읽기/쓰기 권한이 제한된 토큰을 만듦. 그래도 푸시보다는 커밋만 하게 하고, 내가 VM에서 SSH로 커밋을 가져와 로그를 확인한 뒤 직접 푸시하는 쪽을 선호함. 컨테이너에서 Claude를 실행하는 것도 생각했지만 좀 약하게 느껴짐. Linux 취약점이 너무 많음. 이 두려움이 근거 없을 수도 있지만, 신뢰할 수 없는 건 qemu VM에서 돌릴 때 더 안전하다고 느낌

최근 bubblewrap으로 프로세스를 실행해, 실행한 디렉터리에만 읽기/쓰기 접근을 주고 나머지는 읽기 전용으로 만드는 작은 도우미 함수를 급히 만들었음. GUI와 libportal 같은 게 동작하도록 몇몇 특정 Linux 시스템 디렉터리는 예외로 둠
에이전트에게 여기저기 있는 스크린샷이나 로그 파일 같은 임의의 것들을 실제로 가리키게 하고 싶지만, 동시에 매번 수동 승인하며 지켜보고 싶지는 않은 작업에는 컨테이너보다 훨씬 덜 귀찮음. 이런 경험에 AI 도구 플랫폼들이 이미 투자하고 있지 않다는 게 꽤 이상함. 이걸 만들게 된 계기는 Zed 때문이었음. AI 작업을 전제로 한 편집기인데, 에이전트의 특정 경로 권한을 사용자 전체 설정 파일에만 넣을 수 있음. 프로젝트 수준 설정 파일은 존재하지만, 이해할 수 없는 이유로 에이전트 권한 설정은 명시적으로 지원하지 않음

의사결정 이론가는 아니지만, 보상과 기대 피해가 통계적으로 같아질 때가 아니라 기대값상 보상이 피해를 넘어설 때까지 기다려야 한다고 봄