웹 자료를 읽던 코딩 에이전트가 작업 폴더의 파일을 바꾸라는 문장을 발견했다. 사용자가 내린 명령이 아니라, 가져온 웹페이지 안에 들어 있던 문장이었다. 2026년 8월 Reddit에 올라온 공개 사용자 보고에서는 에이전트가 그 지시를 거절했지만, 사용자는 작업을 멈추고 상황부터 확인했다.

이 사례의 사실 관계를 여기서 단정할 필요는 없다. 눈여겨볼 지점은 따로 있다. AI 에이전트는 사용자의 요청뿐 아니라 웹페이지, 파일, 메일, 도구 결과도 같은 작업 맥락에서 읽는다. 외부 자료 속 문장이 명령처럼 끼어들면, 원래 요청과 다른 행동으로 흐를 여지가 생긴다.

사용자 요청은 의도 확인을 거쳐 최소 권한 작업으로 이어지고 외부 자료의 숨은 지시는 중간에 차단되는 흐름.

그림에서 외부 자료는 에이전트가 읽어야 할 데이터다. 그 안에 적힌 문장이 새로운 권한을 주지는 않는다. 사용자 의도를 먼저 확인하고, 허용된 범위 안에서만 행동으로 이어져야 한다.

간접 프롬프트 인젝션은 밖에서 들어온다

OpenAI의 설명은 프롬프트 인젝션을 제3자가 대화 맥락에 악성 지시를 끼워 넣어, 모델이 사용자가 요청하지 않은 일을 하도록 속이는 공격으로 정의한다.

사용자가 채팅창에 직접 공격 문구를 넣는 방식도 있다. AI 에이전트에서는 간접 프롬프트 인젝션을 더 자주 경계해야 한다. 다음처럼 작업에 필요한 자료를 읽는 순간 공격 문장이 함께 들어오기 때문이다.

  • 검색 결과와 웹페이지
  • 저장소의 README와 issue
  • 내려받은 문서와 이미지
  • 메일과 채팅 기록
  • MCP 서버나 다른 도구가 돌려준 결과

외부 자료에 이전 지시를 무시하라처럼 노골적인 문장이 있어야만 공격이 되는 것은 아니다. OWASP의 Prompt Injection 항목은 사람이 알아보기 어려운 문장이나 이미지 속 요소도 모델이 읽으면 영향을 준다고 설명한다.

따라서 문장 모양만 보고 안전 여부를 가르기는 어렵다. 웹페이지의 안내문처럼 보이거나, 업무 절차와 섞이거나, 정상적인 도구 출력 뒤에 붙기도 한다.

챗봇보다 에이전트에서 더 위험한 이유

챗봇이 잘못된 답을 하면 대화 안에서 끝날 때가 많다. 에이전트는 파일을 고치고, 명령을 실행하고, 메일을 보내고, 외부 서비스에 자료를 올리기도 한다. 잘못 읽은 문장이 실제 행동으로 이어지는 통로가 생긴다.

OpenAI의 에이전트 보안 설계 글은 이 구조를 source와 sink로 나눠 본다. 웹페이지나 도구 결과처럼 공격자가 영향을 줄 입력이 source다. 파일 수정, 링크 열기, 정보 전송, 도구 호출처럼 잘못 쓰이면 위험한 기능이 sink다. 둘이 연결될 때 피해가 생긴다.

예를 들어 문서를 요약하는 에이전트가 읽기 권한만 가진다면 공격이 답변을 흐리는 데 그칠 가능성이 크다. 같은 에이전트가 작업 폴더 쓰기와 외부 네트워크 권한까지 가지면 파일 손상이나 자료 유출로 번진다.

그래서 안전 대책을 “악성 문장을 완벽하게 찾아내기” 하나에 맡기면 부족하다. OpenAI는 입력 필터만으로는 사람을 속이는 설명과 정상 문장을 완벽하게 가르기 어렵다고 지적한다. Anthropic의 브라우저 에이전트 연구도 어떤 브라우저 에이전트도 프롬프트 인젝션에 면역이라고 볼 수 없다고 밝힌다.

외부 자료는 명령이 아니라 데이터로 둔다

첫 경계는 에이전트가 무엇을 믿어야 하는지 분리하는 데서 시작한다.

사용자 요청은 작업의 목적과 범위를 정한다. 웹페이지와 파일은 그 목적을 이루기 위해 읽는 자료다. 외부 자료에 새로운 목표, 권한 확대, 다른 서비스로의 전송 지시가 적혀 있어도 곧바로 따를 근거가 되지 않는다.

작업 지시를 줄 때도 범위를 좁히면 판단 기준이 선명해진다.

넓은 요청
이 저장소를 살펴보고 필요한 조치를 모두 해줘.

