피드로 돌아가기
NanoClaw's Deterministic Security Layer
Dev.toDev.to
Security

NanoClaw가 OpenClaw의 프롬프트 기반 보안을 커널 수준 접근 제어로 교체해 AI 에이전트의 프롬프트 인젝션 취약점 차단

NanoClaw's Deterministic Security Layer

Ebenezer Isaac2026년 3월 29일7advanced

Context

OpenClaw는 시스템 프롬프트로 보안 규칙을 강제했으나, 모델이 신뢰성 있어 보이는 악의적 콘텐츠(이메일, 캘린더 이벤트)를 구분하지 못해 공격에 노출되었다. OpenClaw의 내부 구조(도구 실행 파이프라인, 오케스트레이터, 컨테이너 생명주기)가 폐쇄되어 있어 신뢰 모델을 근본적으로 재설계할 수 없었다.

Technical Solution

  • canUseTool 콜백으로 도구 실행 게이트 구현: 모든 도구 호출을 호스트 프로세스에서 모델 외부로 차단 후, Discord 사용자 ID로 발신자 검증 및 gmail_send, memory_write, bulk_delete 등 민감한 도구에 대한 하드 화이트리스트 적용
  • 오케스트레이터 접근으로 킬 스위치 구현: 에이전트 컨테이너 생성 전 구조적 제어를 통해, 프롬프트 조작 불가능한 계층에서 에이전트 실행 여부 결정
  • 수신 계층에서 발신자 화이트리스트: 메시지가 모델에 도달하기 전 정적 화이트리스트로 필터링해 미승인 발신자의 콘텐츠가 컨테이너 생성 자체를 차단
  • 컨테이너 생명주기 훅 커스터마이징: 격리, 세션 경계, 재시작 동작을 호스트 레벨에서 통제하는 확장 포인트 노출
  • 설계 원칙 적용: LLM은 무엇을 할지 결정하고, 호스트 프로세스는 실행 권한을 결정하는 역할 분리로 운영체제의 사용자-커널 권한 모델을 에이전트에 적용

Key Takeaway

AI 에이전트의 보안 문제는 더 나은 프롬프트로 해결할 수 없으며, 모델이 접근할 수 없는 호스트 프로세스 수준에서 입출력 검증과 도구 실행 제어를 구현해야 한다. 실제 역량을 가진 에이전트를 배포할 때는 프레임워크가 제공하는 커널 수준 확장 포인트에 접근 가능한지 먼저 검토해야 한다.


실제 리소스 접근 권한을 가진 AI 에이전트(Gmail 전송, 데이터베이스 쓰기 등)를 배포하는 팀에서 NanoClaw 같은 프레임워크의 호스트 프로세스 콜백(canUseTool)을 활용해 모든 민감한 도구 호출을 모델 외부에서 검증하면, 프롬프트 인젝션 공격으로부터 프로토콜 수준의 보호가 가능하다.

원문 읽기