보안

WARNING

개인 어시스턴트 신뢰 모델: 이 가이드는 게이트웨이당 하나의 신뢰할 수 있는 오퍼레이터 경계를 가정합니다(단일 사용자/개인 어시스턴트 모델). OpenClaw는 하나의 에이전트/게이트웨이를 공유하는 여러 적대적 사용자를 위한 적대적 멀티 테넌트 보안 경계가 아닙니다. 혼합 신뢰 또는 적대적 사용자 운영이 필요한 경우 신뢰 경계를 분리합니다(별도 게이트웨이 + 자격 증명, 이상적으로는 별도 OS 사용자/호스트).

범위 우선: 개인 어시스턴트 보안 모델

OpenClaw 보안 가이드는 개인 어시스턴트 배포를 가정합니다: 신뢰할 수 있는 오퍼레이터 경계 하나, 잠재적으로 여러 에이전트.

지원되는 보안 자세: 게이트웨이당 하나의 사용자/신뢰 경계(경계당 하나의 OS 사용자/호스트/VPS 선호).
지원되지 않는 보안 경계: 상호 신뢰할 수 없는 또는 적대적 사용자가 공유하는 하나의 공유 게이트웨이/에이전트.
적대적 사용자 격리가 필요한 경우 신뢰 경계별로 분리합니다(별도 게이트웨이 + 자격 증명, 이상적으로는 별도 OS 사용자/호스트).
여러 신뢰할 수 없는 사용자가 하나의 도구 활성화된 에이전트에 메시지를 보낼 수 있는 경우 해당 에이전트에 대해 동일한 위임된 도구 권한을 공유하는 것으로 취급합니다.

이 페이지는 해당 모델 내에서의 강화를 설명합니다. 하나의 공유 게이트웨이에서 적대적 멀티 테넌트 격리를 주장하지 않습니다.

빠른 확인: `openclaw security audit`

참조: 공식 검증 (보안 모델)

정기적으로 실행합니다(특히 구성을 변경하거나 네트워크 표면을 노출한 후):

bash

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix
openclaw security audit --json

security audit --fix는 의도적으로 좁게 유지됩니다: 일반적인 오픈 그룹 정책을 허용 목록으로 전환하고, logging.redactSensitive: "tools"를 복원하고, 상태/구성/포함 파일 권한을 강화하고, Windows에서 실행 시 POSIX chmod 대신 Windows ACL 재설정을 사용합니다.

일반적인 함정(게이트웨이 인증 노출, 브라우저 제어 노출, 상승된 권한 허용 목록, 파일 시스템 권한, 허용적 exec 승인, 오픈 채널 도구 노출)을 플래그합니다.

OpenClaw는 제품이자 실험입니다: 프론티어 모델 동작을 실제 메시징 표면과 실제 도구에 연결합니다. "완벽하게 안전한" 설정은 없습니다. 목표는 다음에 대해 신중하게 하는 것입니다:

누가 봇과 이야기할 수 있는지
봇이 어디서 행동할 수 있는지
봇이 무엇을 건드릴 수 있는지

작동하는 가장 작은 액세스로 시작한 다음 확신을 얻으면서 넓힙니다.

배포 및 호스트 신뢰

OpenClaw는 호스트와 구성 경계가 신뢰됩니다:

누군가가 게이트웨이 호스트 상태/구성(~/.openclaw, openclaw.json 포함)을 수정할 수 있다면 신뢰할 수 있는 오퍼레이터로 취급합니다.
여러 상호 신뢰할 수 없는/적대적 오퍼레이터를 위해 하나의 게이트웨이를 실행하는 것은 권장되는 설정이 아닙니다.
혼합 신뢰 팀의 경우 별도 게이트웨이(또는 최소한 별도 OS 사용자/호스트)로 신뢰 경계를 분리합니다.
권장 기본값: 머신/호스트(또는 VPS)당 하나의 사용자, 해당 사용자에 대해 하나의 게이트웨이, 해당 게이트웨이에 하나 이상의 에이전트.
하나의 게이트웨이 인스턴스 내에서 인증된 오퍼레이터 액세스는 신뢰할 수 있는 제어 플레인 역할이지 사용자별 테넌트 역할이 아닙니다.
세션 식별자(sessionKey, 세션 ID, 레이블)는 권한 토큰이 아닌 라우팅 선택기입니다.
여러 사람이 하나의 도구 활성화된 에이전트에 메시지를 보낼 수 있다면 각각 동일한 위임된 권한 집합을 조종할 수 있습니다. 세션/메모리 격리는 프라이버시에 도움되지만 공유 에이전트를 사용자별 호스트 권한 부여로 전환하지 않습니다.

공유 Slack 워크스페이스: 실제 위험

"Slack의 모든 사람이 봇에 메시지를 보낼 수 있다면" 핵심 위험은 위임된 도구 권한입니다:

허용된 발신자는 에이전트 정책 내에서 도구 호출(exec, 브라우저, 네트워크/파일 도구)을 유도할 수 있습니다.
한 발신자의 프롬프트/콘텐츠 주입은 공유 상태, 기기 또는 출력에 영향을 미치는 작업을 유발할 수 있습니다.
하나의 공유 에이전트에 민감한 자격 증명/파일이 있으면 허용된 발신자가 도구 사용을 통해 잠재적으로 유출을 유도할 수 있습니다.

팀 워크플로에는 최소한의 도구가 있는 별도 에이전트/게이트웨이를 사용하고; 개인 데이터 에이전트는 비공개로 유지합니다.

회사 공유 에이전트: 허용 가능한 패턴