좁은 요청
공개 문서 세 개를 읽고 차이만 요약해줘.
파일 수정, 명령 실행, 외부 전송은 하지 마.

두 번째 요청에서는 외부 문장이 행동을 넓히려 할 때 원래 범위와 충돌한다는 사실이 드러난다. OpenAI의 사용자 안전 안내도 넓은 재량을 주기보다 구체적인 일을 요청하라고 권한다.

읽기와 실행 사이에 멈춤 지점을 둔다

자료 조사와 상태 변경을 한 번에 맡기면, 에이전트가 읽은 내용이 곧바로 행동의 이유가 된다. 다음처럼 단계를 나누면 사람이 중간 결과를 확인한다.

  1. 외부 자료를 읽고 출처와 핵심 내용만 정리한다.
  2. 자료 속 지시로 보이는 문장을 따로 표시한다.
  3. 필요한 변경과 정확한 대상을 제안한다.
  4. 사람이 승인한 변경만 실행한다.

모든 작업에 확인 창을 붙이라는 말은 아니다. 읽기 전용 검색이나 로컬 요약은 낮은 권한으로 이어가고, 삭제·전송·게시·결제처럼 되돌리기 어렵거나 밖에 영향을 주는 행동에서 멈추면 된다.

MCP 규격도 도구가 임의의 데이터 접근과 코드 실행 경로를 연다고 경고한다. MCP 보안 원칙은 도구 설명까지 신뢰할 수 없는 입력으로 보고, 호출 전에 사용자가 행동과 공유할 자료를 이해하고 승인해야 한다고 적는다.

최소 권한은 공격이 성공해도 피해를 줄인다

모델이 공격 문장을 놓칠 가능성은 남는다. 그때를 대비하는 장치가 실행 환경의 경계다.

  • 조사 작업은 먼저 읽기 전용으로 연다.
  • 쓰기가 필요하면 허용할 폴더와 파일을 좁힌다.
  • 비밀 정보가 든 경로는 작업 환경에서 보이지 않게 한다.
  • 외부 네트워크는 필요한 목적지와 동작만 허용한다.
  • 삭제와 전송 같은 행동은 정확한 대상 확인을 거친다.

Anthropic의 에이전트 격리 사례는 모델의 판단만 믿지 않고 파일과 네트워크 경계를 먼저 두는 이유를 설명한다. 허용된 도메인도 파일 업로드 같은 여러 기능을 품고 있으므로, 도메인 이름만 믿는 목록은 충분하지 않았다.

OpenAI 역시 링크를 이용한 정보 유출 방어에서 유명한 사이트인지보다 에이전트가 열려는 정확한 URL이 안전한지 확인한다. 정상 도메인의 redirect나 쿼리 문자열도 정보가 빠져나가는 통로가 될 수 있기 때문이다.

실행 직전에 네 가지를 묻는다

에이전트가 외부 자료를 읽은 뒤 파일 수정이나 도구 호출을 제안한다면 다음 질문을 확인하면 된다.

  • 이 행동은 내가 직접 요청한 범위 안에 있는가?
  • 근거가 사용자 요청인가, 외부 자료 속 문장인가?
  • 읽기 전용으로 같은 목적을 먼저 달성할 방법이 있는가?
  • 실행 대상과 외부로 나갈 정보가 화면에 정확히 보이는가?

하나라도 답하기 어렵다면 바로 실행하지 말고 결과와 제안을 분리한다. 에이전트에게 의심스러운 문장을 표시하게 하는 것은 도움이 되지만, 최종 안전장치는 실제 권한과 승인 경계다.

숨은 지시를 찾는 것보다 행동 범위를 줄인다

프롬프트 인젝션은 문장 하나를 금지하면 끝나는 문제가 아니다. 모델이 웹과 파일을 읽는 한 외부 자료는 계속 작업 맥락에 들어온다. 공격 방식도 제품의 방어와 함께 바뀐다.

바뀐 판단은 단순하다. “에이전트가 공격을 알아볼까?”만 묻지 않고, “못 알아봐도 어디까지 할 수 있나?”를 함께 묻는다. 외부 자료는 낮은 신뢰의 데이터로 두고, 읽기와 실행을 나누고, 쓰기와 외부 전송에 최소 권한과 사람 확인을 겹친다.

완벽한 탐지보다 피해 범위를 작게 설계하는 쪽이 오래 간다. 에이전트가 더 많은 도구를 쓰게 될수록 이 경계는 덜 중요해지는 것이 아니라 더 중요해진다.

AI 코딩 도구가 코드를 검사하는 보안 기능과 프롬프트 인젝션의 차이가 궁금하다면 Claude Code Security는 무엇을 검사할까?를 함께 읽어도 좋다.

확인한 공식·원 자료

아래 자료는 2026년 8월 22일에 확인했다.