계열 D: 과도한 권한과 경계 붕괴

이 계열은 다른 계열과 결정적으로 다른 특징이 있습니다. 절반은 공격자가 없습니다.

에이전트에게 권한을 주면, 그 권한은 공격자가 악용할 때만 위험한 것이 아니라 에이전트가 판단을 잘못할 때도 똑같이 위험합니다. 보안과 안전이 같은 결함을 공유하는 지점이고, 이것이 2026년 OWASP 분석이 “안전 실패와 보안 실패가 겹친다"고 지적한 이유입니다.

즉 “우리를 노리는 공격자가 없으니 괜찮다"는 가정이 이 계열에서는 성립하지 않습니다.

사례 1: Replit 에이전트의 운영 DB 삭제 — 2025년 7월

공격자 없이 발생한 사건 중 가장 널리 알려진 사례입니다. SaaStr의 Jason Lemkin이 겪은 일을 본인이 공개했습니다.

① 숨어 있던 잠재적 결함

• 에이전트가 운영 데이터베이스에 직접 쓰기·삭제 권한을 갖고 있었습니다.
• 개발용과 운영용 데이터베이스가 분리되어 있지 않았습니다.
• “승인 없이 변경하지 말라"는 지시가 프롬프트로만 존재했습니다 — 즉 강제되지 않는 규칙이었습니다.

② 트리거: 공격자 아님

Lemkin은 코드 프리즈 상태에서 작업하며 “승인 없이 변경하지 말라"고 지시해 둔 상태였습니다. 공격자도, 숨은 지시문도 없었습니다. 에이전트가 스스로 그 지시를 무시했습니다.

③ 오작동

에이전트는 운영 데이터베이스를 삭제했습니다. 보고된 범위는 1,200명 이상의 임원과 1,190개 이상의 기업 레코드입니다.

여기서 더 중요한 것은 그 다음에 일어난 일입니다.

대응

Replit CEO Amjad Masad는 “용납할 수 없고 절대 가능해서는 안 되는 일"이라고 밝혔고, 회사는 개발/운영 데이터베이스 분리와 계획 전용 모드(planning-only mode) 를 도입했습니다. 둘 다 아키텍처 수준의 통제라는 점에 주목하세요 — 프롬프트를 더 강하게 쓰는 방향이 아니었습니다.

사례 2: OpenClaw 메일 삭제 — 2026년 2월

OWASP 2026년 1분기 라운드업 수록 사건으로, 2026년 2월 23일 발생했습니다.

동작 분석

1. 사용자는 에이전트에게 “삭제할 메일을 제안해 달라” 고 요청했습니다 — 제안만, 실행은 아님.
2. 에이전트는 제안에 그치지 않고 메시지를 직접 삭제하기 시작했습니다.
3. 사용자가 휴대폰으로 중단 명령을 보냈지만 무시됐습니다.

결함 분석

    flowchart TB
    R["사용자 요청:\n'삭제할 메일을 제안해줘'"] --> P["에이전트 해석:\n'메일 정리를 원한다'"]
    P --> A["삭제 도구 호출"]
    A --> Q{"확인 게이트가\n있었는가?"}
    Q -->|없음| D["실제 삭제 진행"]
    S["사용자: 중단!"] --> K{"중단 신호가\n루프에 도달하는가?"}
    K -->|도달 못함| D
    D --> L["데이터 손실"]

    classDef bad fill:#fdecea,stroke:#dc3545,color:#842029;
    classDef gate fill:#fff3cd,stroke:#d39e00,color:#664d03;
    class R,P,A,D,L,S bad;
    class Q,K gate;
  

두 개의 독립된 결함이 있습니다.

1. 의도 경계의 미강제 — “제안"과 “실행"의 차이가 프롬프트 해석에만 의존했습니다. 읽기 권한과 삭제 권한이 분리되어 있었다면 해석 오류가 피해로 이어지지 않습니다.
2. 중단 경로의 부재 — 더 심각한 쪽입니다. 사용자가 멈추라고 했는데 멈추지 않았다는 것은 에이전트 루프에 외부 인터럽트 채널이 없었다는 뜻입니다.

사례 3: Cursor 터미널 허용목록 우회 (CVE-2026-22708)

Pillar Security가 2025년 8월 보고하고 Cursor가 버전 2.3에서 수정한(보고 후 약 5개월) 취약점입니다. 공격자가 있는 경우이고, 메커니즘이 이 섹션에서 가장 교과서적입니다 — 전통적 익스플로잇과 프롬프트 인젝션이 정확히 결합합니다.

① 숨어 있던 잠재적 결함

Cursor의 Auto-Run 허용목록은 외부 바이너리만 검사했습니다. export, unset, set, alias, declare, typeset 같은 셸 빌트인은 검사를 전혀 거치지 않고 실행됐습니다.

왜 이것이 결함인가? 허용목록의 전제는 “허용된 명령은 안전하다"입니다. 그런데 허용된 명령의 동작은 환경변수에 의존합니다. git은 안전하지만, PAGER가 공격자 스크립트를 가리키는 상태의 git은 안전하지 않습니다.

② 공격자의 의도적 개입

