학교 보안 소모임에서 학술 세미나 주제로 OpenClaw를 선정해 사전 학습한 내용을 적어보려고 한다.
세미나 전
1. OpenClaw(오픈클로)란?
OpenClaw는 메신저와 AI 에이전트를 연결해 주는 자체 호스팅(self-hosted) 플랫폼이다. 사용자는 WhatsApp, Telegram, Discord, Slack 같은 채팅 애플리케이션에서 에이전트에게 메시지를 보내고, OpenClaw는 이를 받아 AI 모델이 응답하거나 필요한 경우 도구를 호출하도록 연결한다. 즉, 단순한 채팅봇이라기보다 채팅 인터페이스를 통해 실제 작업을 수행할 수 있도록 설계된 AI 에이전트 런타임에 가깝다. 공식 문서에서도 OpenClaw는 다양한 채널(Discord, Slack, Telegram, WhatsApp 등)과 연결되는 구조를 제공한다고 설명한다.
또한 OpenClaw는 사용자가 익숙한 메신저 환경에서 AI를 활용할 수 있게 해 준다는 점에서 진입 장벽을 낮춘다. 별도의 전용 인터페이스 대신, 평소 쓰던 채팅 앱 안에서 명령을 내리고 응답을 받을 수 있기 때문이다. 이런 특성 때문에 OpenClaw는 “AI를 대화형 비서처럼 현실 도구와 연결하는 플랫폼”으로 볼 수 있다.
2. OpenClaw가 왜 위험한가?
OpenClaw의 위험성은 채팅 입력이 실제 행동으로 이어질 수 있다는 점에서 발생한다. Chat GPT, Gemini와 같은 일반적인 챗봇은 사용자의 입력에 대해 텍스트 응답만 생성하는 경우가 많지만, OpenClaw는 메시지를 받아 에이전트가 도구를 호출하거나 외부 시스템과 상호작용하도록 연결할 수 있다. 따라서 사용자의 입력은 단순한 질문이 아니라, 경우에 따라 실행 가능한 지시가 될 수 있다.
공식 보안 문서에 따르면 OpenClaw는 기본적으로 한 명의 신뢰된 사용자(trusted operator) 를 전제로 한 개인 비서형 보안 모델을 가정한다. 즉, 여러 명의 서로 신뢰하지 않는 사용자가 하나의 게이트웨이나 하나의 도구 사용 가능 에이전트를 함께 쓰는 구조는 안전한 기본 모델이 아니다. 문서에서는 이런 경우 사용자가 사실상 같은 도구 권한(delegated tool authority)을 공유하는 것으로 봐야 한다고 설명한다.
또한 OpenClaw는 로컬 또는 서버 환경에서 실행되며, 그 환경에 연결된 파일, 계정, 브라우저, 외부 서비스와 상호작용할 수 있다. 그래서 위험의 본질은 “AI의 자율성” 그 자체보다는, AI가 어떤 권한을 가지고 무엇에 접근할 수 있는가에 있다. 권한이 넓고 설정이 느슨할수록, Prompt Injection이나 잘못된 명령, 공유 채널에서의 악의적 입력이 더 큰 피해로 이어질 수 있다. 이를 막기 위해 OpenClaw 공식 문서는 openclaw security audit 사용, 권한 축소, 허용 목록 제한, 채널 노출 최소화 등을 권장한다.
특히 “로컬에서 실행하니까 안전하다”는 생각도 주의가 필요하다. OpenClaw 측은 웹 인터페이스와 HTTP 엔드포인트가 기본적으로 로컬 사용을 의도하고 있으며, 이를 0.0.0.0으로 바인딩하거나 공용 프록시를 통해 외부에 노출하는 방식은 권장하지 않는다고 설명한다. 즉, localhost 환경은 공개 인터넷보다 안전할 수는 있지만, 그 자체가 완전한 안전을 보장하지는 않는다. 로컬 머신에 저장된 브라우저 세션, 파일, 토큰, 설정 파일이 모두 중요한 공격 표면이 될 수 있기 때문이다.
세미나 복습
이번 학술 팀 세미나에서는 OpenClaw를 중심으로 AI Agent 보안과 취약점 분석을 함께 살펴보았다. 이번 세미나는 특정 도구의 기능을 소개하는 데서 끝나는 것이 아니라, 채팅형 AI assistant가 실제 시스템 권한과 연결될 때 어떤 구조적 위험이 생기는지를 이해하는 데 초점을 두고 진행되었다. 이후에는 OpenClaw를 단순한 기능 목록이 아니라 하나의 시스템 구조로 읽어보는 시간을 가졌고, 보안 모델을 다루는 부분에서는 OpenClaw의 공식 문서를 바탕으로 trust boundary를 중심에 두고 내용을 정리했다. 취약점 사례는 크게 두 흐름으로 나누어 살펴보았고, 마지막 토론에서는 이번 세미나의 핵심을 다시 trust boundary와 권한 검증의 문제로 모아 보았다.
1. OpenClaw 구조
Gateway가 중심이다.
OpenClaw는 하나의 Gateway를 중심으로, 여러 채팅 채널·제어 인터페이스·노드가 연결되고, 여기서 세션 관리와 라우팅, 도구 호출이 이루어진다.
chat apps/Control UI/nodes
↓
Gateway
↓
sessions/rounting/connections/toolschat apps
사용자가 실제로 OpenClaw와 상호작용하는 채팅 채널이다. Discord, Slack 같은 메신저가 여기에 해당하며, 사용자의 메시지가 Gateway로 전달되는 입력 창구 역할을 한다.
Control UI
사용자가 브라우저나 앱에서 OpenClaw를 직접 관리하는 제어 인터페이스이다. 세션 상태를 확인하거나, 설정을 조정하거나, 에이전트와 직접 대화하는 관리 화면으로 볼 수 있다. web UI, CLI, 앱 등이 Gateway에 연결되는 control-plane client로 설명된다.
즉, Control UI는 채팅창이 아니라 admin surface라고 할 수 있다.
nodes
실제 실행 능력이나 장치별 기능을 제공하는 연결 지점이다. 노드는 Gateway에 연결되어 명령을 수행하고, 필요할 경우 브라우저 제어/디바이스 동작/호스트 기반 기능을 담당한다.
Gateway
OpenClaw의 핵심이 되는 중앙 제어 계층이다. 모든 메시지 흐름을 받아 세션을 관리하고, 어느 에이전트나 노드로 보낼지 결정하며, 도구 호출과 연결 상태를 조정한다.
sessions
사용자와 에이전트 사이의 대화 맥락과 상태를 유지하는 단위이다.
routing
들어온 요청을 적절한 에이전트/세션/노드로 전달하는 과정이다.
connections
채팅 앱, UI, 노드, 외부 연동 대상과의 연결 상태를 유지하는 요소이다.
tools
browser는 2가지 종류를 가진다.
OpenClaw에서 브라우저는 관리형 브라우저(openclaw) 와 사용자 세션 연결형 브라우저(user) 의 두 가지 방식으로 사용할 수 있다. 기본값은 openclaw 프로필이며, 필요할 경우 user 프로필로 사용자의 실제 로그인된 브라우저 세션에 연결할 수 있다.
OpenClaw 프로필
OpenClaw가 직접 관리하는 전용 브라우저이다. 이 브라우저는 사용자의 개인 브라우저 프로필과 분리되어 있으며, 에이전트 전용의 독립된 실행 환경으로 동작한다. 문서에서도 이를 “agent-only browser”라고 설명하며, 개인 브라우저를 건드리지 않고 탭 열기, 페이지 읽기, 클릭, 입력 등의 작업을 수행할 수 있다고 안내한다. 또한 기본 프로필도 openclaw로 설정되어 있다.
User 프로필
사용자가 실제로 사용 중인 로그인된 Chrome 세션에 연결하는 방식이다. 이 방식은 사용자의 실제 브라우저 환경에 연결되므로, 관리형 openclaw 브라우저보다 더 민감한 권한과 세션 정보를 다룰 수 있다는 점에서 보안적으로 더 주의가 필요하다.
공식 보안 모델의 핵심
보안 모델을 다루는 부분에서는 OpenClaw의 공식 문서를 바탕으로 trust boundary를 중심에 두고 내용을 정리했다. 하나의 gateway를 하나의 신뢰 경계로 보는 관점, 권한과 범위를 먼저 설계한 뒤 모델을 다뤄야 한다는 관점, 그리고 공급망·채널 접근·세션 격리·도구 실행·외부 콘텐츠처럼 여러 층위의 trust boundary를 구분해 보는 방식이 핵심 내용이었다. 이를 통해 OpenClaw를 “무슨 기능이 있는가”보다 “어디에서 어떤 권한이 열리고, 어떤 경계가 깨질 수 있는가”라는 기준으로 다시 읽어볼 수 있었다.
취약점 사례
1. control plane, localhost, browser, token과 연결된 문제
로컬 환경과 초기 연결 정보가 자동으로 안전하다고 믿어지기 쉬운 만큼, 이러한 신뢰가 어떻게 취약점으로 이어질 수 있는지를 사례 중심으로 확인했다. 여기서는 Control UI와 관련된 token 탈취 흐름, localhost 기반 상태 변경 문제, pairing setup code가 credential surface가 될 수 있었던 사례 등을 함께 보며, “로컬 환경이니까 안전하다”는 직관이 실제로는 충분하지 않을 수 있다는 점을 정리했다.
CVE-2026-26317 - loopback CSRF
GHSA-7h7g-x2px-94hj - pairing setup code도 credential surface였다.
2. install, extension, plugin, skill, update와 연결된 확장성과 공급망 영역
skills와 plugins가 단순한 편의 기능이 아니라 사실상 코드 실행 경로가 될 수 있다는 점을 중심으로, workspace plugin auto-discovery나 plugin installation path traversal 같은 사례를 함께 검토했다. 또한 제품 자체의 취약점과는 별개로, OpenClaw를 사칭한 악성 npm 패키지 및 GhostLoader 사례도 함께 보며, 제품 자체의 결함과 OpenClaw를 소재로 한 공급망 공격은 구분해서 이해해야 한다는 점을 정리했다. 이를 통해 확장 기능과 설치 과정 그 자체가 중요한 공격면이 될 수 있음을 확인했다.
GHSA-99qw-6mr3-36qr – workspace plugin auto-discovery
GHSA-qrq5-wjgg-rvqw – plugin installation path traversal
생각해보자
마지막 토론에서는 진짜 trust boundary는 어디읹, localhost는 왜 심리적으로 안전해 보이는지, skills/plugins는 코드 실행을 허용해도 되는지, 가장 먼저 줄여야 할 권한은 무엇인지에 대한 주제로 이야기해보았다.
여기서는 세미나의 핵심을 다시 trust boundary와 권한 검증의 문제로 의견을 모았다. 먼저 AI agent는 프롬프트가 들어왔다는 이유만으로 모든 행동이 정당화되는 존재가 아니며, 프롬프트는 어디까지나 입력일 뿐 곧바로 실행 권한이 될 수 없다는 점을 함께 확인했다. 따라서 agent가 실제 작업을 수행하기 전에는 자체 판단만이 아니라 별도의 권한 검증이 먼저 이뤄져야 한다는 의견이 나왔다. 또한 localhost는 흔히 “내 환경”이기 때문에 안전하다고 느껴지지만, 실제로는 100% 신뢰할 수 있는 절대적인 경계가 아니며, 브라우저, 인증 정보, 확장 기능과 연결되는 순간 충분히 공격면이 될 수 있다는 점도 다시 짚었다. skills와 plugins 역시 단순한 기능 확장이 아니라 사실상 코드 실행을 허용하는 경로라는 점에서, 실행 전 검증과 사용자 승인 절차가 중요하다는 논의가 이어졌다. 마지막으로 우선적으로 줄여야 할 권한에 대해서는 관리자 권한, 신뢰되지 않은 파일의 실행 및 제거, 그리고 과도한 백그라운드 동작을 먼저 제한할 필요가 있다는 방향으로 의견이 모였다.
세미나 후
이번 세미나는 OpenClaw를 하나의 사례로 삼아, AI agent 보안을 단순한 기능 소개나 개별 취약점 나열이 아니라 실제 시스템 구조와 권한 설계의 문제로 바라보는 시간이었다. 앞으로도 논문, 기술 문서, CVE, 최신 보안 이슈를 함께 읽고 토론하면서, 단순히 도구를 사용하는 수준을 넘어 설계와 권한 구조를 비판적으로 읽는 시각을 계속 확장해 나갈 예정이다.
