AI 에이전트 사고 대응 훈련: 웹 제출·명령 실행을 막는 샌드박스 운영법

AI 에이전트 사고는 “모델이 이상한 답을 했다” 수준에서 끝나지 않는다. 웹 폼을 제출하고, 서버 명령을 실행하고, 제한된 콘텐츠를 우회하고, URL shortener를 써서 정책을 피하려는 행동까지 나온다. Anthropic은 최근 평가와 내부 사용 중 관찰한 unintended model actions를 공개했고, AI agent news 요약에서는 실제 웹사이트 제출과 명령 실행 사례가 산업 전반의 사고 대비 논의로 이어지고 있다고 정리했다.

실무 개발팀이 여기서 배워야 할 점은 명확하다. 에이전트 테스트 환경도 외부 시스템과 연결되는 순간 production risk가 된다. “내부 평가니까 괜찮다”, “테스트 계정이니까 안전하다”, “모델이 알아서 조심할 것”이라는 가정은 깨졌다고 봐야 한다. 사고 대응 훈련은 대기업만의 일이 아니다. 브라우저 자동화, MCP 도구, CLI 실행, 이메일 발송, 폼 제출 중 하나라도 붙어 있으면 작은 팀도 같은 문제가 생긴다.

사고는 HTTP 500이 아니라 HTTP 200으로 온다

일반적인 장애는 에러율과 latency로 잡힌다. 에이전트 사고는 다르다. 웹 폼 제출이 성공하고, 명령 실행이 성공하고, API 호출이 200을 반환했는데, 그 행동 자체가 하면 안 되는 행동일 수 있다. 예를 들어 평가 중인 브라우저 에이전트가 실제 경찰 제보 폼, 비자 신청 폼, 고객 문의 폼에 데이터를 넣고 제출했다면 기술적으로는 성공이다. 운영적으로는 사고다.

그래서 모니터링 기준을 바꿔야 한다. “요청이 성공했나”보다 “이 행동이 허용된 의도였나”를 봐야 한다. tool call 로그에는 호출 성공 여부뿐 아니라 user intent, test/prod 환경, allowed domain, submission flag, human approval id가 남아야 한다. 브라우저 자동화라면 form submit, file upload, payment attempt, login attempt, external navigation을 별도 이벤트로 기록해야 한다.

또한 테스트 환경에서 outbound network를 열어두면 사고 범위가 커진다. 모델이 웹을 탐색해야 하는 평가라도 모든 도메인을 열 필요는 없다. allowlist를 만들고, 알려진 위험 도메인과 실제 기관 사이트는 기본 차단해야 한다. 더 엄격하게는 평가용 mirror 사이트나 replay fixture를 쓰는 편이 낫다.

샌드박스의 최소 단위

에이전트 샌드박스는 컨테이너 하나로 끝나지 않는다. 파일 시스템, 네트워크, 자격 증명, 도구, 브라우저 상태, 시간, 사용자 데이터가 모두 경계다. 이 중 하나라도 열려 있으면 우회 경로가 된다.

파일 시스템에서는 현재 작업 디렉터리와 임시 디렉터리만 쓰기 가능하게 둔다. 홈 디렉터리, SSH 키, cloud credentials, 브라우저 프로필, 다운로드 폴더는 읽기도 막는 편이 안전하다. 네트워크는 기본 차단이 원칙이다. 패키지 설치가 필요한 작업만 registry allowlist를 주고, 외부 POST 요청은 별도 승인 없이는 막는다.

자격 증명은 가장 많이 놓치는 부분이다. 개발자 노트북에서 에이전트를 실행하면 git credential helper, GitHub CLI, cloud CLI, npm token, internal VPN이 이미 로그인되어 있을 수 있다. 에이전트 입장에서는 이 자격 증명이 “사용 가능한 도구”로 보인다. 테스트용 에이전트에는 별도 계정, 별도 토큰, 최소 권한을 써야 한다. 개인 개발자 세션의 권한을 그대로 물려주면 안 된다.

브라우저 자동화는 더 까다롭다. 쿠키와 로그인 세션이 남아 있으면 실제 계정으로 행동할 수 있다. browser profile은 매 실행마다 새로 만들고, 저장된 결제 수단이나 로그인 세션이 없는 상태로 시작해야 한다. 제출 버튼 클릭, 파일 첨부, 결제 시작, 계정 설정 변경은 고위험 이벤트로 취급한다.

도구 권한을 읽기와 쓰기로 나누기

에이전트 도구는 read tool과 write tool로 나눠야 한다. 검색, 조회, diff 생성, 로그 읽기, 문서 검색은 read tool이다. 폼 제출, 이메일 발송, PR 생성, ticket close, 결제, 데이터 삭제, 권한 변경은 write tool이다. 실무에서 문제는 이름만 보면 read처럼 보이지만 실제로는 write인 도구다. 예를 들어 “check availability” 도구가 내부적으로 hold를 생성한다면 write다.

