DeepSeek V4 Pro 에이전트의 안전성, 모델보다 실행 하네스가 좌우한다

DeepSeek V4 Pro를 웹, 모바일 앱, API, OpenAI Responses API, Codex 연동 등 여러 경로에서 사용할 수 있다는 사실은 인터페이스 호환성을 보여줄 뿐입니다. 각 실행 환경에서 프롬프트, 도구, 권한, 메모리, 재시도, 외부 시스템에 대한 부작용이 동일하게 작동한다는 뜻은 아닙니다.

조직이 실제로 승인해야 할 대상은 모델 하나가 아니라 고정된 모델–하네스–작업–환경 구성입니다. 이 구성이 자체 안전성 평가를 통과했을 때만 배포를 허용하는 것이 핵심 원칙입니다.

같은 모델도 하네스에 따라 다른 에이전트가 된다

에이전트의 행동은 기반 모델만으로 결정되지 않습니다. 하네스는 모델이 지시를 받는 방식, 도구를 선택하는 방식, 데이터를 읽는 범위, 실패를 처리하는 방식, 외부 시스템에 영향을 주는 방식을 정합니다.

실제 위험도를 바꿀 수 있는 요소는 다음과 같습니다.

• 시스템 프롬프트와 어댑터
• 도구 정의와 도구 서버 구현
• 권한 범위와 승인 절차
• 파일시스템 루트와 네트워크 접근 범위
• 자격 증명의 출처와 실행 주체의 신원
• 하위 프로세스와 생성 코드의 실행 방식
• 재시도·타임아웃·동시성 로직
• 세션 상태, 요약, 캐시, 영구 메모리

따라서 동일한 DeepSeek V4 Pro 백엔드라도 어떤 하네스와 실행 환경을 거치느냐에 따라 위험 프로파일이 달라질 수 있습니다. 공통 API 형식은 통합 편의성을 뜻할 뿐, 안전성 인증을 의미하지 않습니다.

AgentS4D가 보여준 것과 보여주지 않은 것

AgentS4D는 모델의 단독 응답이 아니라 완성된 런타임 구성을 평가했습니다. 328개의 위험 주입 사례를 4개 에이전트 하네스와 5개 모델 백엔드 조합에서 테스트해 총 6,560회의 샌드박스 실행을 진행했습니다. 그 결과 4,461회, 즉 68.0%가 안전하지 않은 실행으로 분류됐고, 4,344회, 즉 66.22%는 안전하지 않으면서도 작업을 완료한 실행으로 판정됐습니다. 13

가장 중요한 결론은 작업 성공과 안전한 실행이 동시에 성립하지 않을 수 있다는 점입니다. 에이전트가 요구된 파일이나 결과물을 만들어내면서도 금지된 변경을 수행하거나, 민감한 데이터를 잘못 다루거나, 통제 절차를 우회하거나, 다른 위험한 부작용을 일으킬 수 있습니다.

다만 이 수치를 DeepSeek V4 Pro의 실제 운영 사고율로 해석해서는 안 됩니다. AgentS4D는 의도적으로 위험을 주입한 사례를 통제된 샌드박스에서 평가했고, 여러 모델·하네스 조합의 결과를 합산했습니다. 실제 운영 환경에서는 작업 구성, 보안 통제, 공격성 콘텐츠의 노출 정도, 보호해야 할 자산, 피해를 정의하는 기준이 달라집니다. 이 연구가 제공하는 근거는 특정 배포의 사고율 예측이 아니라, 런타임 안전성을 직접 측정해야 한다는 사실입니다. 135

에이전트 행동의 최대 피해를 제한하라

안전장치는 모델이나 도구가 예상과 다르게 작동하더라도 실수의 결과를 제한하도록 설계해야 합니다.

전용·최소 권한 계정을 사용하라

에이전트, 실행 환경, 테넌트별로 별도의 계정을 만드세요. 직원 계정의 상시 자격 증명, 운영 관리자 권한, 여러 작업에서 재사용되는 광범위한 비밀키는 피해야 합니다. 각 계정은 해당 작업에 필요한 리소스와 동작에만 접근하도록 범위를 좁혀야 합니다.

