2026 DeepSeek Harness 프롬프트 주입 연구 발표 후 무엇을 해야 하나요?

외부 웹 문서를 읽은 뒤 에이전트가 명령 실행이나 파일 변경까지 시도하고 있습니까?
가장 빠른 해법은 고위험 경로를 즉시 좁히고, 논문 성공률은 전체 배포의 취약점 비율로 해석하지 않는 것입니다.

누가 읽어야 합니까?
웹 페이지, 문서, 로그, 코드 주석을 읽은 뒤 도구를 호출하는 에이전트 개발자에게 필요합니다.
보안 엔지니어는 출처에서 민감한 작업으로 이어지는 통제 지점을 정해야 하며, 기술 책임자는 계속 시험할지 범위를 제한할지 결정해야 합니다.

마지막 업데이트: 2026년 8월 19일. 논문 본문과 버전 기록, 공개 재현 저장소, DeepSeek Harness 저장소와 최신 배포 기록을 대조했습니다.

논문 결과와 실제 배포 판단은 다르게 봐야 합니다

2026년 8월 17일 공개된 DeepSeek Harness 공식 프롬프트 주입 연구 원문은 간접 프롬프트 주입을 통제 환경에서 시험했습니다. 연구에는 통제된 실행 14,560회, 외부 자료 경로 16개, 공격 목적 35개, 공격 방법 12개가 포함되었습니다. 시험 대상은 2026년 8월 13일의 특정 소스 커밋인 47f943859bef였습니다.

연구에서 관찰된 대표 수치는 다음과 같습니다.

• 텍스트 경로의 가짜 완료 공격 성공률은 의미 기반 판정에서 17.0%였습니다.
• 파일 경로의 숨은 유니코드 공격 성공률은 규칙 기반 판정에서 25.5%였습니다.
• 파일로 전달된 Skills 경로에서는 규칙 기반 판정 기준 16.0%가 관찰되었습니다.
• 부분 준수 판정은 의미 기반 판정에서 7.3%, 규칙 기반 판정에서 2.0%였습니다.

이 수치는 연구 본문에 명시된 통제 실행 결과입니다. 실제 전자 우편 발송, 셸 명령 실행, 자금 이동을 뜻하지는 않습니다. 연구의 민감한 도구는 지역 시험용 장치였고, 호출 이름과 인자만 기록했습니다. 따라서 기록된 도구 호출은 실제 외부 효과가 아니라 에이전트가 민감한 행동을 시도했는지를 보여줍니다.

반대로 “안전하다”라고 결론 내릴 수도 없습니다. 공식 생성형 인공지능 보안 안내도 웹 사이트나 파일 같은 외부 자료에 들어간 지시가 모델 행동을 바꿀 수 있으며, 연결된 기능의 비인가 사용이나 명령 실행으로 이어질 수 있다고 설명합니다.

핵심은 모델이 문장을 거부하느냐가 아닙니다. 오염된 자료가 다음 행동과 도구 호출을 바꿀 때 실행 계층이 이를 멈추느냐가 핵심입니다.

발표 당일에는 버전과 시험 경계를 먼저 고정합니다

발표 당일에는 연구 결과를 읽기 전에 자신의 실행 환경을 고정하십시오. 먼저 DeepSeek Harness 공식 저장소에서 현재 소스와 사용 중인 커밋을 확인합니다. 이어 공식 배포 기록에서 v0.1.0-rc.7이 현재 환경에 실제로 적용되었는지 따로 확인해야 합니다.

v0.1.0-rc.7의 공개 시점과 논문 시험 커밋은 같지 않을 수 있습니다. 날짜가 같다는 이유만으로 수정 내용과 기본 권한, 도구 호출 정책이 일치한다고 가정하면 안 됩니다. 다음 항목을 기록하십시오.

• 사용 중인 소스 커밋과 배포 버전
• 모델 백엔드와 모델 이름
• 시스템 지시문과 에이전트 인격
• 등록된 읽기 도구와 민감한 쓰기 도구
• 승인 절차가 모델 판단에만 맡겨졌는지 여부
• Skills, MCP, 파일 변환기의 설치 경로와 소유자

이 기록이 있어야 논문 수치와 현장 재시험 결과를 구분할 수 있습니다. 논문의 공격 성공률은 위험 신호이며, 자신의 배포에 대한 보증이나 확정적인 취약점 비율이 아닙니다.

첫날의 선택은 전면 중단보다 경계 차단입니다

첫날에는 DeepSeek Harness 전체를 끄기보다 외부 자료에서 민감한 도구로 이어지는 자동 경로를 먼저 끊으십시오. 특히 다음 조합은 별도 승인이 없으면 읽기 전용으로 되돌리는 것이 좋습니다.

• 웹 페이지 읽기 → 셸 명령 실행
• 문서 또는 로그 읽기 → 파일 덮어쓰기
• 전자 우편 읽기 → 답장 또는 외부 제출
• Skills 또는 MCP 결과 읽기 → 네트워크 요청
• 코드 주석 읽기 → 배포, 병합, 자격 증명 사용