해당 에이전트를 사용하는 모든 사람이 동일한 신뢰 경계에 있고(예: 하나의 회사 팀) 에이전트가 엄격하게 업무 범위로 지정된 경우 허용 가능합니다.

전용 머신/VM/컨테이너에서 실행합니다.
해당 런타임에 대해 전용 OS 사용자 + 전용 브라우저/프로필/계정을 사용합니다.
해당 런타임을 개인 Apple/Google 계정이나 개인 비밀번호 관리자/브라우저 프로필에 로그인하지 마십시오.

개인 및 회사 신원을 동일한 런타임에 혼합하면 분리가 무너지고 개인 데이터 노출 위험이 증가합니다.

게이트웨이 및 노드 신뢰 개념

게이트웨이와 노드를 하나의 오퍼레이터 신뢰 도메인으로, 다른 역할로 취급합니다:

게이트웨이는 제어 플레인 및 정책 표면(gateway.auth, 도구 정책, 라우팅)입니다.
노드는 해당 게이트웨이와 페어링된 원격 실행 표면(명령, 기기 작업, 호스트 로컬 기능)입니다.
게이트웨이에 인증된 호출자는 게이트웨이 범위에서 신뢰됩니다. 페어링 후 노드 작업은 해당 노드에서 신뢰할 수 있는 오퍼레이터 작업입니다.
sessionKey는 라우팅/컨텍스트 선택이며 사용자별 인증이 아닙니다.
Exec 승인(허용 목록 + 요청)은 오퍼레이터 의도를 위한 가드레일이지 적대적 멀티 테넌트 격리가 아닙니다.
신뢰할 수 있는 단일 오퍼레이터 설정에 대한 OpenClaw의 제품 기본값은 gateway/node에서의 호스트 exec가 승인 프롬프트 없이 허용됩니다(security="full", 강화하지 않는 한 ask="off"). 해당 기본값은 의도적인 UX이며 그 자체로는 취약점이 아닙니다.
Exec 승인은 정확한 요청 컨텍스트 및 최선의 직접 로컬 파일 피연산자를 바인딩합니다. 모든 런타임/인터프리터 로더 경로를 의미적으로 모델링하지는 않습니다. 강력한 경계를 위해 샌드박싱 및 호스트 격리를 사용합니다.

적대적 사용자 격리가 필요한 경우 OS 사용자/호스트별로 신뢰 경계를 분리하고 별도 게이트웨이를 실행합니다.

신뢰 경계 매트릭스

위험을 분류할 때 빠른 모델로 사용합니다:

경계 또는 제어	의미	일반적인 오해
`gateway.auth` (토큰/비밀번호/신뢰할 수 있는 프록시/기기 인증)	게이트웨이 API에 대한 호출자 인증	"안전하기 위해 모든 프레임에 메시지별 서명이 필요하다"
`sessionKey`	컨텍스트/세션 선택을 위한 라우팅 키	"세션 키는 사용자 인증 경계다"
프롬프트/콘텐츠 가드레일	모델 남용 위험 감소	"프롬프트 주입만으로 인증 우회가 증명된다"
`canvas.eval` / 브라우저 평가	활성화된 경우 의도적인 오퍼레이터 기능	"모든 JS eval 기본 요소는 이 신뢰 모델에서 자동으로 취약점이다"
로컬 TUI `!` 셸	명시적 오퍼레이터 트리거 로컬 실행	"로컬 셸 편의 명령은 원격 주입이다"
노드 페어링 및 노드 명령	페어링된 기기에서의 오퍼레이터 수준 원격 실행	"원격 기기 제어는 기본적으로 신뢰할 수 없는 사용자 액세스로 취급해야 한다"

설계상 취약점이 아닌 것

이러한 패턴은 일반적으로 보고되며 실제 경계 우회가 표시되지 않는 한 보통 조치 없음으로 종료됩니다:

정책/인증/샌드박스 우회 없는 프롬프트 주입 전용 체인.
하나의 공유 호스트/구성에서 적대적 멀티 테넌트 운영을 가정하는 주장.
공유 게이트웨이 설정에서 일반 오퍼레이터 읽기 경로 액세스(예: sessions.list/sessions.preview/chat.history)를 IDOR로 분류하는 주장.
로컬호스트 전용 배포 결과(예: 루프백 전용 게이트웨이의 HSTS).
이 리포지토리에 존재하지 않는 인바운드 경로에 대한 Discord 인바운드 웹훅 서명 결과.
실제 실행 경계가 여전히 게이트웨이의 전역 노드 명령 정책과 노드의 자체 exec 승인인데 노드 페어링 메타데이터를 system.run에 대한 숨겨진 두 번째 명령별 승인 레이어로 취급하는 보고서.
sessionKey를 인증 토큰으로 취급하는 "사용자별 권한 부여 누락" 결과.

연구원 사전 비행 체크리스트

GHSA를 열기 전에 다음을 모두 확인합니다:

최신 main 또는 최신 릴리스에서 재현이 여전히 작동합니다.
보고서에 정확한 코드 경로(file, 함수, 줄 범위)와 테스트된 버전/커밋이 포함됩니다.
영향이 문서화된 신뢰 경계를 넘습니다(프롬프트 주입만이 아닌).
주장이 범위 외에 나열되지 않습니다.
중복에 대해 기존 어드바이저리를 확인했습니다(해당 시 정식 GHSA 재사용).
배포 가정이 명시적입니다(루프백/로컬 vs 노출, 신뢰할 수 있는 vs 신뢰할 수 없는 오퍼레이터).

60초 강화된 기준선

이 기준선을 먼저 사용하고 신뢰할 수 있는 에이전트당 선택적으로 도구를 다시 활성화합니다:

