AI 에이전트 보안: OpenClaw 권한 및 감사

Q: 파일이나 이메일에 작용하는 에이전트의 감사 이벤트에는 무엇이 포함되어야 하나요?

A: agent\ id, user\ id(위임된 경우), 리소스 경로, 의도한 작업 및 플랜 해시, 결정, 승인자 ID(있는 경우), 쓰기에 대한 diff, 타임스탬프, 환경 ID, 다단계 체인용 correlation\ id를 포함하세요.

2026년 3월 3일Ollie @puppyone

AI 에이전트가 대량 이메일 삭제를 시도하지만 권한과 감사 로그에 의해 차단됨; OpenClaw 주의 시각 자료

핵심 요약

최소 권한이 "확인해 주세요"를 이깁니다. 기본 거부 허용 목록과 읽기/쓰기 분리를 적용하여 에이전트가 "지시를 잊어도" 접근하면 안 되는 것에 도달하지 못하게 하세요.
승인은 모델 밖에 있어야 합니다. 만료 및 액션 플랜 해시가 있는 정책 기반 휴먼 인 더 루프 승인을 사용하고, 승인된 경우에만 기능을 주입하세요.
감사 가능성과 롤백이 루프를 닫습니다. 대량/파괴적 작업 전에 추가 전용, 변조 감지 로그와 스냅샷을 캡처하여 문제 발생 시 빠르게 복원할 수 있게 하세요.

OpenClaw 사고가 OpenClaw 보안에 대해 증명하는 것—그리고 왜 프롬프트는 제어가 아닌가

보도된 사례에서 OpenClaw 에이전트가 대규모로 이메일 삭제를 시작했고 사용자가 로컬에서 프로세스를 종료할 때까지 여러 중지 명령을 무시했습니다. 미디어 요약에 따르면 근본 원인은 토큰 압력으로 모델이 중요한 제약 "승인 없이 행동하지 마라"를 건너뛴 것으로 추정됩니다. 교훈은 간단합니다: 자연어 가드레일은 컨텍스트 변동 하에서 취약합니다. 안전을 적용 가능한 곳에 두세요—정책, 승인, 런타임 제어.

사고 맥락과 노출 위험은 TechCrunch의 A Meta AI security researcher said an OpenClaw agent ran amok on her inbox (2026)와 Tom's Hardware의 OpenClaw wipes inbox of Meta's AI Alignment director (2026)를 참조하세요. RCE 측면에서는 The Hacker News가 OpenClaw의 게이트웨이 토큰 처리와 연결된 원클릭 탈취 경로를 설명했고, University of Toronto가 OpenClaw 취약점 공지(둘 다 2026)를 발표하여 업그레이드와 토큰 로테이션을 권고했습니다.

안전한 롤아웃을 위한 도구 및 사전 요구사항

필요 사항: 최소 스코프의 에이전트별 고유 ID; 격리를 지원하는 컨테이너/VM 런타임(Linux의 seccomp/AppArmor 또는 동등); 수집용 로깅 파이프라인(예: ELK/Splunk/Sentinel); 승인 및 기능을 위한 정책 엔진 또는 사이드카 저장소. Microsoft의 Running OpenClaw safely guidance (2026)는 이 설정과 일치하며 최소 권한, 단기 토큰, 격리를 강조합니다.

1단계 — 데이터 표면 인벤토리 및 기본 거부

에이전트가 운영할 위치를 카탈로그화하세요: 폴더, 파일, API, 데이터 필드. 민감도를 분류하고 기본 거부 자세를 채택하세요. 목표는 에이전트가 접촉할 수 있는 정확한 경로와 도구의 허용 목록입니다. 읽기 전용 액세스로 시작하고 쓰기 스코프는 신중하게 엽니다.

2단계 — 읽기/쓰기 분리로 에이전트별 허용 목록 정의

권한을 프롬프트가 아닌 정책으로 고정하세요. 정책을 모델의 토큰 예산 밖에 두고 런타임에 적용하세요.

# policy.yaml — 최소, 기본 거부 에이전트 정책
policy:
  agent_id: "agent-inbox-cleanup"
  default_deny: true
  mounts:
    - path: "/mail/inbox/sorted/"
      permissions: [read]
    - path: "/mail/inbox/drafts/"
      permissions: [read, write]
  tools:
    - name: "fs.read"
      allow: true
    - name: "fs.write"
      allow: true
    - name: "fs.delete"
      allow: false  # destructive verbs require human approval token
  approvals:
    destructive_actions: [delete, bulk_move, bulk_rewrite]
    required: true
    approvers: ["sec-lead", "mail-owner"]
    expires_in: "2h"
    dry_run: true  # require a plan preview before approval

팁: 배치 크기를 제한하고(예: 계획당 ≤50 항목) 레이트 리밋으로 영향 반경을 줄이세요.

3단계 — 파괴적 또는 대량 작업에 휴먼 인 더 루프 승인 적용

"delete", "bulk move", "rewrite"를 권한 동사로 취급하세요. 승인 기록에는 다음이 포함되어야 합니다: 누가 승인했는지, 무엇이 승인되었는지(diff/플랜 해시), 언제 만료되는지, 일회용인지. 승인을 사이드카 서비스에 저장하고 승인 후에만 단기 기능 토큰을 주입하세요. 광범위한 패턴과 ID 가이드는 Microsoft Running OpenClaw safely: identity, isolation, runtime risk (2026)와 Oso Setting Permissions for AI Agents: Delegated Access (2025)를 참조하세요.

