포스트

DefenseClaw가 Agent Prompt Injection을 막을까: 5개 Scanner와 외부 강제

DefenseClaw는 프롬프트 인젝션을 완벽히 차단하는 방패가 아니라, 에이전트 밖에서 도구, 네트워크 권한을 강제해 공격의 피해 범위를 줄이는 초기 보안 계층입니다.

탐지보다 중요한 것은 실행을 막을 위치다

에이전트와 같은 프로세스 안에 보안 검사를 두면 에이전트가 탈취됐을 때 검사 코드도 우회될 수 있습니다. 원문이 소개한 DefenseClaw의 핵심은 NVIDIA OpenShell 샌드박스와 결합해 정책을 out-of-process로 집행하는 구조입니다. 네트워크는 기본 거부로 두고 허용된 엔드포인트와 권한만 열며, 위험이 발견되면 샌드박스 권한이나 MCP 서버 접근을 회수합니다.

이 설계는 모델이 악성 지시를 “이해하지 못하게” 만드는 것이 아닙니다. 모델이 잘못 판단해도 실제 파일과 외부 시스템에 닿을 수 있는 범위를 줄이는 방식입니다. 그래서 좋은 탐지 모델뿐 아니라 최소 권한, 분리된 자격 증명과 되돌릴 수 없는 작업의 승인 절차가 여전히 필요합니다.

설치 전 다섯 종류를 검사한다

Admission 단계에는 원문 기준 다섯 스캐너가 소개됩니다.

  • skill-scanner: 내려받은 스킬과 스크립트 검사
  • mcp-scanner: MCP 서버 위험 검사
  • a2a-scanner: Agent-to-Agent 연결 검사
  • CodeGuard: 생성 코드의 실행 전 분석
  • AI BoM: 에이전트를 구성하는 자산 명세

이 단계의 목적은 출처를 모르는 코드와 서버가 실행 환경에 들어오기 전에 멈추는 것입니다. 하지만 검사에 통과한 구성요소가 런타임에도 계속 안전하다는 보장은 없습니다. 외부 입력에 의해 동작이 바뀌거나 정상 도구가 과도한 권한으로 호출될 수 있기 때문입니다.

따라서 인바운드와 아웃바운드 메시지를 살피는 런타임 검사, 격리와 권한 회수가 뒤따릅니다. Splunk 연동은 이 이벤트를 보안 운영 흐름에서 관찰하는 수단으로 소개됩니다. 로그를 남기는 것과 차단 정책이 실제로 작동하는 것은 별개이므로 두 경로를 각각 시험해야 합니다.

이 YAML은 현재 설정 사양이 아니다

원문은 정책 의도를 다음과 같은 개념 예시로 설명합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

agent:
  name: "jira-dev-claw"
  runtime: "openshell"
policies:
  mcp_servers:
    - name: "jira-mcp-server"
      action: "allow"
      permissions:
        - "read_ticket"
        - "update_status"
      blocked_permissions:
        - "delete_ticket"
  runtime_inspection:
    - type: "prompt_injection_guard"
      action: "quarantine"

이 조각은 읽기, 상태 변경은 허용하고 삭제는 막는 정책 모양을 보여 줄 뿐, 현재 DefenseClaw가 그대로 받아들이는 완전한 스키마나 배포 절차가 아닙니다. 저장소 설정 형식, OpenShell 준비, 자격 증명, 네트워크와 감사 로그 구성이 빠져 있습니다.

실제 정책을 만들 때는 도구 이름보다 외부 효과를 기준으로 나누는 편이 낫습니다. 읽기, 생성, 수정, 삭제, 결제처럼 권한 수준을 구분하고, 삭제나 광범위한 변경은 네트워크 허용 목록만으로 끝내지 말고 사람 승인을 요구해야 합니다.

오탐과 지연도 보안 예산에 포함한다

모든 메시지와 코드를 검사하면 지연이 추가됩니다. 초당 상호작용이 많은 워크플로우에서는 스캐너 처리량과 격리까지 걸리는 시간을 측정해야 합니다. 탐지 후 수 초 동안 권한이 살아 있다면 그 사이 외부 효과가 발생할 수 있습니다.

엄격한 스캐너는 정상 자동화도 위험으로 분류할 수 있습니다. 허용 목록을 늘리다 보면 운영 부담이 커지고, 급한 예외가 영구 우회로로 남을 수 있습니다. 오탐률뿐 아니라 예외의 소유자, 만료일과 재검토 기록을 관리해야 합니다.