json5

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "replace-with-long-random-token" },
  },
  session: {
    dmScope: "per-channel-peer",
  },
  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
  channels: {
    whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } },
  },
}

이것은 게이트웨이를 로컬 전용으로 유지하고, DM을 격리하고, 기본적으로 제어 플레인/런타임 도구를 비활성화합니다.

공유 받은 편지함 빠른 규칙

하나 이상의 사람이 봇에 DM을 보낼 수 있다면:

session.dmScope: "per-channel-peer" 설정(다중 계정 채널의 경우 "per-account-channel-peer").
dmPolicy: "pairing" 또는 엄격한 허용 목록을 유지합니다.
공유 DM과 광범위한 도구 액세스를 절대 결합하지 않습니다.
이것은 협력/공유 받은 편지함을 강화하지만, 사용자가 호스트/구성 쓰기 액세스를 공유하는 경우 적대적 공동 테넌트 격리를 위한 것이 아닙니다.

컨텍스트 가시성 모델

OpenClaw는 두 가지 개념을 분리합니다:

트리거 권한 부여: 에이전트를 트리거할 수 있는 사람(dmPolicy, groupPolicy, 허용 목록, 언급 게이트).
컨텍스트 가시성: 모델 입력에 주입되는 추가 컨텍스트(회신 본문, 인용 텍스트, 스레드 기록, 전달된 메타데이터).

허용 목록은 트리거 및 명령 권한 부여를 게이팅합니다. contextVisibility 설정은 추가 컨텍스트(인용 회신, 스레드 루트, 가져온 기록)가 필터링되는 방식을 제어합니다:

contextVisibility: "all" (기본값): 받은 대로 추가 컨텍스트를 유지합니다.
contextVisibility: "allowlist": 추가 컨텍스트를 활성 허용 목록 검사에 의해 허용된 발신자로 필터링합니다.
contextVisibility: "allowlist_quote": allowlist처럼 동작하지만 하나의 명시적 인용 회신은 여전히 유지합니다.

채널별 또는 방/대화별로 contextVisibility를 설정합니다. 설정 세부 사항은 그룹 채팅을 참조하십시오.

어드바이저리 분류 가이드:

"모델이 허용 목록에 없는 발신자의 인용 또는 과거 텍스트를 볼 수 있다"만 표시하는 주장은 contextVisibility로 해결할 수 있는 강화 결과이지, 그 자체로 인증 또는 샌드박스 경계 우회가 아닙니다.
보안 영향을 미치려면 보고서는 여전히 신뢰 경계 우회(인증, 정책, 샌드박스, 승인, 또는 다른 문서화된 경계)를 입증해야 합니다.

감사 확인 사항 (높은 수준)

인바운드 액세스 (DM 정책, 그룹 정책, 허용 목록): 낯선 사람이 봇을 트리거할 수 있습니까?
도구 폭발 반경 (상승된 도구 + 오픈 방): 프롬프트 주입이 셸/파일/네트워크 작업으로 전환될 수 있습니까?
Exec 승인 드리프트 (security=full, autoAllowSkills, strictInlineEval 없는 인터프리터 허용 목록): 호스트 exec 가드레일이 여전히 당신이 생각하는 대로 작동합니까?
- security="full"은 광범위한 자세 경고이지 버그의 증거가 아닙니다. 신뢰할 수 있는 개인 어시스턴트 설정을 위해 선택된 기본값입니다. 위협 모델이 승인 또는 허용 목록 가드레일을 필요로 할 때만 강화합니다.
네트워크 노출 (게이트웨이 바인드/인증, Tailscale Serve/Funnel, 약하거나 짧은 인증 토큰).
브라우저 제어 노출 (원격 노드, 릴레이 포트, 원격 CDP 엔드포인트).
로컬 디스크 위생 (권한, 심링크, 구성 포함, "동기화된 폴더" 경로).
플러그인 (명시적 허용 목록 없이 확장이 존재함).
정책 드리프트/잘못된 구성 (샌드박스 Docker 설정이 구성됐지만 샌드박스 모드가 꺼짐; 매칭이 정확한 명령 이름 전용(예: system.run)이고 셸 텍스트를 검사하지 않으므로 비효과적인 gateway.nodes.denyCommands 패턴; 위험한 gateway.nodes.allowCommands 항목; 에이전트별 프로필로 재정의된 전역 tools.profile="minimal"; 허용적 도구 정책에서 접근 가능한 확장 플러그인 도구).
런타임 기대 드리프트 (예: tools.exec.host가 이제 auto를 기본값으로 하는데 암묵적 exec가 여전히 sandbox를 의미한다고 가정하거나, 샌드박스 모드가 꺼진 상태에서 tools.exec.host="sandbox"를 명시적으로 설정).
모델 위생 (구성된 모델이 레거시처럼 보이면 경고; 하드 블록 없음).

--deep을 실행하면 OpenClaw는 최선의 라이브 게이트웨이 프로브도 시도합니다.

자격 증명 저장 맵

액세스를 감사하거나 백업할 항목을 결정할 때 사용합니다:

WhatsApp: ~/.openclaw/credentials/whatsapp/<accountId>/creds.json
Telegram 봇 토큰: 구성/env 또는 channels.telegram.tokenFile(일반 파일만; 심링크 거부됨)
Discord 봇 토큰: 구성/env 또는 SecretRef (env/file/exec 프로바이더)
Slack 토큰: 구성/env(channels.slack.*)
페어링 허용 목록:
- ~/.openclaw/credentials/<channel>-allowFrom.json (기본 계정)
- ~/.openclaw/credentials/<channel>-<accountId>-allowFrom.json (비기본 계정)
모델 인증 프로필: ~/.openclaw/agents/<agentId>/agent/auth-profiles.json
파일 기반 시크릿 페이로드 (선택 사항): ~/.openclaw/secrets.json
레거시 OAuth 임포트: ~/.openclaw/credentials/oauth.json

