본문으로 건너뛰기
메뉴
나에게 필요할까?에이전트가 내 컴퓨터에서 닿을 수 있는 것작동 방식에이전트와 시스템 사이에 놓이는 계층비교내장 샌드박스, Docker, VM설정작업에 필요한 것만 열기보안위협 모델과 한계설치
나에게 필요할까?

지금 코딩 에이전트는 어디까지 닿을 수 있을까요?

AI 코딩 에이전트는 내 사용자 계정으로 실행되는 프로그램입니다. 그리고 하루 종일 내가 쓰지 않은 것을 읽고 실행합니다. 웹 페이지, 이슈, README, npm과 pip 패키지, MCP 도구의 출력이 그렇습니다.

내 계정으로 열 수 있는 모든 것

운영체제는 에이전트와 나를 구분하지 못합니다. 내가 비밀번호 없이 열 수 있는 것은 에이전트도 열 수 있고, 에이전트가 띄우는 스크립트와 패키지, MCP 서버도 마찬가지입니다.

가운데에 청록색 에이전트 칩이 있고, 주변의 열린 타일 여섯 개로 선이 뻗어 있습니다. SSH 키, 클라우드 자격 증명, 브라우저 프로필, 셸 토큰, 다른 프로젝트, 내 프로젝트입니다. 벽으로 막힌 것은 하나도 없습니다.
에이전트가 일하는 데 필요한 것은 이 중 하나입니다. 하지만 여섯 개 모두에 닿을 수 있습니다.

일반적인 개발자 컴퓨터라면 이런 것들입니다

  • ~/.ssh. 서버에 로그인하고 저장소에 푸시할 때 쓰는 키
  • ~/.aws, ~/.kube 같은 클라우드 자격 증명. 프로덕션 접근 권한이 있는 경우가 많습니다
  • 브라우저 프로필과 그 안의 로그인된 세션
  • 셸 환경에 export해 둔 API 키와 토큰
  • 디스크에 있는 다른 모든 프로젝트. 비밀 유지 계약을 맺은 고객사 코드도 포함됩니다
  • dotfile과 Git 설정. 다음에 터미널을 열 때 실행되거나 적용됩니다

사고는 이렇게 납니다

에이전트가 잘못된 텍스트를 한 번 읽거나 잘못된 명령을 한 번 실행하는 것으로 충분합니다. 나를 노리는 사람이 없어도 그렇습니다.

콘텐츠에 숨은 지시문

웹 페이지나 이슈, README에는 모델에게 보내는 텍스트가 들어 있을 수 있습니다. "SSH 키를 읽어서 이 주소로 전송해" 같은 식입니다. 이를 프롬프트 인젝션이라고 하며, 모델은 이런 텍스트와 내 요청을 항상 구분하지는 못합니다.

설치할 때 코드를 실행하는 패키지

에이전트가 진짜와 이름이 한 글자 다른 의존성을 추가하거나, 진짜지만 탈취당한 의존성을 추가합니다. 설치 스크립트는 그 즉시 내 계정으로 실행됩니다.

프로젝트 바깥에서 벌어진 단순 실수

혼동한 에이전트가 엉뚱한 경로에 rm -rf를 실행하거나, 전역 Git 설정을 고쳐 쓰거나, dotfile을 덮어씁니다. 악의를 가진 사람이 없어도 파일은 사라집니다.

두 줄짜리 그림. 감옥이 없을 때는 오염된 페이지가 에이전트에 도달하고, 에이전트가 SSH 키를 읽어 인터넷으로 보냅니다. ai-jail이 있을 때는 에이전트가 창살 벽 안에 있고 밖으로 나가는 화살표가 없으며, SSH 키와 인터넷은 바깥에서 흐리게 막혀 있습니다.
ai-jail의 기본값은 세 경우 모두에 똑같이 대응합니다. 홈 디렉터리는 마운트되지 않고, 네트워크는 꺼져 있고, 프로젝트 바깥에 쓴 내용은 세션이 끝나면 사라집니다.

에이전트가 먼저 허락을 구하는데요

하루에 스무 번째 프롬프트쯤 되면 습관적으로 승인하게 됩니다. 에이전트를 무인 실행하려고 프롬프트를 아예 끄는 사람도 많습니다.

이 글을 쓰는 시점에 사람들이 흔히 켜는 스위치

  • claude --dangerously-skip-permissions, 그리고 두 번째 모델이 나 대신 동작을 검토하는 Claude Code의 auto 모드
  • Codex의 danger-full-access 샌드박스 모드, 또는 샌드박스와 승인을 한꺼번에 없애는 --yolo