OpenShell 의존성도 기술 선택의 일부입니다. 다른 샌드박스 표준을 쓰는 조직이라면 격리 계층을 바꾸는 비용을 확인해야 합니다. 초기 프로젝트인 만큼 기능 목록보다 업그레이드와 장애 시 정책이 어떤 상태로 실패하는지를 먼저 검증해야 합니다. 보안 계층이 멈췄을 때 허용되는 fail-open은 가장 위험한 기본값입니다.

파일럿은 공격 시나리오로 통과시킨다

테스트 에이전트에 읽기 전용 자격 증명만 주고 세 가지 상황을 재현하십시오. 악성 지시가 포함된 문서, 허용되지 않은 MCP 도구 호출, 정상 스크립트의 오탐입니다. 각 경우에 설치 전 차단, 런타임 격리, 권한 회수가 실제로 일어나는지와 Splunk 기록을 확인합니다.

그다음 허용된 읽기 작업의 지연을 기준선과 비교하고, 차단 후 에이전트가 다른 경로로 우회하지 않는지 봅니다. 이 시험을 통과해도 데이터베이스 삭제나 배포 권한을 바로 주어서는 안 됩니다. DefenseClaw는 최소 권한과 사람 승인을 대체하는 제품이 아니라 그 정책을 더 강한 경계에서 집행하기 위한 후보입니다.

먼저 어떤 공격을 막을지 범위를 정한다

프롬프트 인젝션 하나에도 여러 경로가 있습니다. 사용자가 직접 넣은 악성 지시, 검색한 웹 문서와 이메일에 숨은 지시, 감염된 스킬, MCP 서버, 다른 에이전트가 전달한 메시지를 나눠야 합니다. 각 입력이 어떤 파일, 도구, 네트워크 권한에 닿을 수 있는지 데이터 흐름으로 그리면 스캐너가 막는 단계와 남은 공백이 보입니다.

목표도 탐지율 하나가 아닙니다. 비밀 읽기, 외부 전송, 데이터 변경, 권한 상승과 지속성 확보처럼 보호할 자산별로 허용할 동작을 정합니다. 모델이 공격 문장을 따르더라도 읽을 비밀이 없고 외부 목적지가 차단돼 있으면 피해가 줄어듭니다. 반대로 탐지 경고만 남고 도구 권한이 그대로라면 공격자가 다음 표현으로 재시도할 수 있습니다.

신뢰 경계에는 보안 도구 자체도 포함됩니다. 정책 파일을 누가 수정하고 스캐너 업데이트를 어떤 경로로 받는지, 로그와 격리 해제 권한이 누구에게 있는지 확인합니다. 에이전트가 실행하는 계정으로 정책을 바꿀 수 있다면 out-of-process 구조의 이점이 약해집니다.

설치 전 스캔은 어떤 한계를 갖나

정적 스캐너는 내려받은 코드와 명시된 설정을 볼 수 있지만 런타임에 추가로 받은 명령, 동적으로 내려받는 파일과 원격 서버의 행동 변화를 모두 예측하기 어렵습니다. 설치 시점에 안전한 MCP 서버가 나중에 업데이트되거나 계정이 탈취될 수도 있습니다. 해시와 버전을 고정하고 변경될 때 재검사를 요구해야 합니다.

AI BoM은 목록이 있는 것과 최신 상태인 것을 구분해야 합니다. 모델, 스킬, 서버, 플러그인과 자격 증명의 소유자, 버전을 실행 로그와 연결합니다. 사용되지 않는 오래된 구성요소와 취약한 버전을 찾고, 승인되지 않은 새 도구가 나타나면 실행 전에 차단할 수 있어야 합니다.

스캔 결과의 근거도 남깁니다. 위험 패턴 이름만 보여 주면 운영자가 왜 차단됐는지 판단하기 어렵고 허용 목록을 넓게 만들 수 있습니다. 파일, 설정 위치, 요청한 권한, 외부 목적지와 가능한 영향을 보여 주고 예외는 최소 범위와 만료 시간을 가져야 합니다.

권한 회수 전의 짧은 시간도 시험해야 한다

런타임 검사가 메시지를 분석하고 격리를 요청하는 동안 도구 호출이 이미 시작될 수 있습니다. 악성 입력을 받은 시점, 탐지, 권한 회수와 외부 요청 차단 시간을 각각 기록합니다. 회수 전에 한 번의 쓰기나 전송이 가능한 구조라면 고위험 도구는 사전 승인이나 동기식 정책 검사를 거쳐야 합니다.

장기 연결과 이미 발급된 토큰도 확인합니다. 네트워크 규칙을 바꿔도 열린 연결이 유지되거나 하위 프로세스가 자격 증명을 복사했다면 격리 뒤에도 작업이 계속될 수 있습니다. 세션 종료, 프로세스 트리 정리와 임시 비밀 폐기가 실제로 일어나는지 공격 시나리오로 검증해야 합니다.