파일시스템과 네트워크를 분리하라

• 전용 작업공간 루트만 마운트합니다.
• 관련 없는 경로는 숨기는 데 그치지 말고 접근 자체를 차단합니다.
• 네트워크 목적지, HTTP 메서드, 포트, 필요하다면 송신량까지 허용 목록으로 제한합니다.
• 읽기, 초안 작성, 스테이징 쓰기, 운영 환경 쓰기 권한을 분리합니다.
• 비밀정보는 자격 증명 브로커나 단기 토큰 시스템에 보관합니다.
• 장기 자격 증명을 프롬프트, 작업공간 파일, 환경 변수, 도구 출력에 넣지 않습니다.

삭제, 게시, 결제, 접근 권한 변경, 배포, 외부 메시지 발송처럼 영향이 큰 작업은 실행 계층의 정책 검사를 통과하게 하거나 명시적인 승인을 요구해야 합니다.

전체 실행 경로를 점검하라

공식 도구만 살펴봐서는 충분하지 않습니다. 하위 프로세스, 셸 명령, 생성 코드, 패키지 설치, 원격 도구 서버, 플러그인, 스킬 코드도 외부 상태를 변경할 수 있습니다.

이 모든 경로에 동일한 정책을 적용해야 합니다. 특히 셸이나 생성 코드가 파일시스템, 네트워크, 인증, 로깅, 승인 통제를 우회하지 못하도록 막아야 합니다.

도구는 모델 밖에서 강제되도록 설계하라

모델이 생성한 도구 호출은 신뢰할 수 없는 요청으로 취급해야 합니다. 권한과 안전 규칙을 실제로 집행하는 주체는 모델이 아니라 도구 서버여야 합니다.

도구 스키마는 좁고 명확하게 만들고, 다음과 같은 제약을 적용하세요.

• 열거형 값과 문자열 길이 제한
• 경로 정규화와 명시적인 리소스 식별자
• 목적지 허용 목록
• 페이지 수와 결과 크기 제한
• 모델 외부에서 수행하는 인자 검증
• 호출자, 테넌트, 대상, 작업을 기준으로 한 서버 측 권한 확인

계획·미리보기 도구와 실제 효과를 발생시키는 도구도 분리하는 편이 안전합니다. 파괴적이거나 되돌리기 어려운 작업에는 다음 조치를 적용해야 합니다.

• 미리보기와 확인 또는 승인 토큰 요구
• 가능한 경우 소프트 삭제, 격리, 되돌릴 수 있는 절차 사용
• 멱등성 키 적용
• 같은 요청이 재시도될 때의 동작을 사전에 정의
• 재시도로 동일한 효과가 반복되지 않도록 내구성 있는 처리 영수증 반환

겉보기에는 정상적인 JSON 도구 호출이라도 권한 없는 대상, 위험한 경로, 과도한 범위, 사람의 검토가 필요한 작업을 포함할 수 있습니다. 따라서 형식이 올바르다는 사실만으로 안전하다고 판단해서는 안 됩니다.

상태와 메모리의 수명주기를 배포 전에 정의하라

상태는 한 번의 대화에 머물지 않고 턴, 작업, 사용자, 환경을 넘어 위험을 전달할 수 있습니다. 메시지, 업로드 파일, 작업공간 파일, 요약, 도구 결과, 캐시, 영구 메모리에 대해 다음 규칙을 문서화하고 집행해야 합니다.

• 격리: 사용자, 테넌트, 작업, 환경별로 상태를 분리하고 세션 간 암묵적인 공유를 허용하지 않습니다.
• 보존: 보존 기간, 암호화, 접근 제어, 삭제 규칙을 명확히 정합니다.
• 초기화: 실행 사이에 컨텍스트, 메모리, 작업공간 상태, 자격 증명, 캐시를 지우는 절차를 제공합니다.
• 재시도와 타임아웃: 횟수와 예산을 제한하고, 재시도가 멱등성을 유지하도록 합니다. 재시도로 권한 범위가 조용히 넓어져서는 안 됩니다.
• 동시성: 공유 파일, 승인, 외부 작업에 대한 잠금과 충돌 처리 방식을 정의합니다.