보안 감사 체크리스트

감사에서 결과가 출력될 때 이것을 우선순위 순서로 처리합니다:

"오픈" + 도구 활성화된 것: DM/그룹을 먼저 잠급니다(페어링/허용 목록), 그런 다음 도구 정책/샌드박싱을 강화합니다.
공개 네트워크 노출 (LAN 바인드, Funnel, 누락된 인증): 즉시 수정합니다.
브라우저 제어 원격 노출: 오퍼레이터 액세스처럼 취급합니다(tailnet 전용, 노드를 의도적으로 페어링, 공개 노출 피하기).
권한: 상태/구성/자격 증명/인증이 그룹/월드 읽기 가능하지 않은지 확인합니다.
플러그인/확장: 명시적으로 신뢰하는 것만 로드합니다.
모델 선택: 도구가 있는 모든 봇에 현대적, 명령 강화된 모델을 선호합니다.

보안 감사 용어집

실제 배포에서 가장 많이 볼 수 있는 고신호 checkId 값 (완전하지 않음):

`checkId`	심각도	중요한 이유	기본 수정 키/경로	자동 수정
`fs.state_dir.perms_world_writable`	치명적	다른 사용자/프로세스가 전체 OpenClaw 상태를 수정할 수 있음	`~/.openclaw`의 파일 시스템 권한	예
`fs.state_dir.perms_group_writable`	경고	그룹 사용자가 전체 OpenClaw 상태를 수정할 수 있음	`~/.openclaw`의 파일 시스템 권한	예
`fs.state_dir.perms_readable`	경고	상태 디렉터리가 다른 사람이 읽을 수 있음	`~/.openclaw`의 파일 시스템 권한	예
`fs.config.perms_writable`	치명적	다른 사람이 인증/도구 정책/구성을 변경할 수 있음	`~/.openclaw/openclaw.json`의 파일 시스템 권한	예
`fs.config.perms_world_readable`	치명적	구성이 토큰/설정을 노출할 수 있음	구성 파일의 파일 시스템 권한	예
`gateway.bind_no_auth`	치명적	공유 시크릿 없는 원격 바인드	`gateway.bind`, `gateway.auth.*`	아니요
`gateway.trusted_proxy_auth`	치명적	프록시 신원이 이제 인증 경계가 됨	`gateway.auth.mode="trusted-proxy"`	아니요
`gateway.tailscale_funnel`	치명적	공개 인터넷 노출	`gateway.tailscale.mode`	아니요
`tools.exec.security_full_configured`	경고/치명적	호스트 exec이 `security="full"`로 실행 중	`tools.exec.security`, `agents.list[].tools.exec.security`	아니요
`security.exposure.open_channels_with_exec`	경고/치명적	공유/공개 방이 exec 활성화된 에이전트에 접근할 수 있음	`channels..dmPolicy`, `channels..groupPolicy`, `tools.exec.*`	아니요
`logging.redact_off`	경고	민감한 값이 로그/상태로 누출됨	`logging.redactSensitive`	예
`plugins.extensions_no_allowlist`	경고	명시적 플러그인 허용 목록 없이 확장이 설치됨	`plugins.allowlist`	아니요

전체 감사 용어집은 원문 문서를 참조하십시오.

HTTP를 통한 Control UI

Control UI는 기기 신원을 생성하기 위해 보안 컨텍스트(HTTPS 또는 localhost)가 필요합니다. gateway.controlUi.allowInsecureAuth는 로컬 호환성 토글입니다:

localhost에서 페이지가 비보안 HTTP를 통해 로드될 때 기기 신원 없이 Control UI 인증을 허용합니다.
페어링 검사를 우회하지 않습니다.
원격(비 localhost) 기기 신원 요구 사항을 완화하지 않습니다.

HTTPS(Tailscale Serve) 또는 127.0.0.1에서 UI를 열기를 선호합니다.

비상 시나리오에만, gateway.controlUi.dangerouslyDisableDeviceAuth는 기기 신원 검사를 완전히 비활성화합니다. 이것은 심각한 보안 다운그레이드입니다. 적극적으로 디버깅하고 빠르게 되돌릴 수 있는 경우가 아니라면 꺼두십시오.

역방향 프록시 구성

역방향 프록시(nginx, Caddy, Traefik 등) 뒤에서 게이트웨이를 실행하는 경우 올바른 전달된 클라이언트 IP 처리를 위해 gateway.trustedProxies를 구성합니다.

게이트웨이가 trustedProxies에 없는 주소에서 프록시 헤더를 감지하면 연결을 로컬 클라이언트로 취급하지 않습니다. 게이트웨이 인증이 비활성화된 경우 해당 연결은 거부됩니다. 이것은 프록시된 연결이 그렇지 않으면 localhost에서 온 것처럼 보이고 자동 신뢰를 받는 인증 우회를 방지합니다.

yaml

gateway:
  trustedProxies:
    - "10.0.0.1" # 역방향 프록시 IP
  # 선택 사항. 기본값 false.
  # 프록시가 X-Forwarded-For를 제공할 수 없는 경우에만 활성화합니다.
  allowRealIpFallback: false
  auth:
    mode: password
    password: ${OPENCLAW_GATEWAY_PASSWORD}

좋은 역방향 프록시 동작(들어오는 전달 헤더 덮어쓰기):

nginx

proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;