출처와 작업을 아래처럼 나누면 임시 제한을 빠르게 정할 수 있습니다.

권한 경계를 정리할 때는 물리 맥 환경과 가상 맥 환경 비교처럼 실행 공간과 권한 경계를 함께 확인해야 합니다. 환경을 나누는 것만으로 승인 절차가 완성되지는 않지만, 실제 자격 증명과 시험용 자료를 분리하는 출발점은 될 수 있습니다.

이 단계에서 중요한 것은 경고 문구를 더 길게 쓰는 일이 아닙니다. 모델이 “외부 자료를 믿지 말라”는 지시를 놓쳐도, 승인 계층이 민감한 작업을 멈출 수 있어야 합니다. 오픈 웹 애플리케이션 보안 재단의 에이전트 보안 안내도 외부 자료를 통한 직접 및 간접 주입을 별도 위험으로 다루고, 공격 사례 시험과 배포 전 검증을 권고합니다.

첫 사흘에는 출처 표기와 독립 승인을 붙입니다

외부 자료가 문맥에 들어올 때 최소한 다음 세 가지를 함께 남기십시오.

1. 자료가 어디에서 왔는지 나타내는 출처
2. 신뢰 수준과 검토 상태
3. 자료의 운반 방식인 웹, 파일, Skills, MCP, 전자 우편 등의 유형

이 표기는 모델에게 보여주기 위한 장식이 아니라 추적을 위한 기록입니다. 동일한 문장이 내부 승인 문서에서 왔는지 공개 웹 페이지에서 왔는지에 따라 후속 처리가 달라져야 합니다.

승인도 모델과 분리해야 합니다. 도구 호출 정책 훅에서 고위험 도구를 분류하고, 실행 전에 사람 또는 별도 정책 서비스가 다음을 확인하도록 구성하십시오.

• 요청한 도구가 허용 목록에 있는지
• 인자가 외부 자료의 지시에 의해 바뀌었는지
• 대상 파일과 계정이 승인 범위 안에 있는지
• 실제 외부 효과가 발생하는 작업인지
• 실패했을 때 되돌릴 수 있는지

A.I.G 공식 저장소는 에이전트, Skills, MCP를 검사하는 기능과 재현 가능한 보안 시험 구성 요소를 제공합니다. 다만 A.I.G의 공식 보안 경계 문서는 다중 사용자 권한 관리와 인증을 제공하는 플랫폼이 아니며, 기본적으로 단일 운영자용 도구라고 설명합니다. 따라서 공개 네트워크에 그대로 노출하면 안 됩니다. 내부 시험망이나 접근 제한된 별도 실행 공간에서 사용해야 합니다.

첫 주에는 Skills와 파일 표현을 별도로 재검증합니다

이번 연구에서 눈에 띄는 경로는 Skills와 파일 전달 방식입니다. 따라서 모든 입력을 한꺼번에 점검하기보다 다음 순서로 자산을 나누십시오.

먼저 Skills의 소유자, 저장소, 버전, 설치 시점, 요구 권한을 목록화합니다. 설명 파일만 보지 말고 실행 스크립트, 설정 파일, 숨은 문자, 인코딩 변환 결과까지 확인하십시오. 파일은 본문뿐 아니라 메타데이터, 이름, 확장자, 변환 과정에도 공격 지시가 들어갈 수 있습니다.

MCP도 같은 방식으로 보십시오. MCP 도구 오염에 대한 보안 설명은 외부 도구의 응답이 모델 문맥에 들어가면서 숨은 지시가 정상 도구 설명처럼 처리될 수 있다고 설명합니다. 연결 시점에 도구 이름만 검토하고 실행 시점의 응답을 다시 검사하지 않으면 신뢰 경계가 비어 있게 됩니다.

시험은 반드시 가짜 외부 효과로 진행해야 합니다. 전자 우편은 지역 기록 장치로 바꾸고, 셸은 허용된 모의 명령만 남기며, 파일 쓰기는 임시 작업 공간으로 제한하십시오. 각 사례에서 네 가지 결과를 따로 기록하면 원인 분석이 쉬워집니다.

• 악성 내용이 모델 문맥에 들어갔는가
• 계획이나 도구 선택이 바뀌었는가
• 민감한 도구 호출이 실제로 발생했는가
• 승인 정책이나 격리 계층이 호출을 차단했는가

이렇게 분리하면 “모델이 속았다”와 “실행 계층이 허용했다”를 구별할 수 있습니다. 두 번째가 남아 있다면 시스템 지시문을 고치는 것만으로는 충분하지 않습니다.

확대 시험 전에는 실제 설정으로 대표 사례를 다시 실행합니다

소규모 시범 운영을 넓히기 전에는 논문과 같은 공격을 복사하는 데 그치지 말고, 팀이 실제로 사용하는 출처와 도구를 조합하십시오. 예를 들어 웹 검색 뒤 코드 수정, 내부 문서 검색 뒤 파일 생성, Skills 호출 뒤 지역 테스트 실행처럼 정상 업무 흐름에 악성 자료를 섞습니다.

