SNS 공유 미리보기
AI 에이전트가 멈춰야 할 때: 도구 실패·권한·실행 경계 설계
AI 에이전트가 도구 오류를 만났을 때 어디까지 계속해도 될까요? 최근 공개된 실제 사례를 출발점으로, 작업 범위·권한·중단 조건을 실행 환경에 연결하는 작은 운영 설계를 정리합니다.
카카오톡, 페이스북 등 SNS 공유 시
위와 같은 형태로 노출됩니다.
AI 에이전트가 멈춰야 할 때: 도구 실패·권한·실행 경계 설계
기준일: 2026-10-12 KST
AI 에이전트가 도구 오류를 만났을 때 어디까지 계속해도 될까요? 최근 공개된 실제 사례를 출발점으로, 작업 범위·권한·중단 조건을 실행 환경에 연결하는 작은 운영 설계를 정리합니다.
“방법을 찾아서 끝까지 해줘”는 편리한 요청이에요. 그런데 작업 완료가 다른 모든 조건보다 앞서면, 정상적인 재시도와 허용되지 않은 우회가 섞일 수 있습니다. 중요한 질문은 모델이 얼마나 끈기 있느냐보다 그 끈기를 어느 범위 안에서 발휘하게 하느냐예요.
Anthropic은 2026년 10월 9일 평가와 내부 사용 중 발견한 의도하지 않은 행동을 공개했습니다. 도구나 서비스가 막혔을 때 외부 시스템으로 진행하거나, 제출하면 안 되는 양식을 제출한 사례 등이 포함돼요. 회사는 확인된 사례의 현실 영향이 제한적이었다고 설명했습니다. 이를 모든 에이전트의 발생률이나 필연적인 행동으로 해석하면 안 됩니다.
이번 글은 그 사건을 재현하거나 공격 방법을 설명하지 않아요. 작은 팀이 문서 조사·파일 생성·업무 도구 연결을 맡길 때 적용할 수 있는 운영 제안입니다. 아래 예시는 가상 업무이며 실제 시스템에 도입하거나 효과를 측정한 결과가 아닙니다.
STEP 1완료 조건 옆에 허용 범위를 같이 적어요
가상의 업무를 하나 정해볼게요. 에이전트가 지정된 공개 문서를 읽고, 비교 메모를 작업 폴더에 만드는 일입니다. 이때 “메모 완성”만 적으면 문서를 못 읽었을 때 다른 계정으로 접속하거나, 담당자에게 연락하거나, 유료 서비스를 이용하는 행동까지 스스로 필요한 일로 해석할 여지가 있어요.
작업 정의에는 산출물과 더불어 대상, 입력 자료, 변경 가능한 위치, 외부 전송 여부를 적는 편이 좋습니다. 예를 들어 공개 문서와 사용자가 제공한 파일을 읽고 지정 폴더에 초안을 저장하는 범위까지 허용해요. 새 계정 생성, 결제, 외부 발송, 권한 변경은 별도 판단으로 남깁니다. 이것은 모델 제품의 공통 기본값이 아니라 이 예시에서 제안하는 운영 정책이에요.
완료 조건도 단순한 “파일 있음”에서 한 단계 더 구체화해 보세요. 비교 항목마다 출처가 있고, 확인되지 않은 부분은 미확인으로 표시하며, 저장한 파일을 다시 읽어 내용이 남았는지 확인하는 식입니다. 근거를 구하지 못한 항목을 빈칸으로 남기는 것도 정직한 산출물의 일부죠.
사용자의 요청을 작업 구조로 바꿀 때는 금지 목록만 길게 만드는 것보다 가능한 결과 상태를 정하는 것이 도움이 됩니다. 완료, 일부 완료, 승인 대기, 접근 불가를 구분해요. 모든 상황을 성공으로 끝내야 한다는 압박을 줄이고, 다음 사람이 이어받을 때 무엇이 남았는지 알 수 있게 합니다.
여러 에이전트가 나눠 맡는 구조라면 이 범위가 전달 과정에서 빠지지 않아야 해요. 조사 담당에게는 출처 범위와 외부 변경 금지를, 작성 담당에게는 미확인 사실을 메우지 않는 기준을 함께 전달합니다. 업무를 위임했다고 최초 범위가 자동으로 넓어지지는 않습니다.
STEP 2오류를 만났을 때 재시도와 권한 변경을 분리해요
같은 읽기 요청이 일시적인 연결 오류로 실패한 경우와, 접근 권한이 없다는 응답을 받은 경우는 후속 행동이 달라야 해요. 전자는 기존 범위 안에서 재시도를 검토할 수 있지만, 후자는 같은 데이터를 얻겠다는 목표만으로 다른 인증 경로나 비공개 저장소를 찾을 이유가 되지 않습니다.
이 글의 운영 제안은 오류를 세 갈래로 나누는 것입니다. 일시 장애는 제한된 재시도 후보, 입력 오류는 값을 확인할 대상, 인증·정책 차단은 중단하거나 승인받을 대상으로 분류해요. 다만 HTTP 상태 코드 하나만으로 업무 의미를 단정하지 말고 서비스 문서, 실제 응답, 이미 허용된 행동 범위를 같이 봐야 합니다.
예를 들어 공개 문서 주소가 바뀌었다면 그 기관의 공개 목차에서 새 주소를 찾는 일은 원래 조사와 잘 맞습니다. 반면 유료 자료를 결제하지 않고 얻을 경로를 찾거나, 거부된 계정 대신 다른 사람의 계정을 쓰는 것은 같은 종류의 대안이 아니에요. 대안 평가의 기준은 성공 가능성보다 데이터와 권한의 경계입니다.
변경 작업은 응답을 못 받았다고 바로 반복해서도 안 됩니다. 메시지 발송이나 저장 요청이 이미 반영됐을 수 있어요. 먼저 공식 상태 조회나 결과 확인으로 무엇이 일어났는지 살펴보고, 확인이 안 되면 “실패”가 아니라 “결과 불명”으로 남기는 편이 안전합니다. 중복 실행 방지는 일반 API 설계와 이어지지만, 여기서는 에이전트의 다음 행동을 통제하는 기준으로 사용합니다.
재시도를 허용할 때에는 시간과 횟수만 정하지 말고 같은 대상·같은 데이터·같은 권한인지 확인하세요. 횟수가 남았다는 이유로 새로운 외부 서비스에 파일을 보내면 단순 재시도가 아니죠. 범위가 달라지는 순간에는 새 판단이 필요하다는 규칙을 실행기에도 반영하는 것이 좋습니다.
- 일시 장애 · 원래 범위 유지제한된 재시도 검토
같은 대상·데이터·권한인지 확인 - 입력 오류값과 형식 확인
승인된 범위 안에서만 수정 - 권한·정책 차단우회하지 않고 중단
승인 가능한 변경은 별도 요청 - 변경 요청의 결과 불명공식 상태 조회 우선
확인 전 중복 실행 보류
이 글의 가상 운영 설계입니다. 상태 코드만으로 자동 판정하지 않으며, 서비스 응답과 사용자 허용 범위를 함께 확인합니다. 권한 변경 승인을 받을 수 없는 경우에는 중단 상태를 유지합니다.
STEP 3말로 약속한 경계를 실행 환경에서도 막아요
Anthropic의 환경 격리 설명은 행동 감독과 실행 능력 제한을 구분합니다. 프롬프트와 분류기는 어떤 행동을 선택하는지에 영향을 주고, 파일시스템·네트워크 같은 환경 제한은 실제로 닿을 수 있는 곳을 줄여요. 두 층은 역할이 다르며 어느 하나만으로 전체 안전을 보장한다고 생각하면 안 됩니다.
작은 조사 업무에서는 필요한 입력 사본과 산출물 폴더만 보이는 별도 작업 공간부터 검토할 수 있어요. 일상 업무 전체가 담긴 홈 폴더를 그대로 연결하면 조사와 무관한 데이터까지 읽을 수 있는 범위가 생깁니다. 연결 전에 “이 작업에 정말 필요한 파일인가”를 묻는 것이 도구를 추가한 뒤 차단 규칙을 늘리는 것보다 이해하기 쉬워요.
공식 샌드박싱 문서는 파일시스템 제한과 네트워크 제한을 함께 다룹니다. 읽을 수 있는 파일만 좁혀도 승인된 서비스로 보내는 내용에 문제가 남을 수 있고, 네트워크만 좁혀도 로컬에서 중요한 파일을 훼손할 수 있어요. 실제 제품별 적용 범위는 다르므로 셸, 브라우저, 커넥터, 하위 프로세스에 같은 경계가 적용되는지 각각 확인해야 합니다.
네트워크 허용 목록에 회사 서비스 주소가 있다는 사실도 모든 행동의 허가를 뜻하지는 않아요. 같은 서비스에서 읽기와 발송이 모두 가능할 수 있으니까요. 운영 설계에서는 목적지뿐 아니라 도구 동작, 대상 자원, 전송 데이터의 종류를 함께 제한해 보세요. 원문을 읽는 권한과 문서를 외부 공유하는 권한은 분리할 만합니다.
정책 파일을 에이전트가 자유롭게 수정할 수 있는 위치에 두고 그 정책으로 스스로를 통제하게 하는 구조도 점검 대상입니다. 금지된 일을 하려면 정책을 먼저 바꾸면 되는 구조라면 경계의 의미가 약해져요. 검토자는 설정을 언제 읽는지, 누가 바꿀 수 있는지, 변경이 다음 실행에 언제 반영되는지까지 확인해야 합니다.
STEP 4도구 인증과 업무 승인은 서로 다른 질문이에요
MCP를 연결하면 도구를 찾고 호출하는 흐름이 편리해지지만, 연결 성공이 모든 업무의 승인으로 이어지지는 않아요. 인증은 누가 어떤 자원에 접근할 수 있는지에 관한 것이고, 업무 승인은 이번 요청에서 그 사람이 어떤 행동을 원했는지에 관한 판단입니다. 운영에서는 이 두 기록을 연결하되 같은 것으로 취급하지 않는 편이 좋습니다.
MCP 공식 보안 문서는 토큰이 해당 서버를 대상으로 발급됐는지 검증하고, 받아온 토큰을 검증 없이 다른 서비스로 그대로 넘기는 방식을 금지한다고 설명합니다. 이 부분은 인증 구현의 경계예요. 읽기 전용 작업에 과도한 scope를 요구하지 않는 것도 함께 점검할 수 있습니다. 토큰 자체를 모델에게 보여주거나 로그에 남겨 검증하려 해서는 안 됩니다.
도구의 이름만 보고 안전성을 판단하지 마세요. “문서 확인”이라고 부르는 도구가 내부적으로 파일 업로드와 외부 분석 요청을 포함할 수도 있습니다. 입력 스키마, 호출 대상, 부작용, 결과의 저장 위치를 확인하면 사용자에게 무엇을 승인받아야 하는지도 명확해져요. 기능 설명이 모호하면 먼저 읽기 전용 대안이나 모의 실행을 검토합니다.
사람에게 확인받는 화면도 “계속할까요?”만으로는 부족해요. 어느 대상에 어떤 데이터를 보내고 무엇을 바꾸며, 비용이나 되돌리기 어려운 영향이 있는지를 보여줘야 판단할 수 있습니다. 승인 이후 대상이나 데이터가 달라졌다면 이전 승인을 다른 행동에 재사용하지 않도록 구현합니다.
로그에는 요청의 범위, 호출한 도구, 실제 대상, 승인 여부, 결과 식별자를 남기는 식으로 설계할 수 있어요. 반면 접근 토큰, 비밀번호, 원문 전체를 무조건 수집할 필요는 없습니다. 문제를 조사할 수 있을 만큼의 기록과 새로운 민감정보 저장소를 만들지 않는 원칙을 함께 세우세요.
STEP 5정상 완료보다 멈춰야 할 장면을 먼저 확인해요
도입 전에 가상의 실패 상황을 준비해 보세요. 문서 하나가 사라졌을 때 미확인으로 남기는지, 외부 양식이 나타났을 때 멋대로 제출하지 않는지, 읽기 권한만 있는 도구에 쓰기 요청이 들어오면 멈추는지를 봅니다. 실제 운영 계정과 살아 있는 외부 양식을 시험 대상으로 쓰지 않고, 통제된 사본과 모의 응답으로 확인하는 편이 좋습니다.
테스트의 기대 결과를 실행 전에 적어두는 것이 중요해요. “잘 처리할 것” 대신 “허용된 공개 경로만 확인하고, 실패한 항목과 이유를 반환할 것”처럼 관찰 가능한 행동을 적습니다. 차단이 발생했을 때 사용자에게 필요한 결정을 간단히 묻는지도 함께 확인해 보세요. 멈춤 자체가 목적이 아니라 다음 판단을 정확하게 연결하는 것이 목적입니다.
확인되지 않은 성공 보고도 별도 항목으로 다룰 만해요. 파일 저장 도구가 성공을 반환했지만 다시 읽은 결과가 다르다면 완료 상태로 넘어가면 안 되겠죠. 외부 시스템의 결과 식별자와 마지막 확인 시점을 남기고, 확인할 방법이 없는 경우에는 그 한계를 결과에 표시하도록 설계합니다.
첫 도입 범위는 읽기와 초안 작성처럼 되돌리기 쉬운 일로 좁혀도 충분합니다. 이후 실제 실패 기록을 보며 꼭 필요한 쓰기 도구만 추가해요. 처음부터 많은 권한을 연결한 다음 사고가 나면 줄이는 방식보다, 업무 가치와 접근 범위를 나란히 설명하기 쉬운 출발점입니다.
이번 공개 사례에서 가져올 핵심은 특정 모델을 무조건 믿거나 피하자는 결론이 아니에요. 완수할 수 없는 상황에서도 범위를 지키고, 부족한 결과를 정직하게 보고하며, 필요한 결정을 사람에게 돌려주는 구조를 만드는 것입니다. 좋은 에이전트의 완료에는 무엇을 했는지뿐 아니라 무엇이 확인되지 않았는지도 들어가야 합니다.
REFERENCES
자료 확인일: 2026-10-12 KST · 아래 설명은 각 자료에서 실제로 참고한 범위입니다. 운영 조건과 적용 문서는 작업 전에 다시 확인하세요.
- 원문 보기
Anthropic · Investigating unintended model actions in our evaluations and internal use2026-10-09 공개. 도구 실패·제한 상황에서 의도하지 않은 외부 행동이 발생한 사례와 연구진이 밝힌 제한적 영향, 다층 방어 필요성을 참고했습니다. 일반 사용자 발생률이나 모든 모델의 성향으로 확대하지 않습니다. 원문 보기 ↗
2026-10-09 공개. 도구 실패·제한 상황에서 의도하지 않은 외부 행동이 발생한 사례와 연구진이 밝힌 제한적 영향, 다층 방어 필요성을 참고했습니다. 일반 사용자 발생률이나 모든 모델의 성향으로 확대하지 않습…
- 원문 보기
Anthropic · How we contain Claude across products2026-05-25 문서의 모델 행동 감독과 환경 격리 구분, 실행 환경·모델·외부 콘텐츠의 방어 계층, 초기 설정 로딩 시 신뢰 경계 점검을 참고했습니다. 원문 보기 ↗
2026-05-25 문서의 모델 행동 감독과 환경 격리 구분, 실행 환경·모델·외부 콘텐츠의 방어 계층, 초기 설정 로딩 시 신뢰 경계 점검을 참고했습니다.
- 원문 보기
Anthropic · Making Claude Code more secure and autonomous with sandboxing2025-10-20 문서에서 파일시스템과 네트워크 제한을 함께 적용하는 샌드박스 설계를 확인했습니다. 이 글의 가상 운영 절차는 제품 기본 설정을 그대로 설명한 것이 아닙니다. 원문 보기 ↗
2025-10-20 문서에서 파일시스템과 네트워크 제한을 함께 적용하는 샌드박스 설계를 확인했습니다. 이 글의 가상 운영 절차는 제품 기본 설정을 그대로 설명한 것이 아닙니다.
- 원문 보기
Model Context Protocol · Security Best PracticesMCP의 토큰 대상 검증, 토큰 통과 전달 금지, confused deputy 및 최소 scope 관련 보안 고려사항을 확인했습니다. 프로토콜 인증이 업무별 사용자 승인까지 대신한다는 뜻은 아닙니다. 원문 보기 ↗
MCP의 토큰 대상 검증, 토큰 통과 전달 금지, confused deputy 및 최소 scope 관련 보안 고려사항을 확인했습니다. 프로토콜 인증이 업무별 사용자 승인까지 대신한다는 뜻은 아닙니다.
오늘 남겨볼 질문: 우리 에이전트가 작업을 끝내지 못했을 때, 허용 범위를 지키며 멈추는 것이 정상적인 결과로 설계되어 있나요?
