코딩 도구와 LLM 제공자를 항상 분리하고, bubblewrap 샌드박스로 코딩 도구의 권한을 제한함
도구는 작업 프로젝트 디렉터리만 읽을 수 있고, .git은 읽기 전용이며 민감한 디렉터리는 빈 디렉터리로 마운트함
네트워크 네임스페이스도 격리해 Unix 소켓의 HTTP 프록시로만 인터넷에 접근시키고, 특정 LLM 제공자 호스트만 허용하되 도구 자체의 호스트는 차단함
예를 들어 Crush에는 *.openrouter.ai 접근을 허용하지만 LLM 목록 자동 업데이트에 쓰이는 *.charm.land는 막음. 덕분에 yolo 모드로 모든 작업을 맡기기가 훨씬 편해짐

bubblewrap에서는 Docker Hub의 debian:unstable 같은 rootfs를 받아 별도 폴더에 완전한 배포판 환경으로 구성하는 편이 좋음
그 안에 AI 에이전트를 설치한 뒤, 배포판 rootfs는 읽기 전용으로, 맞춤형 /home/user는 읽기·쓰기로 지정해 bwrap을 실행하는 스크립트를 만들면 됨. 지정한 디렉터리 밖의 중요한 파일은 보이지 않고, 여러 에이전트를 서로 보이지 않게 실행할 수도 있음
더 강화하려면 내부에서 gVisor의 runsc ... do ...를 호출하거나 muvm 같은 가상 머신 모니터를 사용할 수 있음. bwrap은 환경 구성을 맡기고 별도의 샌드박스 도구로 잠그는 방식이라 신뢰하기 좋음
설정이 올바르다면 bwrap만으로도 대부분의 공격자를 막기에 충분하며, 권한 상승에는 사실상 Linux 커널 제로데이를 써야 할 가능성이 큼

이를 구현할 때 어떤 방식을 사용하는지 궁금함

이런 추가 보안 강화가 단지 안심을 주는 데 그치는지, 실제로 위험한 동작을 잡아낸 적이 있는지 궁금함
제약으로 막아야 할 만큼 어리석은 행동을 하는 모델이라면 애초에 쓸 가치가 없다고 봄. 나도 자체 환경을 강화하는 중이며, 관행 자체를 비판하려는 것은 아님

claude-code, Codex, grok-build 같은 독점 네이티브 코딩 에이전트 실행기는 다음 업데이트에 어떤 비공개 기능이 추가될지 알 수 없어 프라이버시 측면에서 위험함
opencode에서 API를 통해 모델을 쓰는 편이 훨씬 안전하지만, 네이티브 실행기만큼 좋은 성능을 내기는 어렵다는 절충이 따름

사용량이 충분하면 서버 측 도구 호출만으로도 전체 코드베이스를 재구성할 수 있고, 이 과정은 완전히 탐지하기 어려움
Grok의 방식이 더 노골적일 뿐 opencode도 실질적인 보안 경계를 만들지 못하며, 치토스를 자물쇠로 쓰는 밈과 비슷함

Codex는 오픈소스임

자동 업데이트 자체도 큰 문제임
Windows XP SP1의 원격 코드 실행 취약점 같은 것을 즉시 패치하지 않는 것도 위험하지만, 지난 수십 년 동안 업데이트를 하지 않아 생겼을 법한 피해보다 자동 업데이트로 발생한 피해를 더 많이 봤음

자체 에이전트를 사용하지만, 그것 때문에 회사 계정이 차단될 위험은 감수할 수 없음

“에이전트가 읽은 파일과 무관하게 추적 중인 모든 파일 내용과 Git 이력을 포함한 저장소 전체를 업로드한다”는 것은 매우 충격적임
Elon이 따라잡으려고 이런 일을 할 수도 있으리라 어느 정도 예상했지만 심각하게 우려됨. 가격 경쟁력이 있고 grok-4.5의 성능도 충분히 좋지만, 바로 이런 이유로 선택하지 않았음

명백한 데이터 유출이며 불법이어야 함

Microsoft와의 협력 관계 때문에 OpenAI도 모든 GitHub 저장소에 접근할 수 있는지 궁금함

결국 바닥을 향한 경쟁임

어떤 데이터를 공유해야 하는지에 관한 정보를 찾지 못해 무료 체험조차 망설였음

이런 CLI는 항상 접근 가능한 디렉터리를 제한하는 샌드박스 안에서 실행함
CLI가 실수로 SSH 키나 다른 민감한 정보를 가져갈 수도 있고, 프로그래머는 실제로 이런 실수를 자주 저지름. “접근 가능한 모든 파일 업로드”가 고의인지 실수인지에 안전을 맡기고 싶지 않음

첫 번째 항목인 “저장소 안의 비밀정보 파일을 모델이 읽었다”는 것은 사실상 의도된 동작임
LLM은 파일을 읽기 전에 그 안에 비밀정보가 있는지 판단할 수 없음. 평문 비밀정보가 담긴 파일에 LLM 접근 권한을 주고 읽었다며 놀라는 쪽이 근본적인 문제임
다만 저장소 전체를 자동으로 업로드하는 것은 터무니없음. 수 GB 규모의 저장소라면 일부 회선에서 매우 오래 걸리고, 모든 데이터를 모으려는 다른 목적이 없다면 대체로 무의미해 보임