각 사례는 성공 여부 하나로 끝내지 말고 다음 단계별로 판정하십시오.

• 자료가 검색 결과나 파일 내용으로 유입되었는가
• 에이전트의 계획이 사용자 요청에서 벗어났는가
• 도구 인자에 공격자의 문장이 반영되었는가
• 승인 단계가 실행을 멈췄는가
• 차단 뒤 재시도나 우회 호출이 발생했는가

재시험 환경을 별도로 마련한다면 물리 환경과 가상 환경의 경계를 먼저 확인하십시오. 맥 미니 기반 실행 환경을 검토할 때도 장비와 실행 비용을 분리해 비교해야 합니다. 민감한 자격 증명과 실제 고객 파일을 시험 공간에 넣지 않는 것이 우선입니다. 환경을 분리해도 승인 정책과 기록 체계가 자동으로 생기는 것은 아닙니다.

계속 시험할지 제한할지 점수로 결정합니다

아래 점검표를 실행 기록과 함께 채우십시오. 체크되지 않은 항목이 민감한 외부 효과와 연결되어 있다면, 해당 기능만 제한하고 읽기 전용 시험으로 되돌리는 것이 좋습니다.

• [ ] 사용 중인 커밋과 v0.1.0-rc.7의 차이를 확인했습니다.
• [ ] 웹, 파일, 전자 우편, Skills, MCP, 코드 주석의 출처를 기록했습니다.
• [ ] 셸, 파일 쓰기, 네트워크 전송, 외부 제출 도구를 분류했습니다.
• [ ] 민감한 도구마다 모델과 독립된 승인 지점을 붙였습니다.
• [ ] 숨은 문자, 메타데이터, 인코딩 변환을 포함한 파일 시험을 만들었습니다.
• [ ] 실제 외부 효과가 없는 가짜 도구와 임시 작업 공간을 사용했습니다.
• [ ] 대표 사례에서 문맥 유입, 계획 변경, 호출, 차단 결과를 별도 항목으로 기록했습니다.
• [ ] 연구 수치와 현장 수치를 별도 열에 저장했습니다.
• [ ] 새 배포나 정책 변경 때 같은 사례를 다시 실행할 담당자를 정했습니다.

판정은 단순하게 하십시오. 모든 고위험 경로가 독립 승인과 격리를 통과하면 제한된 시범 운영을 계속할 수 있습니다. 문맥 유입은 확인되지만 도구 호출이 차단되면 기능을 제한한 채 관찰합니다. 민감한 호출이 승인 없이 발생하면 고권한 배포를 보류하고 원인 커밋과 정책 훅을 먼저 수정해야 합니다.

다음 배포에서는 연구 결론을 버전별로 갱신합니다

DeepSeek Harness의 도구 정책, Skills 구조, 문맥 경계, 기본 권한이 바뀌면 이번 연구의 결론도 다시 계산해야 합니다. 같은 내용을 반복해서 기록하는 대신 다음 항목을 버전 관리 대상으로 두십시오.

• 시험 대상 커밋과 배포 날짜
• 모델과 인격 설정
• 외부 자료 경로
• 등록 도구와 승인 정책
• 공격 사례와 기대 차단 결과
• 실제 호출 기록과 차단 사유
• 계속 시험, 기능 제한, 고권한 중단 중 최종 결정

현재 구성은 연구와 다르지만 민감한 작업을 독립적으로 승인하지 못한다면, 논문 수치가 낮더라도 장기 배포를 서두를 이유가 없습니다. 반대로 논문 수치가 높아도 실제 구성에서 외부 자료를 격리하고 도구 호출을 차단한다면 제한된 범위의 검증은 계속할 수 있습니다.

연구 발표 뒤의 현실적인 판단은 “DeepSeek Harness가 안전한가”가 아닙니다. “내 버전에서 어떤 외부 자료가 어떤 도구까지 도달하며, 그 마지막 호출을 누가 승인하는가”입니다. 현재 방식이 단일 서버와 공유 작업 공간에 의존한다면 권한이 섞이고, 재시험 기록이 남지 않으며, 외부 자료와 실제 자격 증명이 같은 실행 경로에 놓이는 문제가 생깁니다. 임시 검증이나 팀별 분리 시험이라면 별도의 맥 실행 환경을 검토할 수 있습니다. 다만 장기 고정 부하나 물리 장치 연결이 핵심인 경우에는 직접 장비를 운영하는 편이 더 적합할 수 있습니다.

추가 환경을 비교할 때는 맥 미니 기반 실행 비용 안내에서 장비 비용과 실행 조건을 먼저 분리해 검토하십시오. 그다음 자신의 버전과 도구 목록으로 첫 주 회귀 목록을 작성하십시오. 연구의 위험 신호를 그대로 복사하지 말고, 실제 승인 기록으로 바꾸는 것이 우선입니다.