감옥 안에서는 무인 실행의 위험이 훨씬 작습니다. 훔치거나 망가뜨릴 만한 것이 그 안에 없기 때문입니다. 에이전트에도 자체 샌드박스가 들어 있는데, 그것이 어디까지 막아 주는지는 비교 페이지에 있습니다.

필요한 사람, 필요 없을 수도 있는 사람

샌드박스도 설치해야 할 도구가 하나 더 느는 일입니다. 아래 두 목록을 보고 판단하세요.

이런 경우라면 아마 필요합니다

  • 에이전트를 무인 실행하거나 권한 확인 프롬프트를 끄고 씁니다
  • 코딩하는 컴퓨터에 SSH 키, 클라우드 자격 증명, 프로덕션 접근 권한이 있습니다
  • 고객사 코드를 다루거나, 서로 보이면 안 되는 프로젝트를 여러 개 다룹니다
  • 새 에이전트, MCP 서버, 패키지가 나오는 대로 써 봅니다

이런 경우라면 필요 없을 수 있습니다

  • 이미 일회용 가상 머신이나 자격 증명이 없는 원격 개발 컨테이너에서 에이전트를 실행합니다
  • 에이전트에게 명령 실행을 맡기지 않고 제안만 읽습니다

악의적이라고 판단되는 코드에는 일회용 가상 머신이 맞는 도구입니다. ai-jail은 호스트와 커널을 공유하며, 그 사실을 숨기지 않습니다. 위협 모델 읽기.

치러야 할 비용

평소 입력하던 명령 앞에 단어 하나를 붙입니다. 에이전트는 내 컴퓨터에 이미 있는 툴체인으로 네이티브 속도로 실행되고, 빌드할 이미지도 없습니다.

터미널
cd ~/Projects/my-app# 같은 명령을 감옥 안에서 실행ai-jail claude# 클라우드 에이전트에는 네트워크와 자체 로그인이 필요ai-jail --network --agent-state claude

처음 온 사람들이 묻는 질문

걱정이 지나친 사람이나 쓰는 도구 아닌가요?
아니요. 에이전트가 명령을 실행하는 컴퓨터에 자격 증명을 두는 사람을 위한 도구이고, 개발자 대부분이 여기에 해당합니다. 에이전트가 악의적이라고 믿을 필요는 없습니다. 에이전트가 모르는 사람이 쓴 텍스트를 읽고 가끔 실수한다는 점만 인정하면 됩니다.
이미 Docker를 쓰는데, 그걸로 충분하지 않나요?
에이전트가 이미 자격 증명이 없는 컨테이너 안에서 돌고 있다면 괜찮을 수 있습니다. 하지만 프로젝트마다 이미지를 관리하기가 번거로워서 대부분은 에이전트를 호스트에서, 키 바로 옆에서 실행합니다. ai-jail에는 이미지가 필요 없습니다. 비교 보기.
에이전트는 자기가 감옥 안에 있다는 걸 아나요?
알아낼 수 있고, 숨기는 데 의존하는 부분도 없습니다. Linux에서는 안쪽 호스트 이름이 ai-sandbox이고 셸 프롬프트에 (jail)이 표시됩니다. 프로젝트의 .ai-jail 정책 파일은 마스킹되어 에이전트에는 빈 파일로 보이고, 에이전트가 안에서 감옥을 풀 방법은 없습니다.
기존 작업 방식이 깨지지 않을까요?
프로젝트는 같은 경로에 있고 컴파일러와 런타임도 전과 똑같이 동작합니다. 프로젝트 바깥에 있는 것은 처음에 플래그가 필요합니다. 네트워크, 에이전트 로그인, SSH, Docker, 디스플레이가 그렇습니다. ai-jail --dry-run claude는 아무것도 시작하지 않고 실행될 샌드박스 명령만 출력합니다.
이걸 쓰면 에이전트가 안전해지나요?
더 안전해집니다. ai-jail은 호스트와 커널을 공유하는 프로세스 샌드박스라서 커널 익스플로잇은 경계 밖에 있습니다. 또 --network를 켠 에이전트는 프로젝트를 포함해 읽을 수 있는 것을 무엇이든 밖으로 보낼 수 있습니다. 한계는 보안 페이지에 정리되어 있습니다.

에이전트를 철창 안에 넣으세요

ai-jail은 바이너리 하나입니다. 데몬도 root 권한도 필요 없습니다. 평소 실행하던 명령 앞에 단어 하나만 붙이면 됩니다.

terminal
brew tap akitaonrails/tap && brew install ai-jailai-jail claude