에이전트를 실행한 현재 작업공간은 적어도 에이전트가 자유롭게 다룰 수 있다고 늘 가정해 왔기 때문에 예상된 동작처럼 보임
대부분의 에이전트는 첫 프롬프트에서 코드와 그 안의 비밀정보까지 읽음. 서버에서 이를 활용해 프롬프트 왕복 시간과 도구 호출을 줄인다면 오히려 사용자에게 이득 아닌지 궁금함

파일을 읽고 응답을 전달할 때는 일반적인 메시지 API를 사용함
그런데 여기서는 프로젝트 폴더 전체를 GCP 스토리지 버킷으로 빼내는 별도 엔드포인트가 발견됨. 대규모 분산 시스템을 설계해 본 사람이라면 훈련 데이터를 긁어모으려는 구조임을 알 수 있음

Cursor는 로컬에서 일종의 색인 작업을 하는 것으로 알고 있음
모든 파일을 업로드하지 않고도 검색을 통해 관련 부분만 찾아 모델이 사용할 수 있도록 전송할 수 있음

개요를 사람이 작성했다면 좋았겠지만, 내용 자체는 불안함

업로드되는 내용을 보여주는 코드 블록 몇 개와 2~3개 문단이면 충분했을 글임
AI가 작성한 보고서는 읽기가 너무 고역이라 10초 정도 훑다가 흥미를 잃었음

최소한 사람이 LLM과 몇 차례 더 다듬어 문체를 개선할 수도 있었음

훔친 내용이 “모든 비즈니스를 자동화”한다는 Macrohard 프로젝트나 “everything app”에 들어갈지 궁금함
모든 것을 직접 만들 필요 없이 훔치면 된다는 발상처럼 보임

사용자가 이런 특권을 누리려고 돈까지 낸다는 점이 화룡점정임
도덕성이 없는 채 이런 회사를 운영한다면 사기의 규모가 드러나고 규제가 막기 전에 최대한 많이 훔치려 할 것임. 실제로 그렇게 하고 있다는 뜻은 아니지만, 경제적 유인은 정확히 그 방향으로 정렬돼 있음

AI 에이전트는 실행기가 시작된 디렉터리의 파일을 읽을 수 있다고 봐야 함
대부분 첫 프롬프트에서 코드와 그 안의 비밀정보까지 읽으며, .env는 로컬 환경용이라 실제 비밀정보를 담아서는 안 됨. AI 에이전트는 지시를 신뢰할 수 없으므로 진짜 비밀정보와 격리해야 함
이런 전제를 받아들인다면 코드를 매번 컨텍스트로 보내는 것보다 서버에 올려 두는 편이 나을 수도 있음

LLM의 작동 방식상 결국 코드는 컨텍스트를 통해 다시 전달돼야 함
이렇게 별도 업로드할 이유는 Musk가 다음 모델을 위해 프로젝트 구성, 인기 라이브러리, CI 작업 흐름 같은 깨끗한 훈련 데이터를 확보하려는 것뿐이라고 봄

한 번 업로드해도 추론 과정에는 여전히 들어가며, 절약되는 것은 약간의 HTTP 트래픽 정도임

이야기의 핵심은 크지 않음. Grok이 다른 제공자보다 컨텍스트 구성에서 10% 정도 더 공격적이거나, 단순히 이 방식이 더 빨리 출시할 수 있었던 것일 가능성이 큼
모든 제공자는 결과 개선에 도움이 된다면 같은 일을 할 능력과 유인이 있음
진짜 차이는 .env 같은 비밀정보 파일을 가리지 않고 전송하고, 일시적으로 처리하는 데 그치지 않고 이름이 지정된 GCS 버킷에 저장하며, CLI 설정 문서에 업로드 방식을 알리지 않은 채 기본 활성화했다는 것임
접근 가능한 경로에 암호화되지 않은 .env를 두어서는 안 됨. Grok이 비밀정보를 식별해 무시하는 편이 낫겠지만, 사용자가 그런 동작에 의존해서는 안 됨

“Improve the model” 설정을 켜든 끄든 저장소 전체가 똑같이 업로드된다는 점은 매우 심각함
대부분의 AI 업체도 데이터 수집에 동의하면 자체 실행기에서 비슷한 일을 하겠지만, 명시적으로 껐는데도 업로드하는 것은 악의적임

코드베이스 전체를 업로드하면 모델이 “생각”하는 동안 클라이언트에 실제 도구 호출을 요청하지 않고도 코드를 살펴볼 수 있음
클라이언트로 다시 요청하는 것의 단점이 무엇인지 불분명해 아주 좋은 이유는 아니지만, 생각할 수 있는 최선의 명분임

실제 목적은 영업비밀, 앱 설계, 사내 업무 지식을 훔치거나 코드·앱·도구·절차를 복제하려는 것에 더 가까워 보임
원래 비공개였던 코드가 이제 그들의 코드가 됨

컴퓨터가 오프라인이어도 어딘가의 컨테이너를 통해 휴대전화에서 원격 제어하고, 나중에 로컬 개발로 돌아와 GCP 버킷의 변경 사항을 동기화하려는 용도일 수 있음
꽤 유용하지만 Elon에게 저장소 전체를 넘길 만큼 유용하지는 않음. 거부할 수 없게 만들고 전혀 공개하지 않았다는 사실은 이 데이터를 맡겨서는 안 된다는 판단을 더욱 강화함