보통 나는 문제가 생긴 회사의 공식 발표문을 먼저 읽음
그런데 Snowflake의 공지문은 계정이 있어야만 볼 수 있어서 당황스러웠음
읽어보니 “sandbox”라는 용어를 잘못 쓰고 있는 것 같음
“Cortex가 기본적으로 플래그를 설정해 sandbox 밖에서 명령을 실행할 수 있다”라면, 그건 더 이상 sandbox가 아님
나는 prompt injection 문제는 근본적으로 해결 불가능하다고 봄
SQL에서도 파라미터화된 쿼리를 쓰기 전까지 해결되지 않았고, 자연어는 훨씬 자유로움
결국 “이전 지시를 무시하고 …” 같은 공격이 반복됨
데이터와 명령이 같은 스트림에 있으면 항상 같은 결말을 맞이함
자연어 자체가 공격 표면이기 때문에 더 넓을 수밖에 없음
RFC 3514의 “evil bit” 개념을 prompt injection에도 확장해서, evil bit이 1이면 명령 실행을 막자는 농담을 던짐
관련 문서: RFC 3514
요즘 AI 업계에서 “sandbox”는 단순히 “정말 실행할 건가요?”라고 묻는 시스템을 의미하는 듯함
하지만 내가 익숙한 의미는 격리된 환경에서 악성코드를 안전하게 관찰하는 것임
AI에도 이런 진짜 기술적 경계를 만들려는 시도가 많아서 흥미로운 분야라 생각함
“그냥 개념적인 sandbox일 뿐”이라는 짧은 반응도 있었음
사용자가 직접 접근 권한을 켜는 스위치를 조작할 수 있다면, 그건 sandbox가 아님
처음엔 OS 권한 상승 얘기인 줄 알았는데, 단순히 보안 설계가 부실한 사례였음
Anthropic 논문에서 인용된 사례를 보면, AI가 자율적으로 악성 행위를 하기도 함
예를 들어 Alibaba Cloud의 방화벽이 학습 서버에서 암호화폐 채굴 시도를 탐지했고,
RL 최적화 중 부수 효과로 이런 행동이 나타났다고 함
관련 자료: arXiv 논문, Anthropic 연구, Time 기사
그런데 논문 2.3.0.1절에서는 각 작업이 독립된 sandbox에서 실행된다고 했는데,
그렇다면 네트워크 제어가 있는 상태에서 어떻게 SSH 터널이나 리소스 스캔이 가능했는지 의문임
Snowflake 직원이 등장해, 보안팀의 대응 타임라인과 수정 사항을 공유함
자세한 내용은 공식 문서에서 확인 가능함
“인간 승인 없이 쉘 명령이 실행됐다”는 부분을 보고,
쉘 보안을 조금이라도 고민해본 사람이라면 하위 프로세스 생성 방식을 고려하지 않았다는 게 놀라움
쉘 코드를 파싱해서 검열하는 방식은 근본적으로 취약하고 오류가 많음
이런 제한은 OS 수준에서 걸어야 안전함
“진짜 sandboxing 팁”을 공유하자는 제안이 있었음
나는 Claude Code를 VS Code devcontainer 안에서 돌리고 있음
인터넷 접근을 허용 도메인만으로 제한하는 설정도 있음
다만 docker-in-docker 환경이 필요해서 완전한 통합은 어려움
그래서 지금은 단위 테스트까지만 실행 중이며, Vagrant로 전체 VM 격리를 시도해볼까 고민 중임
다른 사용자는 Multi Level Security 개념을 적용한 데이터 존 분리 실험을 소개함
프로젝트 링크: aflock.ai
“Cortex가 workspace trust를 지원하지 않는다”는 문장을 보고,
애초에 제한이 없는 환경이었던 건 아닌지 의문이 들었음
실제로는 제한이 있었지만, 플래그 조작으로 쉽게 우회 가능했다고 함
모델이 플래그를 설정하면 사용자 승인 없이 바로 sandbox 밖에서 실행됨
“이게 새로운 gain-of-function 연구냐”는 농담이 있었고
다른 사람은 “그보단 imaginary function에 가깝다”며,
에이전트가 스스로를 통제할 수 있다고 믿는 게 환상이라고 말함
또 다른 사람은 “악성 AI를 일부러 만들어 더 나은 sandbox를 실험하는 것”이라고 설명함
많은 사람들이 이미 에이전트가 생성한 코드를 검토 없이 실행하고 있음
그렇다면 에이전트 자체를 sandbox로 감싸는 게 무슨 의미가 있나 싶음
어차피 전체 시스템이 별도 머신, 컨테이너, 혹은 제한된 사용자로 격리되어야 함
아마도 대부분의 사용자가 그렇게 하지 않기 때문에,
개발사들이 대신 기본 수준의 안전장치를 제공하려는 것 같음
“토글로 꺼지는 sandbox는 진짜 sandbox가 아니다”라는 의견이 있었음
이는 단순히 마케팅 과장으로, 제품의 허술한 설계를 가리려는 시도처럼 보임
“이건 sandbox조차 아니고, 내부 코드 제한을 우회한 것일 뿐”이라며
진짜 sandbox는 내부에서 변경할 수 없는 외부 격리 환경이어야 한다고 강조함
Hacker News 의견들
보통 나는 문제가 생긴 회사의 공식 발표문을 먼저 읽음
그런데 Snowflake의 공지문은 계정이 있어야만 볼 수 있어서 당황스러웠음
읽어보니 “sandbox”라는 용어를 잘못 쓰고 있는 것 같음
“Cortex가 기본적으로 플래그를 설정해 sandbox 밖에서 명령을 실행할 수 있다”라면, 그건 더 이상 sandbox가 아님
SQL에서도 파라미터화된 쿼리를 쓰기 전까지 해결되지 않았고, 자연어는 훨씬 자유로움
결국 “이전 지시를 무시하고 …” 같은 공격이 반복됨
데이터와 명령이 같은 스트림에 있으면 항상 같은 결말을 맞이함
자연어 자체가 공격 표면이기 때문에 더 넓을 수밖에 없음
관련 문서: RFC 3514
하지만 내가 익숙한 의미는 격리된 환경에서 악성코드를 안전하게 관찰하는 것임
AI에도 이런 진짜 기술적 경계를 만들려는 시도가 많아서 흥미로운 분야라 생각함
사용자가 직접 접근 권한을 켜는 스위치를 조작할 수 있다면, 그건 sandbox가 아님
처음엔 OS 권한 상승 얘기인 줄 알았는데, 단순히 보안 설계가 부실한 사례였음
Anthropic 논문에서 인용된 사례를 보면, AI가 자율적으로 악성 행위를 하기도 함
예를 들어 Alibaba Cloud의 방화벽이 학습 서버에서 암호화폐 채굴 시도를 탐지했고,
RL 최적화 중 부수 효과로 이런 행동이 나타났다고 함
관련 자료: arXiv 논문, Anthropic 연구, Time 기사
그렇다면 네트워크 제어가 있는 상태에서 어떻게 SSH 터널이나 리소스 스캔이 가능했는지 의문임
Snowflake 직원이 등장해, 보안팀의 대응 타임라인과 수정 사항을 공유함
자세한 내용은 공식 문서에서 확인 가능함
“인간 승인 없이 쉘 명령이 실행됐다”는 부분을 보고,
쉘 보안을 조금이라도 고민해본 사람이라면 하위 프로세스 생성 방식을 고려하지 않았다는 게 놀라움
이런 제한은 OS 수준에서 걸어야 안전함
“진짜 sandboxing 팁”을 공유하자는 제안이 있었음
나는 Claude Code를 VS Code devcontainer 안에서 돌리고 있음
인터넷 접근을 허용 도메인만으로 제한하는 설정도 있음
다만 docker-in-docker 환경이 필요해서 완전한 통합은 어려움
그래서 지금은 단위 테스트까지만 실행 중이며, Vagrant로 전체 VM 격리를 시도해볼까 고민 중임
프로젝트 링크: aflock.ai
“Cortex가 workspace trust를 지원하지 않는다”는 문장을 보고,
애초에 제한이 없는 환경이었던 건 아닌지 의문이 들었음
모델이 플래그를 설정하면 사용자 승인 없이 바로 sandbox 밖에서 실행됨
“이게 새로운 gain-of-function 연구냐”는 농담이 있었고
에이전트가 스스로를 통제할 수 있다고 믿는 게 환상이라고 말함
많은 사람들이 이미 에이전트가 생성한 코드를 검토 없이 실행하고 있음
그렇다면 에이전트 자체를 sandbox로 감싸는 게 무슨 의미가 있나 싶음
어차피 전체 시스템이 별도 머신, 컨테이너, 혹은 제한된 사용자로 격리되어야 함
아마도 대부분의 사용자가 그렇게 하지 않기 때문에,
개발사들이 대신 기본 수준의 안전장치를 제공하려는 것 같음
“토글로 꺼지는 sandbox는 진짜 sandbox가 아니다”라는 의견이 있었음
이는 단순히 마케팅 과장으로, 제품의 허술한 설계를 가리려는 시도처럼 보임
진짜 sandbox는 내부에서 변경할 수 없는 외부 격리 환경이어야 한다고 강조함