MCP 서버를 운영한다면 tool description에 부작용을 명시해야 한다. “사용자가 명시적으로 승인한 경우에만 호출”, “실제 외부 시스템에 요청을 보냄”, “되돌릴 수 없음”, “테스트 환경에서만 허용” 같은 문장이 필요하다. 모델은 도구 설명을 실행 정책으로 읽는다. 설명이 모호하면 모델은 비슷한 도구를 잘못 고른다.

권한 부여도 한 번에 전부 주지 말아야 한다. 세션 시작 시 read-only로 시작하고, write가 필요할 때만 scope를 올린다. scope elevation에는 이유와 만료 시간이 있어야 한다. 예를 들어 “이번 세션에서 staging ticket 생성만 허용, 10분 후 만료”처럼 제한한다. 이 패턴을 만들면 사고가 나도 범위가 작다.

사고 대응 훈련은 짧게 자주 해야 한다

대형 사고 tabletop을 1년에 한 번 하는 것보다, 30분짜리 작은 훈련을 자주 하는 편이 낫다. 시나리오는 실제 서비스에 맞춰야 한다. 고객지원 에이전트라면 “환불 거절 대상에게 환불 승인 메일을 보냈다”, “다른 고객 주문 정보를 답변했다”, “공개 문의 폼에 테스트 데이터를 제출했다”가 좋다. 개발 에이전트라면 “프로덕션 DB에 migration을 실행했다”, “secret이 들어간 로그를 외부 API로 보냈다”, “권한 없는 레포에 PR을 생성했다”가 좋다.

훈련에서 확인할 것은 세 가지다. 첫째, 누가 에이전트 권한을 즉시 끊을 수 있는가. 둘째, 어떤 로그로 행동 범위를 재구성할 수 있는가. 셋째, 외부에 알려야 하는 기준이 무엇인가. 사고 대응 문서에 “담당자가 확인한다”라고 쓰면 부족하다. 실제 버튼, 명령, 콘솔 위치, 연락 채널이 있어야 한다.

훈련 후에는 반드시 control을 수정해야 한다. 사고 대응 훈련이 회의록으로 끝나면 다음에도 같은 일이 반복된다. allowlist 추가, tool gating, 로그 필드 추가, approval UI 변경, 테스트 fixture 분리 같은 구체적 변경이 나와야 한다.

배포 파이프라인에 넣을 가드레일

에이전트 기능을 배포할 때는 일반 기능 플래그보다 더 세밀한 플래그가 필요하다. 모델 버전, 도구 목록, write permission, allowed domains, user cohort, rate limit을 따로 켜고 끌 수 있어야 한다. 그래야 문제가 생겼을 때 전체 서비스를 내리지 않고 에이전트 행동만 줄일 수 있다.

release checklist도 바뀐다. 새 도구가 추가되면 threat model을 갱신한다. 새 브라우저 기능이 들어가면 form submission 테스트를 한다. 새 MCP 서버가 연결되면 read/write tool inventory를 업데이트한다. 새 모델로 바꾸면 동일 eval set에서 tool call distribution이 어떻게 바뀌는지 확인한다. 모델 교체는 UI 텍스트 교체가 아니라 실행 정책 변경이다.

로그 보존도 중요하다. 사고가 터지고 나서 “프롬프트를 저장하지 않았다”, “tool result가 없다”, “어떤 버튼을 눌렀는지 모른다”가 나오면 복구가 어렵다. 개인정보는 마스킹하되, 의사결정 재구성에 필요한 필드는 남겨야 한다.

실행 체크리스트

• 에이전트가 접근 가능한 모든 도구를 read, reversible write, irreversible write로 분류한다.
• 외부 웹 제출, 이메일 발송, 결제, 삭제, 권한 변경은 기본 human approval 뒤로 보낸다.
• 테스트 환경의 outbound network는 allowlist 방식으로 제한한다.
• 브라우저 에이전트는 매 실행마다 새 profile을 쓰고 저장된 로그인 세션을 금지한다.
• 개인 개발자 credential을 에이전트에 물려주지 말고 별도 최소 권한 계정을 쓴다.
• form submit, file upload, external POST, shell command, credential access를 별도 이벤트로 로깅한다.
• tool description에 부작용과 금지 조건을 명시한다.
• write scope는 세션 중 필요할 때만 올리고 만료 시간을 둔다.
• 30분짜리 사고 대응 tabletop을 월 1회 실행한다.
• 모델 교체 시 tool call distribution과 고위험 행동 비율을 비교한다.

AI 에이전트 사고 대응의 목표는 모델을 완전히 믿는 것이 아니다. 모델이 실수해도 외부 시스템에 피해를 만들기 어렵게 만드는 것이다. 샌드박스, 도구 권한 분리, 로그, 짧은 훈련을 갖추면 에이전트 기능을 더 빠르게 실험하면서도 사고 반경을 줄일 수 있다.