AI 코딩 에이전트 도입은 모델을 고르는 일보다 “계획을 어떤 세션에 넣고, 어느 도구를 어느 권한으로 열며, 무엇을 증거로 완료 판정할지”를 정하는 일에 가깝습니다. OpenClaw 공식 문서 기준으로 실행 위치와 승인 방식은 별도 설정이며, 기본값만 믿으면 샌드박스가 없는 환경에서 명령이 gateway 호스트로 향할 수 있습니다. 따라서 안전한 시작 순서는 계획 고정 → 세션 분리 → 도구 최소화 → 변경 전 승인 → 결과 검증입니다.
이 글은 OpenClaw를 설치하거나 명령을 실행한 사용기가 아닙니다. 2026년 9월 14일 공개 문서에서 확인한 제품 동작과 한계를 정리하고, arXiv 논문이 보고한 실험값은 논문의 평가 조건에만 귀속합니다. 처리 시간, 생산성 향상률, 비용 절감률처럼 확인하지 않은 값은 제시하지 않습니다.
광고나 제휴 여부와 무관하게 아래 공개 자료를 참고했습니다.
권한·세션·안전성 판단에 대조한 6개 문서
OpenClaw 프로젝트의 제품 문서 4건, arXiv에 공개된 안전성 연구논문 1건, Informa TechTarget의 해설 1건 등 총 6건을 대조했습니다. 아래 목록은 이 글의 권한 모드, 실행 위치, 승인 결합 규칙, 세션 분리, 연구 수치를 확인한 자료이며, 제품 문서의 정의와 논문의 실험 결과를 서로 바꾸어 인용하지 않았습니다.
- OpenClaw Docs: Permission modes —
deny부터full까지 5개 host exec 모드. - OpenClaw Docs: Exec tool — 실행 위치 4종, 기본 timeout, 샌드박스 부재 시
auto처리. - OpenClaw Docs: Exec approvals — 설정과 host 승인 정책의 결합, 승인 경계와 fallback.
- OpenClaw Docs: Session management — DM·그룹·cron·webhook 세션 구조.
- arXiv: Your Agent, Their Asset: A Real-World Safety Analysis of OpenClaw — CIK 상태 오염 평가의 사례 수, 반복 수, 공격 성공률.
- Informa TechTarget: OpenClaw and Moltbook explained — 로컬 실행 권한과 기업 거버넌스 맥락을 대조한 보조 해설.
OpenClaw 공식 문서의 확인값과 원문 항목명
| 구분 | 확인한 값·정의 | 공식 원문 항목명 | ⭐ 적용상 주의 |
|---|---|---|---|
| host exec 권한 모드 | deny, allowlist, ask, auto, full의 5종 |
OpenClaw host exec modes — tools.exec.mode |
5단계 보안 등급이라는 뜻이 아님. auto와 ask는 같은 allowlist/on-miss 기반이지만 전자는 적격 누락을 자동 검토함 |
| 공식 권장 시작 모드 | 코딩 에이전트에는 auto 권장 |
Recommended default | 모든 명령이 자동 승인되거나 사람 검토가 불필요하다는 뜻이 아님. 검토 실패·고위험 명령 등은 사람 승인으로 갈 수 있음 |
| 실행 위치 | auto, sandbox, gateway, node의 4종; 기본 auto |
Parameters — host |
auto가 항상 샌드박스를 뜻하지 않음. 활성 sandbox가 없으면 gateway로 해석됨 |
| 샌드박스 기본 상태 | 기본은 off; 이때 암시적 host=auto는 gateway로 해석 |
Exec tool — Notes — “sandboxing is off by default” | 로컬 실행이 곧 격리 실행이라는 뜻이 아님. 명시적 host=sandbox는 sandbox가 없을 때 gateway로 우회하지 않고 실패함 |
| 명령 timeout | tools.exec.timeoutSeconds 기본 1800초; 호출별 0은 exec timeout 비활성화 |
Config — tools.exec.timeoutSeconds |
1800초가 업무 완료 보장이나 외부 API timeout을 뜻하지 않음. 0도 호스트·worker 종료를 견디는 영구 실행을 보장하지 않음 |
| 승인 질문 모드 | off, on-miss, always의 3종; 문서상 기본 off |
exec.ask |
off가 명령을 읽기 전용으로 만들거나 OS 권한을 줄인다는 뜻이 아님 |
| UI 부재 시 fallback | deny, allowlist, full의 3종; 생략 시 deny |
askFallback |
full이 allowlist나 별도 명시 승인 요건까지 무시한다는 뜻이 아님. 무인 환경에서는 생략 기본값이 차단 쪽임 |
| 승인 정책 결합 | 일반 경로에서는 OpenClaw 설정과 실행 host의 로컬 승인 정책 중 더 엄격한 결과 적용 | Exec approvals — “effective policy is the stricter” | 한쪽을 full로 바꾸면 다른 쪽 제한도 자동 해제된다는 뜻이 아님. 문서가 밝힌 full-permission 예외는 별도 조건임 |
| 사람 승인 선택 | Allow Once, Always Allow Here, Don’t Allow의 3가지 | Approval flow | Always Allow Here는 정책이 허용할 때만 표시되며 같은 디렉터리의 승인된 명령 범위를 뜻함. 사용자 인증 경계가 아님 |
| DM 세션 범위 | main, per-peer, per-channel-peer, per-account-channel-peer의 4종; 기본 main |
session.dmScope |
main은 모든 DM이 한 대화 맥락을 공유함. 여러 사람이 메시지를 보낼 수 있는 환경의 격리 기본값이 아님 |
| 그룹 세션 범위 | per-group, main의 2종; 기본 per-group |
session.groupScope |
per-group은 대화 맥락 분리일 뿐 host 권한·파일·비밀값의 보안 경계를 자동 생성하지 않음 |
| 입력원별 세션 | DM은 기본 공유, group·room은 각각 분리, cron은 실행마다 새 세션, webhook은 hook별 분리 | How messages are routed | 새 cron 세션이 파일·메모리·외부 시스템의 이전 변경까지 되돌린다는 뜻이 아님 |
계획·도구·검증을 한 흐름으로 묶는 방법
에이전트에게 “고쳐 줘”라고만 맡기면 계획과 실행 권한이 한 문장에 섞입니다. 아래 7단계는 제품 기능을 나열한 것이 아니라, 공식 문서의 실행·세션 경계를 실제 작업 계약으로 옮긴 운영 기준입니다.
- 계획을 먼저 고정합니다. 목표, 읽을 경로, 쓸 수 있는 경로, 금지 작업, 완료 기준, 중단 기준을 한 작업 단위에 적습니다.
- 세션 경계를 정합니다. 단일 운영자의 연속 대화인지, 여러 발신자가 들어오는 DM인지, 그룹·cron처럼 별도 맥락이 필요한지 선택합니다.
- 도구를 효과 기준으로 분류합니다. 조회, 파일 변경, shell 실행, 외부 전송, 배포·삭제를 같은 권한 묶음으로 취급하지 않습니다.
- 실행 위치와 권한 모드를 따로 정합니다. sandbox 여부를 먼저 확인하고, host 명령이 필요 없다면
deny, 알려진 명령만 필요하면allowlist부터 검토합니다. - 승인 전에 정확한 변경 대상을 봅니다. 명령 문자열뿐 아니라 working directory, 대상 파일, 외부 목적지, 되돌리기 가능성을 확인합니다.
- 검증 명령을 실행 명령과 분리합니다. diff, 테스트, 타입 검사, 브라우저 상태, 외부 시스템 결과 중 무엇이 완료 증거인지 계획 단계에서 정합니다.
- 증거가 통과한 뒤에만 범위를 넓힙니다. 한 작업의 성공이 다른 저장소, 프로덕션, 결제·메일 권한의 자동 승인을 뜻하지 않습니다.
조건에 따른 권한·세션 선택 기준표
| 조건 | 선택 | 이유 |
|---|---|---|
| 코드 읽기와 계획 작성만 필요함 | host exec deny, 읽기 도구만 허용 |
shell이 없어도 목표를 달성할 수 있으므로 실행 표면을 열 이유가 없음 |
| 정해진 lint·test 명령만 반복함 | allowlist + 명령·인자·작업 디렉터리 제한 |
알려진 검증 경로만 직접 실행하고 새로운 명령 형태는 차단할 수 있음 |
| 새 명령은 매번 사람이 판단해야 함 | ask + host 승인 정책도 같은 수준 이상으로 설정 |
allowlist 누락을 자동 검토로 넘기지 않고 사람 승인 지점으로 유지함 |
| 일상 코딩에서 저·중위험 명령 자동 검토가 필요함 | 공식 권장인 auto, 단 외부 쓰기·배포·삭제는 별도 사람 승인 |
auto는 적격 누락을 검토하지만 모든 명령을 승인하지 않으며 고위험 효과의 소유권을 대신하지 않음 |
| 결제, 대량 메일, 프로덕션 삭제처럼 되돌리기 어려움 | 기본 deny; 필요한 단일 작업만 좁은 승인 경로로 분리 |
대화 세션의 편의보다 외부 부작용의 복구 불가능성이 우선함 |
| 한 사람만 여러 기기·채널에서 사용함 | dmScope: main을 검토 |
공유 맥락이 연속성에 유리하지만 실제 발신자가 한 명이라는 신뢰 조건이 필요함 |
| 여러 사람이 같은 에이전트에 DM을 보냄 | per-channel-peer; 상호 불신 사용자라면 gateway도 신뢰 경계별 분리 |
공식 문서는 다중 사용자 inbox에 채널+발신자 격리를 권장하며, 세션 분리는 host 관리자 경계가 아니라고 명시함 |
| cron으로 반복 작업을 실행함 | 실행마다 새 세션 + 상태 기반 중복 방지 + 결과 확인 | 새 세션은 대화 맥락만 새로 만들 뿐 이전 외부 변경을 취소하지 않음 |
| 승인 UI가 없는 무인 환경 | askFallback: deny 유지 + 사전 allowlist |
사람에게 물을 수 없는 상황을 자동 허용으로 바꾸지 않고 예측 가능한 실패로 처리함 |
작업 계획서는 최소한 여기까지 적는다
다음은 실행 결과가 아니라 작업을 넘기기 전 작성할 수 있는 계약 예시입니다. 특정 저장소에서 이 설정을 사용하거나 성공을 확인했다는 뜻이 아닙니다.
| 항목 | 기록 예시 | 완료 판정 |
|---|---|---|
| 목표 | 파서의 빈 입력 오류를 수정 | 빈 입력 회귀 테스트가 통과하고 기존 테스트가 유지됨 |
| 읽기 범위 | 파서 구현, 해당 테스트, 패키지 스크립트 | 범위 밖 파일을 읽어야 하면 중단하고 이유를 남김 |
| 쓰기 범위 | 파서 파일 1개와 회귀 테스트 1개 | 최종 diff에 선언하지 않은 파일 변경이 없음 |
| 금지 작업 | 배포, 의존성 교체, 비밀값 조회, 데이터 삭제 | 관련 명령·파일·외부 호출이 실행 계획에 없음 |
| 허용 도구 | 파일 읽기·수정, 지정된 test 명령 | 새 shell 명령은 승인 전 실행하지 않음 |
| 중단 기준 | 수정 범위 확대, 테스트의 비결정적 실패, 외부 권한 요구 | 추측으로 우회하지 않고 미완료 원인과 다음 결정을 분리 |
| 증거 | diff, 명령, exit code, 실패 시 원문 오류 | 에이전트의 “완료” 문장이 아니라 재현 가능한 출력으로 판정 |
논문이 보고한 OpenClaw 안전성 수치
아래 값은 Wang 등 14명의 arXiv preprint가 단일 OpenClaw 인스턴스와 지정된 4개 backbone model을 대상으로 보고한 결과입니다. 이 글이 공격을 재현하거나 측정한 값이 아니며, 일반 사용자 환경의 침해 확률로 환산할 수 없습니다.
| 논문 보고 항목 | 보고값 | 논문 원문 항목명 | ⭐ 적용상 주의 |
|---|---|---|---|
| 지속 상태 분류 | Capability·Identity·Knowledge의 3개 차원 | Three Dimensions of Persistent State / CIK taxonomy | 제품의 모든 보안 위험을 3종으로 완전히 열거했다는 뜻이 아니라 논문이 채택한 분석 틀임 |
| 공격 절차 | 주입과 후속 세션의 trigger로 나눈 2단계 | Attack protocol | 모든 실제 공격이 두 번의 대화로만 끝난다는 뜻이 아님. session-context 주입은 논문에서도 예외로 한 대화 안에서 평가함 |
| 영향 시나리오 | 12개; 2개 harm category와 각 3개 subcategory | Impact scenarios | 12명이 참여했거나 12개 실제 피해 신고를 조사했다는 뜻이 아님. 연구자가 설계한 시나리오 수임 |
| 평가 모델 | 4개 backbone model | Environment | 현재의 모든 모델·버전·설정을 대표한다는 뜻이 아니며 논문에 적힌 모델과 한 인스턴스 조건에 한정됨 |
| 모델당 평가 사례 | 88개: baseline 12개 + injection variant 76개 | Case design / Appendix A Experimental Scale | 88개 저장소나 88명의 사용자 표본이 아님. 한 모델에 적용한 test case 구성임 |
| 반복 실행 | 보고 metric은 5회 독립 실행 평균 | Metrics / Appendix H Full Results with Standard Deviations | 5개 조직에서 재현됐다는 뜻이 아니며 같은 평가 설계의 반복 수임 |
| baseline ASR | 모델별 10.0%~36.7%; 논문 abstract의 전체 평균은 24.6% | Systematic Vulnerability Across CIK Dimensions — Table 2 | OpenClaw 사용자의 실제 사고율이 아님. 논문이 “확인 없이 해로운 행동을 실행”으로 정의한 test-case 공격 성공률임 |
| 상태 오염 후 평균 ASR | CIK 단일 차원 오염 시 평균 64%~74% | Abstract / Systematic Vulnerability Across CIK Dimensions | 모든 배포에서 64~74% 확률로 침해된다는 뜻이 아니며 평가 시나리오·모델·판정 기준에 종속됨 |
| 가장 강한 단일 방어의 남은 ASR | Capability-targeted attack에서 63.8% | Existing Defenses Are Insufficient — Table 4 | 제품의 현재 승인 기능이 63.8% 실패한다는 뜻이 아님. 논문이 Sonnet 4.5에 적용한 3개 CIK 방어 중 capability defense 결과임 |
| 파일 보호 tradeoff | 평균 attack injection 87.0%→5.0%; legitimate update rate는 100%에서 13.2% 미만으로 감소 | The Evolution–Safety Tradeoff — Table 5 | 파일 보호가 보편적으로 공격 97%를 막는다는 단일 보장값이 아님. Knowledge·Identity 파일 대상 평가이며 정상 업데이트도 크게 차단함 |
이 수치가 운영 기준으로 주는 메시지는 “모델이 더 똑똑하면 승인 단계가 필요 없다”가 아닙니다. 논문은 persistent state가 바뀐 뒤 후속 세션에서 행동이 달라지는 구조를 평가했습니다. 따라서 skill·기억·정체성 파일을 단순 콘텐츠가 아니라 실행 정책의 입력으로 보고, 변경 diff와 출처, 서명·고정 버전, sandbox, 사람 승인을 함께 설계해야 합니다.
증상 → 원인 후보 → 확인 → 조치
| 증상 | 원인 후보 | 확인할 항목 | 조치 |
|---|---|---|---|
| 명령이 승인 질문 없이 바로 실행됨 | sandbox가 없고 auto host가 gateway로 해석됨; gateway/node의 permissive 기본 정책 |
실제 host, sandbox 활성 여부, 요청 정책과 host-local 승인 정책의 effective result | host와 tools.exec.mode를 명시하고 host 승인 정책도 함께 좁힌 뒤 effective policy를 다시 확인 |
allowlist에 넣었는데 실행이 계속 거절됨 |
실행 host의 정책이 더 엄격하거나 명령·인자·작업 디렉터리가 승인 범위와 다름 | resolved executable, argv, cwd, 양쪽 정책, allowlist match | 전체 권한으로 우회하지 말고 실제 필요한 명령 형태와 디렉터리만 다시 승인 |
| 승인 대기 뒤 늦게 허용했지만 실행되지 않음 | 원래 turn이 닫히거나 취소되어 pending authority가 무효화됨 | 승인 요청이 발생한 세션·turn, 현재 pending 상태 | 같은 작업을 새 요청으로 다시 제시하고 현재 command·cwd·대상을 재검토 |
| 다른 사람의 DM 맥락이 답변에 섞임 | 기본 dmScope: main으로 여러 발신자가 한 세션을 공유 |
DM 발신자 수, channel/account 구분, 현재 dmScope |
per-channel-peer 또는 필요한 더 좁은 범위를 적용하고 상호 불신 사용자는 gateway 자체를 분리 |
| cron 실행이 이전 대화의 지시를 기억하지 못함 | cron은 실행마다 새 세션 | 작업 정의가 대화에만 있는지, 읽는 설정·입력 파일과 상태 저장 위치 | 검토된 작업 계약을 명시적 입력으로 제공하되 persistent file 변경도 diff·승인 대상으로 관리 |
| 테스트는 통과했지만 외부 시스템 결과가 틀림 | 완료 기준이 코드 내부 검사에만 있고 외부 부작용 검증이 없음 | 요청 ID, 대상 계정, 생성·변경된 외부 상태, 중복 여부, rollback 가능성 | 외부 쓰기 전 승인과 쓰기 후 상태 확인을 별도 단계로 두고 에이전트의 완료 문장만으로 종료하지 않음 |
| skill·기억 업데이트 뒤 후속 세션 행동이 달라짐 | Capability·Identity·Knowledge 입력의 의도치 않은 변경 또는 오염 | 업데이트 전후 diff, 출처, 실행 파일, 자동 로드 범위, 변경 승인자 | 변경을 되돌리고 실행 파일을 격리하며 version pin·서명·사람 승인을 적용한 뒤 별도 안전 검증 |
| 명령이 30분 부근에서 종료됨 | 기본 exec timeout 1800초 도달 | 명령 시작·종료 시각, timeoutSeconds, 외부 서비스 자체 timeout |
무조건 0으로 풀지 말고 작업을 체크포인트로 나누고 업무상 허용 시간을 명시 |
실행 뒤 남겨야 할 검증 증거
- 범위 증거: 최종 diff와 변경 파일 목록이 계획의 쓰기 범위와 일치하는지 확인합니다.
- 동작 증거: 실행한 테스트·lint·type check 명령, exit code, 실패 원문을 남깁니다.
- 사용자 화면 증거: UI 변경이면 대상 viewport와 상호작용 결과를 확인하되, 화면이 보였다는 사실만으로 데이터 저장 성공을 대신하지 않습니다.
- 외부 상태 증거: 배포·메일·결제·API 변경은 대상, 시각, request identifier, 중복 여부, 되돌리기 경로를 확인합니다.
- 미완료 증거: 권한·로그인·quota가 없으면 우회 성공처럼 쓰지 말고 환경 필요 조건으로 분리합니다.
예약 실행의 지연·누락·중복 기준은 GitHub Actions 스케줄 자동화 판단표에서 이어서 볼 수 있습니다. 검증 결과를 행 단위로 기록하려면 회의록 정리 워크플로에서 도구 산출물을 사람이 검수하는 순서을, 이메일처럼 외부 상태가 바뀌는 업무라면 이메일 후속 업무의 상태 추적 구조를 함께 적용할 수 있습니다.
공식 문서에 없는 값과 이 글의 확인 경계
| 항목 | 판정 | 본문 처리 |
|---|---|---|
| OpenClaw 도입의 생산성 향상률·비용 절감률 | 확인한 공식 문서에 명시 없음·이 글에서 미측정 | 효율이 몇 % 좋아진다는 수치를 쓰지 않음 |
| 안전한 작업에 공통인 최적 권한 모드 | 공식 단일 보장값 없음 | 업무의 부작용과 사람 승인 필요성에 따라 조건표로 선택 |
| 논문 ASR의 실제 조직 사고율 환산 | 논문에 명시 없음 | 평가 조건의 attack success rate로만 인용 |
| 이 글의 OpenClaw 설치·실행·공격 재현 | 수행하지 않음 | 제품 문서 확인값과 논문 보고값만 사용 |
| 자료 접근 상태 | 6개 문서 모두 본문 접근 가능 | 접근 차단을 명시 없음으로 바꾸지 않으며, 이번 확인에는 접근 차단 자료가 없음 |
핵심 결론
AI 코딩 에이전트의 품질은 생성한 코드 양보다 경계의 선명도로 판단해야 합니다. OpenClaw에서는 실행 host와 권한 mode가 별도이고, DM 기본 세션은 공유형이며, cron은 매번 새 세션입니다. 이 세 가지를 섞으면 “샌드박스인 줄 알았던 host 실행”, “사용자 사이의 맥락 혼합”, “대화에만 있던 검증 조건의 소실”이 생길 수 있습니다.
도입 첫 단위는 작은 코드 작업 하나면 충분합니다. 읽기·쓰기 범위를 고정하고, shell은 필요한 명령만 열고, 외부 변경은 사람 승인 뒤 실행하며, diff와 테스트·외부 상태가 모두 맞을 때만 완료로 판정하세요. 권한 확대는 편의 설정이 아니라 이전 단계의 검증 증거가 통과한 뒤 내리는 별도 결정입니다.