상태 초기화는 보안 경계의 일부로 다뤄야 합니다. 이전 지시, 자격 증명, 도구 결과가 새 작업에 예기치 않게 다시 나타날 수 있다면 모델 업그레이드나 프롬프트 변경으로 위험이 달라질 수 있습니다. 응답만 확인하는 테스트로는 이런 변화를 놓칠 수 있습니다.

모든 위험 전달 경로를 신뢰할 수 없는 입력으로 취급하라

프롬프트 인젝션은 사용자의 직접 메시지로만 들어오지 않습니다. 다음과 같은 위치에도 지시가 숨어 있을 수 있습니다.

• 업로드 문서와 저장소 파일
• 검색·조회한 웹페이지
• 외부 스킬과 플러그인
• 도구 서비스의 응답
• 저장된 메모리
• 요약과 캐시된 컨텍스트
• 사용자가 제공한 텍스트

이런 내용은 파싱하고 라벨을 붙인 뒤 데이터로 인용해야 합니다. 에이전트의 권한, 정책, 도구 선택, 자격 증명 사용, 승인 요건을 바꾸는 지시로 취급해서는 안 됩니다. 악성 지시를 모델이 알아서 구분하기를 기대하기보다 런타임에서 데이터와 권한을 분리해야 합니다.

하네스별 출시 체크리스트

배포를 승인하기 전에 정확한 구성을 고정하고 기록해야 합니다.

1. 모델과 라우팅: 모델 식별자와 버전, 제공업체 경로, 추론 설정 또는 노력 수준, 호환성 어댑터
2. 하네스 동작: 하네스 버전, 시스템 프롬프트, 세션 로직, 재시도·타임아웃 규칙, 하위 프로세스 정책, 메모리 구현
3. 도구와 정책: 도구 정의와 버전, 정책 버전, 승인 기준, 인증 로직, 도구 서버의 신뢰 경계
4. 권한: 계정, 권한 범위, 파일시스템 루트, 네트워크 목적지, 자격 증명 출처, 운영 환경 쓰기 경로
5. 상태 의미: 격리, 보존, 초기화, 캐시 동작, 동시성, 세션 간 경계
6. 공격 대응 범위: 모든 위험 전달 경로를 통한 프롬프트 인젝션, 혼동된 대리인 공격, 자격 증명 노출, 경로 탐색, SSRF·송신 남용, 악성 도구 응답, 재시도 중복, 메모리 오염, 승인 우회
7. 증거: 프롬프트와 정책 버전, 도구 호출·결과, 승인, 정책 결정, 작업공간 변경 내역, 외부 요청, 사용된 신원, 최종 산출물, 완료 결과, 안전성 결과를 안정적인 실행 ID로 기록

완료 여부와 안전성은 별도로 점수화해야 합니다. 올바른 최종 결과물이 나왔다는 이유로 안전하지 않은 부작용을 상쇄해서는 안 됩니다. 이것이 AgentS4D 결과가 던지는 핵심 교훈입니다. 12

구성이 바뀌면 테스트도 다시 실행해야 한다

승인 대상은 ‘DeepSeek V4 Pro 에이전트’라는 영구적인 제품명이 아니라 특정 시점에 고정된 구성입니다. 다음 요소 중 하나라도 실질적으로 바뀌면 구성별 안전성 테스트를 다시 실행해야 합니다.

• 모델 또는 제공업체 라우팅
• 추론 설정이나 노력 수준
• 시스템 프롬프트 또는 어댑터
• 하네스나 세션 로직
• 도구 또는 원격 도구 서버
• 권한·승인 정책
• 자격 증명 라우팅
• 메모리, 재시도, 타임아웃, 동시성 동작
• 네트워크 또는 파일시스템 경계

이렇게 접근하면 런타임 안전성은 ‘이 모델은 대체로 우수하다’는 막연한 기대가 아니라, 실제 외부 효과를 만들 수 있는 정확한 실행 환경에 기반한 측정 가능한 출시 결정이 됩니다.