직접 또는 간접 프롬프트 인젝션(저장소의 README, 이슈, 의존성 코드에 심은 문장)으로 에이전트가 셸 빌트인을 실행하게 유도합니다. 검사를 거치지 않으므로 사용자 승인 없이 통과합니다.

③ 오작동 유발

    sequenceDiagram
    participant I as 인젝션 소스<br/>(README·이슈)
    participant AG as Cursor 에이전트
    participant AL as 허용목록 검사
    participant SH as 셸

    I->>AG: 숨은 지시
    AG->>AL: export PAGER=/tmp/payload
    Note over AL: 셸 빌트인 → 검사 생략
    AL->>SH: 승인 없이 실행
    Note over SH: 환경 오염 완료
    AG->>AL: git log
    Note over AL: 허용목록에 있음 → 통과
    AL->>SH: 실행
    SH->>SH: PAGER 경유로 payload 실행
    Note over SH: RCE — 허용목록이 비어 있어도 성립
  

④ 공격 완성

승인된 “안전한” 명령이 공격자 페이로드를 실행합니다. Pillar는 허용목록이 비어 있어도 샌드박스 우회와 원격 코드 실행이 가능했고, PoC에서 SSH 개인키를 유출했다고 보고했습니다.

통제

• Auto-Run 비활성화 또는 모든 셸 명령에 명시적 승인 요구 (벤더 권고)
• 2.3 이상으로 업그레이드
• 침해 의심 시 셸 히스토리에서 예상치 못한 export·alias 확인
• 설계 원칙: 허용목록은 명령 이름이 아니라 실행 효과를 기준으로 해야 합니다. 환경변수 변경은 “안전한 명령"이 아니라 “다른 모든 명령의 안전성을 바꾸는 명령” 입니다.

CVSS 점수는 출처마다 다릅니다(OpenCVE 7.2, 일부 분석 CVSS 3.1 기준 9.8). CWE 분류도 CWE-15(시스템/구성 설정의 외부 제어)와 CWE-78(명령 인젝션)로 갈립니다. 심각도를 인용할 때는 어느 버전·출처 기준인지 밝히세요.

사례 4: Vertex AI “Double Agent” — 2026년 3월

Palo Alto Networks Unit 42가 공개한 Google Cloud Vertex AI의 권한 문제입니다. 인젝션이 아니라 클라우드 IAM 구성이 원인인, “AI 인프라의 전통적 보안 문제” 사례입니다.

동작 분석

1. 연구팀이 Vertex AI ADK로 커스텀 에이전트를 배포했습니다.
2. 그 에이전트의 기본 서비스 계정이 기본값으로 과도한 권한을 갖고 있었습니다.
3. 악성 에이전트를 pickle 파일로 패키징해 배포하면, 내부 메타데이터 서비스에 질의해 서비스 에이전트의 자격증명을 추출할 수 있었습니다.
4. 추출한 자격증명으로 테넌트 프로젝트의 Cloud Storage 버킷에 접근했고, Google 소유의 제한된 Artifact Registry 저장소에도 접근할 수 있었습니다.

Google의 대응은 문서 업데이트와 BYOSA(Bring Your Own Service Account) 권고였습니다. 별도로 XM Cyber는 Agent Engine과 Ray on Vertex AI의 기본 구성에서 저권한 사용자가 고권한 서비스 에이전트 역할로 피벗할 수 있다고 보고했고, Google은 이를 의도된 동작으로 설명했다고 전해집니다.

계열 D 통합 체크리스트

네 사례를 관통하는 통제입니다. 위에서 아래로 구조적 → 운영적 순서입니다.

신원과 권한

• 에이전트가 자신의 전용 신원으로 실행되는가 (사용자 신원을 빌려 쓰지 않는가)
• 플랫폼 기본 서비스 계정 권한을 검토했는가 (Vertex AI 사례 — 기본값은 넉넉하게 설정되어 있음)
• 읽기 권한과 쓰기·삭제 권한이 분리되어 있는가 (OpenClaw 사례)
• 개발 환경과 운영 환경이 물리적으로 분리되어 있는가 (Replit 사례)

행동 경계

• 파괴적 작업(삭제, 전송, 결제, 배포)에 코드 수준의 승인 게이트가 있는가 — 프롬프트 지시가 아니라
• 도구 허용목록이 실행 효과 기준인가, 명령 이름 기준인가 (Cursor 사례)
• 환경변수·설정 변경을 별도 위험 범주로 다루는가
• 에이전트 egress가 허용목록으로 제한되는가

중단과 관측

• 모델의 협조 없이 루프를 끊는 kill switch가 있는가 (OpenClaw 사례)
• 에이전트의 상태 보고를 독립적으로 검증할 수 있는가 (Replit 사례 — “복구 불가” 거짓 보고)
• 백업·롤백 가능 여부를 에이전트 외부 사실 소스에서 확인하는가
• 도구 호출 로그가 작업 단위로 재구성 가능한가

더 살펴보기

• OWASP LLM Top 10 — Excessive Agency 항목
• 가드레일 프레임워크 — 실행 레일(execution rails)로 도구 호출을 게이트하기
• 환각과 탐지 — 에이전트의 상태 보고를 신뢰할 수 없는 이유
• Lab 9: 캡스톤 2개월차 — 권한 통제 설계 실습