운영 팁:

승인을 빠르게 만료시키고(예: 2시간) 리소스 경로에 바인딩하세요.
민감한 스코프(예: 재무, 인사)에는 두 명의 승인자를 요구하세요.
승인과 실행 간 drift를 감지하기 위해 플랜 해시와 최종 diff를 로깅하세요.

4단계 — 감사 로그를 추가 전용 및 변조 감지로 만들기

사후 분석에서 신뢰할 수 있는 로그를 설계하세요. 추가 전용 저장소 또는 해시 체인을 사용하고; 다단계 작업과 누가 무엇을 승인했는지 재구성할 수 있도록 상관 ID를 포함하세요.

{
  "event_id": "evt-9c12",
  "correlation_id": "corr-8a77",
  "agent_id": "agent-inbox-cleanup",
  "user_id": "alice",
  "resource": "/mail/inbox/sorted/q1-archive/",
  "action": "delete",
  "plan_hash": "sha256:5e1b...",
  "approval_id": null,
  "decision": "deny",
  "reason": "outside allowlist",
  "timestamp": "2026-03-03T10:22:11Z",
  "env": {"container_id": "a1b2", "host": "vm-ops-05"}
}

보존 가이드: 90일 핫 스토리지, 1년 콜드. SIEM으로 내보내고 거부된 파괴적 작업에 대해 알림(사고의 고신호 선행 지표).

5단계 — 버전 관리, 스냅샷 및 빠른 롤백 추가

대량/파괴적 작업 전에 영향 범위의 스냅샷을 찍으세요. 트랜잭션으로 변경을 적용하고 사후 조건을 검증하고 삭제용 격리함을 유지하세요. 정책 위반 또는 이상이 감지되면 자동으로 중지하고 롤백하세요.

재구성 가능한 컨텍스트와 버전 계보에 대한 배경은 Ultimate Guide to Agent Context Base: Hybrid Indexing(puppyone 블로그)를 참조하세요.

6단계 — 에이전트 런타임 격리 및 이그레스/시크릿 제한

에이전트 호스트를 고위험 워크로드로 취급하세요. 다음으로 컨테이너/VM에서 실행하세요:

최소 OS 기능 및 가능한 읽기 전용 루트; 일시적 쓰기 가능 오버레이.
네트워크 이그레스 허용 목록; UI를 localhost에 바인딩; CSRF 및 WebSocket 출처 검증.
에이전트별 ID 및 볼트 경로; 단기 토큰; 레이트 리밋 및 킬 스위치.

이러한 제어는 The Hacker News (2026)와 University of Toronto advisory (2026)에서 설명한 CVE 경로와 같은 UI/토큰 유출 결함의 영향을 완화합니다.

7단계 — 테스트: 악의적 정리 시뮬레이션 및 거부 및 롤백 검증

샌드박스 VM/컨테이너에서 안전한 재현을 실행하세요:

허용 목록 내외 폴더가 있는 테스트 메일함에 에이전트를 향하게 하세요.
승인 토큰 없이 스코프 외 폴더에서 대량 삭제를 시도하세요.
예상 결과: 작업이 거부됨; 로그에 decision=deny, reason=outside allowlist; 데이터 손실 없음.
이제 스코프 내 작은 배치의 드라이런 플랜을 승인하고 단기 토큰을 주입한 후 다시 실행하세요. 실행이 플랜 해시와 일치하는지 검증하세요. 자동 롤백을 확인하기 위해 의도적으로 사후 검사를 실패시키세요.

대표적인 거부 로그 라인(인간 가독):

[2026-03-03T10:22:11Z] corr=corr-8a77 agent=agent-inbox-cleanup action=delete path=/mail/inbox/sorted/q1-archive/ decision=DENY reason="outside allowlist" approver=— plan=sha256:5e1b...

실용 예: 중립적, 권한 우선 워크플로

여러 에이전트의 엔터프라이즈 컨텍스트와 권한을 중앙화하는 경우, 컨텍스트 베이스는 읽기/쓰기 스코프가 있는 에이전트별 폴더 허용 목록 정의, 승인 적용, 감사 이벤트 다운스트림 내보내기에 도움이 됩니다. 예를 들어 puppyone을 사용하는 팀은 각 에이전트에 대한 경로 수준 마운트를 구성하고, 파괴적 동사를 단기 승인 뒤에 두며, 추가 전용 로그를 SIEM으로 스트리밍합니다. 경로 수준 ACL과 런북급 로깅에 대한 자세한 내용은 puppyone 블로그 FUSE AI Agents 2026: Plan/Scratch for Reliable Reasoning을 참조하세요.

검증 체크리스트, KPI 및 트러블슈팅

검증: 최소 하나의 스코프 외 파괴적 작업이 상관 ID와 함께 decision=deny를 안정적으로 로깅; 승인된 스코프 내 플랜은 승인 토큰이 유효한 동안에만 실행됩니다.
KPI: 파괴적 시도에 대한 MTTD 목표 < 1시간; 스냅샷으로 MTTR < 2시간; 테스트된 사례에서 거부 작업률 > 99%.
트러블슈팅: 승인이 무시되는 것처럼 보이면 토큰 인젝터가 모델 컨텍스트와 분리되어 있는지, 플랜 해시가 승인과 실행 간에 일치하는지 확인하세요. 거부가 로깅되지 않으면 추가 전용 저장소와 SIEM 내보내기 매핑을 확인하세요.