나쁜 역방향 프록시 동작(신뢰할 수 없는 전달 헤더 추가/보존):

nginx

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

로컬 세션 로그가 디스크에 저장됨

OpenClaw는 세션 전사본을 ~/.openclaw/agents/<agentId>/sessions/*.jsonl 아래에 저장합니다. 이것은 세션 연속성과 (선택적으로) 세션 메모리 인덱싱에 필요하지만, 파일 시스템 액세스가 있는 모든 프로세스/사용자가 해당 로그를 읽을 수 있다는 것도 의미합니다. 디스크 액세스를 신뢰 경계로 취급하고 ~/.openclaw의 권한을 잠급니다. 에이전트 간에 더 강력한 격리가 필요한 경우 별도 OS 사용자 또는 별도 호스트에서 실행합니다.

노드 실행 (system.run)

macOS 노드가 페어링된 경우 게이트웨이는 해당 노드에서 system.run을 호출할 수 있습니다. 이것은 Mac에서의 원격 코드 실행입니다:

노드 페어링이 필요합니다(승인 + 토큰).
게이트웨이 노드 페어링은 명령별 승인 표면이 아닙니다. 노드 신원/신뢰와 토큰 발행을 설정합니다.
게이트웨이는 gateway.nodes.allowCommands / denyCommands를 통해 거칠은 전역 노드 명령 정책을 적용합니다.
Mac에서 설정 → Exec 승인(보안 + 요청 + 허용 목록)을 통해 제어됩니다.
원격 실행이 필요하지 않으면 보안을 거부로 설정하고 해당 Mac에 대한 노드 페어링을 제거합니다.

동적 skill (감시자/원격 노드)

OpenClaw는 세션 중간에 skill 목록을 새로 고칠 수 있습니다:

Skill 감시자: SKILL.md의 변경 사항은 다음 에이전트 턴에서 skill 스냅샷을 업데이트할 수 있습니다.
원격 노드: macOS 노드를 연결하면 macOS 전용 skill이 적격해질 수 있습니다(바이너리 프로빙 기반).

skill 폴더를 신뢰할 수 있는 코드로 취급하고 수정할 수 있는 사람을 제한합니다.

위협 모델

AI 어시스턴트는 다음을 수행할 수 있습니다:

임의 셸 명령 실행
파일 읽기/쓰기
네트워크 서비스 액세스
누구에게나 메시지 전송(WhatsApp 액세스를 제공한 경우)

당신에게 메시지를 보내는 사람들은:

AI를 나쁜 일을 하도록 속이려 할 수 있습니다
데이터에 대한 액세스를 소셜 엔지니어링할 수 있습니다
인프라 세부 사항을 탐색할 수 있습니다

핵심 개념: 지능 전에 액세스 제어

여기서 대부분의 실패는 화려한 악용이 아닙니다. "누군가가 봇에 메시지를 보냈고 봇이 요청받은 것을 했다"입니다.

OpenClaw의 입장:

신원 우선: 봇과 이야기할 수 있는 사람을 결정합니다(DM 페어링 / 허용 목록 / 명시적 "오픈").
다음은 범위: 봇이 행동할 수 있는 위치를 결정합니다(그룹 허용 목록 + 언급 게이팅, 도구, 샌드박싱, 기기 권한).
모델은 마지막: 모델이 조작될 수 있다고 가정하고, 조작의 폭발 반경이 제한되도록 설계합니다.

명령 권한 부여 모델

슬래시 명령 및 지시어는 권한이 부여된 발신자에 대해서만 준수됩니다. 권한 부여는 채널 허용 목록/페어링과 commands.useAccessGroups에서 파생됩니다(구성 및 슬래시 명령 참조). 채널 허용 목록이 비어 있거나 "*"를 포함하면 해당 채널에 대해 명령이 효과적으로 열립니다.

/exec는 권한이 부여된 오퍼레이터를 위한 세션 전용 편의 기능입니다. 구성을 쓰거나 다른 세션을 변경하지 않습니다.

제어 플레인 도구 위험

두 가지 내장 도구는 영구적인 제어 플레인 변경을 할 수 있습니다:

gateway는 config.schema.lookup / config.get으로 구성을 검사하고, config.apply, config.patch, update.run으로 영구적 변경을 할 수 있습니다.
cron은 원래 채팅/작업이 종료된 후에도 계속 실행되는 예약된 작업을 만들 수 있습니다.

신뢰할 수 없는 콘텐츠를 처리하는 모든 에이전트/표면에 대해 기본적으로 이것들을 거부합니다:

json5

{
  tools: {
    deny: ["gateway", "cron", "sessions_spawn", "sessions_send"],
  },
}

플러그인/확장

플러그인은 게이트웨이와 인프로세스로 실행됩니다. 신뢰할 수 있는 코드로 취급합니다:

신뢰하는 소스에서만 플러그인을 설치합니다.
명시적 plugins.allow 허용 목록을 선호합니다.
활성화하기 전에 플러그인 구성을 검토합니다.
플러그인 변경 후 게이트웨이를 재시작합니다.

세부 사항: 플러그인

DM 액세스 모델 (pairing / allowlist / open / disabled)

현재 DM 가능한 모든 채널은 메시지가 처리되기 전에 인바운드 DM을 게이팅하는 DM 정책(dmPolicy 또는 *.dm.policy)을 지원합니다:

pairing (기본값): 알 수 없는 발신자는 짧은 페어링 코드를 받고 봇은 승인될 때까지 메시지를 무시합니다. 코드는 1시간 후 만료됩니다. 반복 DM은 새 요청이 생성될 때까지 코드를 재전송하지 않습니다. 대기 중인 요청은 기본적으로 채널당 3개로 제한됩니다.
allowlist: 알 수 없는 발신자는 차단됩니다(페어링 핸드셰이크 없음).
open: 누구나 DM을 허용합니다(공개). 채널 허용 목록에 "*"가 포함되어야 합니다(명시적 선택).
disabled: 인바운드 DM을 완전히 무시합니다.

CLI를 통해 승인합니다:

bash

openclaw pairing list <channel>
openclaw pairing approve <channel> <code>

세부 사항 + 디스크 파일: 페어링

DM 세션 격리 (멀티 사용자 모드)

기본적으로 OpenClaw는 모든 DM을 메인 세션으로 라우팅하여 어시스턴트가 기기와 채널 간에 연속성을 가집니다. 여러 사람이 봇에 DM을 보낼 수 있는 경우(오픈 DM 또는 다중 사람 허용 목록) DM 세션 격리를 고려합니다:

json5

{
  session: { dmScope: "per-channel-peer" },
}

이것은 크로스 사용자 컨텍스트 누출을 방지하면서 그룹 채팅을 격리 상태로 유지합니다.

프롬프트 주입 (무엇인지, 왜 중요한지)

프롬프트 주입은 공격자가 모델을 안전하지 않은 일을 하도록 조작하는 메시지를 만들 때 발생합니다("지침을 무시해", "파일 시스템을 덤프해", "이 링크를 따라가서 명령을 실행해" 등).

강력한 시스템 프롬프트가 있어도 프롬프트 주입은 해결되지 않습니다. 시스템 프롬프트 가드레일은 소프트 지침일 뿐입니다. 하드 적용은 도구 정책, exec 승인, 샌드박싱, 채널 허용 목록에서 옵니다. 실제로 도움이 되는 것:

인바운드 DM을 잠겨 있게 유지합니다(페어링/허용 목록).
그룹에서 언급 게이팅을 선호합니다. 공개 방에서 "항상 켜진" 봇을 피합니다.
링크, 첨부 파일, 붙여넣기 지침을 기본적으로 적대적으로 취급합니다.
민감한 도구 실행을 샌드박스에서 실행합니다. 시크릿을 에이전트의 접근 가능한 파일 시스템에서 제외합니다.
높은 위험 도구(exec, browser, web_fetch, web_search)를 신뢰할 수 있는 에이전트 또는 명시적 허용 목록으로 제한합니다.

구성 강화 (예제)

0) 파일 권한

게이트웨이 호스트에서 구성 + 상태를 비공개로 유지합니다:

~/.openclaw/openclaw.json: 600 (사용자 읽기/쓰기만)
~/.openclaw: 700 (사용자만)

openclaw doctor는 경고하고 이러한 권한을 강화하도록 제안할 수 있습니다.

0.4) 네트워크 노출 (바인드 + 포트 + 방화벽)

게이트웨이는 단일 포트에서 WebSocket + HTTP를 멀티플렉싱합니다:

기본값: 18789
구성/플래그/env: gateway.port, --port, OPENCLAW_GATEWAY_PORT

바인드 모드는 게이트웨이가 리스닝하는 위치를 제어합니다:

gateway.bind: "loopback" (기본값): 로컬 클라이언트만 연결할 수 있습니다.
비루프백 바인드("lan", "tailnet", "custom")는 공격 표면을 넓힙니다. 게이트웨이 인증(공유 토큰/비밀번호 또는 올바르게 구성된 비루프백 신뢰할 수 있는 프록시)과 실제 방화벽이 있는 경우에만 사용합니다.

경험칙:

LAN 바인드 대신 Tailscale Serve를 선호합니다(Serve는 게이트웨이를 루프백에 유지하고 Tailscale이 액세스를 처리합니다).
LAN에 바인딩해야 하는 경우 소스 IP의 엄격한 허용 목록으로 포트를 방화벽 처리합니다. 광범위하게 포트 포워딩하지 마십시오.
0.0.0.0에서 인증 없이 게이트웨이를 절대 노출하지 마십시오.

0.5) 게이트웨이 WebSocket 잠금 (로컬 인증)

게이트웨이 인증은 기본적으로 필수입니다. 유효한 게이트웨이 인증 경로가 구성되지 않으면 게이트웨이는 WebSocket 연결을 거부합니다(페일 클로즈).

모든 WS 클라이언트가 인증하도록 토큰을 설정합니다:

json5

{
  gateway: {
    auth: { mode: "token", token: "your-token" },
  },
}

Doctor가 하나를 생성할 수 있습니다: openclaw doctor --generate-gateway-token.

인증 모드:

gateway.auth.mode: "token": 공유 Bearer 토큰 (대부분의 설정에 권장).
gateway.auth.mode: "password": 비밀번호 인증 (env를 통해 설정 선호: OPENCLAW_GATEWAY_PASSWORD).
gateway.auth.mode: "trusted-proxy": 신뢰할 수 있는 신원 인식 역방향 프록시가 사용자를 인증하고 헤더를 통해 신원을 전달하도록 신뢰합니다 (신뢰할 수 있는 프록시 인증 참조).

교체 체크리스트(토큰/비밀번호):

새 시크릿을 생성/설정합니다(gateway.auth.token 또는 OPENCLAW_GATEWAY_PASSWORD).
게이트웨이를 재시작합니다(또는 macOS 앱이 게이트웨이를 감독하는 경우 macOS 앱을 재시작합니다).
게이트웨이를 호출하는 모든 머신에서 원격 클라이언트를 업데이트합니다(gateway.remote.token / .password).
이전 자격 증명으로 더 이상 연결할 수 없음을 확인합니다.

0.7) 디스크의 시크릿 (민감한 데이터)

~/.openclaw/(또는 $OPENCLAW_STATE_DIR/) 아래의 모든 것이 시크릿이나 개인 데이터를 포함할 수 있다고 가정합니다:

openclaw.json: 구성에 토큰(게이트웨이, 원격 게이트웨이), 프로바이더 설정, 허용 목록이 포함될 수 있습니다.
credentials/**: 채널 자격 증명(예: WhatsApp creds), 페어링 허용 목록, 레거시 OAuth 임포트.
agents/<agentId>/agent/auth-profiles.json: API 키, 토큰 프로필, OAuth 토큰.
agents/<agentId>/sessions/**: 개인 메시지와 도구 출력을 포함할 수 있는 세션 전사본.

강화 팁:

권한을 엄격하게 유지합니다(디렉터리는 700, 파일은 600).
게이트웨이 호스트에서 전체 디스크 암호화를 사용합니다.
호스트가 공유된 경우 게이트웨이에 전용 OS 사용자 계정을 선호합니다.

0.8) 로그 + 전사본 (수정 + 보존)

로그와 전사본은 액세스 제어가 올바른 경우에도 민감한 정보를 누출할 수 있습니다:

게이트웨이 로그에 도구 요약, 오류, URL이 포함될 수 있습니다.
세션 전사본에는 붙여넣기된 시크릿, 파일 내용, 명령 출력, 링크가 포함될 수 있습니다.

권장 사항:

도구 요약 수정을 켜두십시오(logging.redactSensitive: "tools"; 기본값).
logging.redactPatterns를 통해 환경에 맞는 사용자 지정 패턴을 추가합니다(토큰, 호스트 이름, 내부 URL).
진단 공유 시 원시 로그 대신 openclaw status --all을 선호합니다(붙여넣기 가능, 시크릿 수정됨).

세부 사항: 로깅

1) DM: 기본적으로 페어링

json5

{
  channels: { whatsapp: { dmPolicy: "pairing" } },
}

2) 그룹: 모든 곳에서 언급 필요

json

{
  "channels": {
    "whatsapp": {
      "groups": {
        "*": { "requireMention": true }
      }
    }
  },
  "agents": {
    "list": [
      {
        "id": "main",
        "groupChat": { "mentionPatterns": ["@openclaw", "@mybot"] }
      }
    ]
  }
}

그룹 채팅에서 명시적으로 언급될 때만 응답합니다.

3) 별도 번호 (WhatsApp, Signal, Telegram)

전화번호 기반 채널의 경우 개인 번호와 별도의 전화번호로 AI를 실행하는 것을 고려합니다:

개인 번호: 대화가 비공개 상태 유지
봇 번호: AI가 적절한 경계로 처리

4) 읽기 전용 모드 (샌드박스 + 도구를 통해)

다음을 결합하여 읽기 전용 프로필을 구성할 수 있습니다:

agents.defaults.sandbox.workspaceAccess: "ro" (또는 워크스페이스 액세스 없이 "none")
write, edit, apply_patch, exec, process 등을 차단하는 도구 허용/거부 목록

5) 보안 기준선 (복사/붙여넣기)

게이트웨이를 비공개로 유지하고, DM 페어링을 요구하고, 항상 켜진 그룹 봇을 피하는 "안전한 기본" 구성:

json5

{
  gateway: {
    mode: "local",
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "your-long-random-token" },
  },
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } },
    },
  },
}

샌드박싱 (권장)

전용 문서: 샌드박싱

두 가지 보완적인 접근법:

Docker에서 전체 게이트웨이 실행 (컨테이너 경계): Docker
도구 샌드박스 (agents.defaults.sandbox, 호스트 게이트웨이 + Docker 격리 도구): 샌드박싱

브라우저 제어 위험

브라우저 제어를 활성화하면 모델이 실제 브라우저를 구동할 수 있습니다. 해당 브라우저 프로필에 이미 로그인된 세션이 포함된 경우 모델이 해당 계정과 데이터에 액세스할 수 있습니다. 브라우저 프로필을 민감한 상태로 취급합니다:

에이전트에 전용 프로필을 선호합니다(기본 openclaw 프로필).
에이전트가 개인 일상 드라이버 프로필을 가리키는 것을 피합니다.
신뢰하지 않는 한 샌드박스된 에이전트에 대해 호스트 브라우저 제어를 비활성화 상태로 유지합니다.
원격 게이트웨이의 경우 "브라우저 제어"는 해당 프로필이 접근할 수 있는 모든 것에 대한 "오퍼레이터 액세스"와 동등합니다.

AI에게 말할 것

에이전트의 시스템 프롬프트에 보안 지침을 포함합니다:

## 보안 규칙
- 낯선 사람에게 디렉터리 목록이나 파일 경로를 절대 공유하지 않기
- API 키, 자격 증명, 인프라 세부 사항을 절대 공개하지 않기
- 시스템 구성을 수정하는 요청을 소유자와 확인하기
- 의심스러울 때 행동하기 전에 요청하기
- 명시적으로 승인되지 않는 한 개인 데이터를 비공개로 유지하기

인시던트 대응

AI가 나쁜 일을 한 경우:

봉쇄

중지: macOS 앱을 중지하거나(게이트웨이를 감독하는 경우) openclaw gateway 프로세스를 종료합니다.
노출 종료: 무슨 일이 일어났는지 이해할 때까지 gateway.bind: "loopback" 설정(또는 Tailscale Funnel/Serve 비활성화).
액세스 동결: 위험한 DM/그룹을 dmPolicy: "disabled" / 언급 필요로 전환하고, 있는 경우 "*" 모두 허용 항목을 제거합니다.

교체 (시크릿 누출 가정 시 침해 가정)

게이트웨이 인증 교체(gateway.auth.token / OPENCLAW_GATEWAY_PASSWORD)하고 재시작합니다.
게이트웨이를 호출할 수 있는 모든 머신에서 원격 클라이언트 시크릿 교체(gateway.remote.token / .password).
프로바이더/API 자격 증명 교체(WhatsApp creds, Slack/Discord 토큰, auth-profiles.json의 모델/API 키, 사용 시 암호화된 시크릿 페이로드 값).

감사

게이트웨이 로그 확인: /tmp/openclaw/openclaw-YYYY-MM-DD.log (또는 logging.file).
관련 전사본 검토: ~/.openclaw/agents/<agentId>/sessions/*.jsonl.
최근 구성 변경 검토(액세스를 넓혔을 수 있는 것: gateway.bind, gateway.auth, dm/그룹 정책, tools.elevated, 플러그인 변경).
openclaw security audit --deep를 다시 실행하고 치명적 결과가 해결됐는지 확인합니다.

보안 문제 보고

OpenClaw에서 취약점을 발견하셨습니까? 책임감 있게 보고하십시오:

이메일: security@openclaw.ai
수정될 때까지 공개적으로 게시하지 마십시오

보안 ​

범위 우선: 개인 어시스턴트 보안 모델 ​

빠른 확인: openclaw security audit ​

배포 및 호스트 신뢰 ​

공유 Slack 워크스페이스: 실제 위험 ​

회사 공유 에이전트: 허용 가능한 패턴 ​

게이트웨이 및 노드 신뢰 개념 ​

신뢰 경계 매트릭스 ​

설계상 취약점이 아닌 것 ​

연구원 사전 비행 체크리스트 ​

60초 강화된 기준선 ​

공유 받은 편지함 빠른 규칙 ​

컨텍스트 가시성 모델 ​

감사 확인 사항 (높은 수준) ​

자격 증명 저장 맵 ​

보안 감사 체크리스트 ​

보안 감사 용어집 ​

HTTP를 통한 Control UI ​

역방향 프록시 구성 ​

로컬 세션 로그가 디스크에 저장됨 ​

노드 실행 (system.run) ​

동적 skill (감시자/원격 노드) ​

위협 모델 ​

핵심 개념: 지능 전에 액세스 제어 ​

명령 권한 부여 모델 ​

제어 플레인 도구 위험 ​

플러그인/확장 ​

DM 액세스 모델 (pairing / allowlist / open / disabled) ​

DM 세션 격리 (멀티 사용자 모드) ​

프롬프트 주입 (무엇인지, 왜 중요한지) ​

구성 강화 (예제) ​

0) 파일 권한 ​

0.4) 네트워크 노출 (바인드 + 포트 + 방화벽) ​

0.5) 게이트웨이 WebSocket 잠금 (로컬 인증) ​

0.7) 디스크의 시크릿 (민감한 데이터) ​

0.8) 로그 + 전사본 (수정 + 보존) ​

1) DM: 기본적으로 페어링 ​

2) 그룹: 모든 곳에서 언급 필요 ​

3) 별도 번호 (WhatsApp, Signal, Telegram) ​

4) 읽기 전용 모드 (샌드박스 + 도구를 통해) ​

5) 보안 기준선 (복사/붙여넣기) ​

샌드박싱 (권장) ​

브라우저 제어 위험 ​

AI에게 말할 것 ​

인시던트 대응 ​

봉쇄 ​

교체 (시크릿 누출 가정 시 침해 가정) ​

감사 ​

보안 문제 보고 ​

보안

범위 우선: 개인 어시스턴트 보안 모델

빠른 확인: `openclaw security audit`

배포 및 호스트 신뢰

공유 Slack 워크스페이스: 실제 위험

회사 공유 에이전트: 허용 가능한 패턴

게이트웨이 및 노드 신뢰 개념

신뢰 경계 매트릭스

설계상 취약점이 아닌 것

연구원 사전 비행 체크리스트

60초 강화된 기준선

공유 받은 편지함 빠른 규칙

컨텍스트 가시성 모델

감사 확인 사항 (높은 수준)

자격 증명 저장 맵

보안 감사 체크리스트

보안 감사 용어집

HTTP를 통한 Control UI

역방향 프록시 구성

로컬 세션 로그가 디스크에 저장됨

노드 실행 (system.run)

동적 skill (감시자/원격 노드)

위협 모델

핵심 개념: 지능 전에 액세스 제어

명령 권한 부여 모델

제어 플레인 도구 위험

플러그인/확장

DM 액세스 모델 (pairing / allowlist / open / disabled)

DM 세션 격리 (멀티 사용자 모드)

프롬프트 주입 (무엇인지, 왜 중요한지)

구성 강화 (예제)

0) 파일 권한

0.4) 네트워크 노출 (바인드 + 포트 + 방화벽)

0.5) 게이트웨이 WebSocket 잠금 (로컬 인증)

0.7) 디스크의 시크릿 (민감한 데이터)

0.8) 로그 + 전사본 (수정 + 보존)

1) DM: 기본적으로 페어링

2) 그룹: 모든 곳에서 언급 필요

3) 별도 번호 (WhatsApp, Signal, Telegram)

4) 읽기 전용 모드 (샌드박스 + 도구를 통해)

5) 보안 기준선 (복사/붙여넣기)

샌드박싱 (권장)

브라우저 제어 위험

AI에게 말할 것

인시던트 대응

봉쇄

교체 (시크릿 누출 가정 시 침해 가정)

감사

보안 문제 보고