차단 후 에이전트가 같은 목적을 다른 도구로 달성하려는지도 봅니다. 삭제 도구를 막았더니 코드 실행기로 삭제 명령을 만들거나 허용된 HTTP 도구로 중계할 수 있습니다. 도구 이름이 아니라 파일 쓰기, 외부 전송 같은 효과 기준으로 권한을 묶어야 우회 경로를 줄일 수 있습니다.

보안 계층 장애 때 기본값은 무엇이어야 할까

정책 엔진이나 OpenShell 상태를 확인할 수 없을 때 고위험 작업을 허용하면 가장 필요한 순간에 경계가 사라집니다. 읽기 전용, 비민감 요청과 쓰기, 비밀 접근을 구분해 후자는 fail-closed로 두고, 전자는 제한된 로컬 기능만 계속할지 정합니다. 장애 모드가 일반 운영 권한보다 넓어지지 않아야 합니다.

로그 전송 실패와 정책 집행 실패도 분리합니다. Splunk가 잠시 unavailable하다고 모든 작업을 멈출 필요는 없을 수 있지만, 로컬 감사 버퍼의 용량과 재전송 순서를 정해야 합니다. 반대로 차단 명령이 적용됐는지 확인할 수 없다면 단순 경보가 아니라 실행을 중지해야 합니다.

업그레이드와 정책 배포 중에는 노드마다 다른 버전이 동작할 수 있습니다. 새 규칙이 모든 샌드박스에 반영됐는지, 오래된 노드가 요청을 받지 않는지 확인합니다. 실패한 업데이트를 되돌릴 때도 이전 정책이 현재 위협을 허용하지 않는지 검토해야 합니다.

오탐을 줄이면서 예외가 우회로가 되지 않게 하려면

정상 작업을 차단한 사례를 읽기, 코드 생성, 외부 API 호출과 파일 변경으로 분류합니다. 규칙 전체를 끄기보다 특정 도구, 목적지, 작업 ID에만 좁은 예외를 주고 자동 만료시킵니다. 예외를 요청한 사람과 승인자, 사용 횟수와 실제 결과를 남겨 반복 예외는 정책 개선 대상으로 돌립니다.

탐지 민감도를 낮출 때 공격 회귀 세트를 함께 실행합니다. 오탐 하나를 없애려다 비슷한 표현의 악성 지시가 통과할 수 있습니다. 정상, 악성 쌍을 같은 문맥으로 만들어 어느 특징이 판정을 바꿨는지 확인하고, 탐지 모델과 결정적 권한 규칙의 역할을 분리합니다.

사용자에게 차단 이유와 가능한 안전한 대안을 보여 주면 무조건 예외를 요청하는 일을 줄일 수 있습니다. 다만 오류 메시지에 내부 정책, 비밀 경로나 탐지 상세를 과도하게 노출하지 않습니다. 운영자용 감사 정보와 에이전트가 받을 최소 피드백을 나누는 편이 좋습니다.

도입 여부는 어떤 표로 판단할까

공격 유형별 차단 위치, 탐지부터 회수까지의 시간, 차단 전 외부 효과와 로그 완전성을 기록합니다. 정상 작업에서는 추가 P50/P95 지연, 오탐, 예외 처리 시간과 처리량을 봅니다. “공격을 잡았다”는 사례와 정상 자동화를 계속 운영할 수 있는지는 다른 지표입니다.

비교 대상은 DefenseClaw 없음만이 아닙니다. 최소 권한 샌드박스만 적용한 경우, 네트워크 allowlist와 사람 승인만 적용한 경우, 스캐너, 런타임 검사를 더한 경우를 나눕니다. 추가 계층이 어떤 공격을 더 막고 어느 비용을 만드는지 확인해야 중복 통제와 실제 공백을 찾을 수 있습니다.

읽기 전용 에이전트에서 정책 장애, 회수, 오탐을 안정적으로 처리한 뒤 제한된 쓰기를 추가합니다. 고위험 권한을 주기 위한 명분으로 보안 제품을 쓰는 것이 아니라 이미 최소화한 권한의 우회와 남용을 더 줄이는 계층으로 사용해야 합니다.

참고 자료:

원문과 버전 확인

함께 읽으면 이해가 이어지는 글

THE END / OPSOAI

여기까지 읽었습니다

핵심 장면을 한 번 더 떠올려 보세요. 이해가 남았다면 이 책은 제 역할을 다했습니다.

다른 책 고르기
표지 1 —

←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.

CONTENTS

이 책의 목차

    13개 장 22 분읽는 시간