> ## Documentation Index > Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt > Use this file to discover all available pages before exploring further. # Безпека **Модель довіри особистого помічника.** Ці настанови передбачають одну довірену межу оператора на кожен Gateway (однокористувацька модель особистого помічника). OpenClaw **не** є захищеною межею для ворожого багатокористувацького середовища, де кілька зловмисних користувачів спільно використовують одного агента або Gateway. Для роботи з різними рівнями довіри або зловмисними користувачами розділіть межі довіри: окремі Gateway + облікові дані, а в ідеалі — окремі користувачі ОС або хости. ## Область застосування: модель безпеки особистого помічника * Підтримується: один користувач/одна межа довіри на кожен Gateway (бажано один користувач ОС/хост/VPS на межу). * Не підтримується: один спільний Gateway/агент, яким користуються взаємно недовірені або зловмисні користувачі. * Для ізоляції зловмисних користувачів потрібні окремі Gateway (а в ідеалі — окремі користувачі ОС/хости). * Якщо кілька недовірених користувачів можуть надсилати повідомлення одному агенту з увімкненими інструментами, вони спільно використовують делеговані цьому агенту повноваження інструментів. * Якщо хтось може змінювати стан або конфігурацію хоста Gateway (`~/.openclaw`, зокрема `openclaw.json`), вважайте цю особу довіреним оператором. * У межах одного Gateway автентифікований доступ оператора є довіреною роллю площини керування, а не роллю окремого користувача-орендаря. * `sessionKey` (ідентифікатори сеансів, мітки) — це селектор маршрутизації, а не токен авторизації. Розміщуєте кількох користувачів або організації? Запускайте окрему ізольовану комірку Gateway для кожного орендаря замість спільного використання Gateway. Див. [Багатокористувацьке розміщення](/gateway/multi-tenant-hosting). Перш ніж змінювати віддалений доступ, політику особистих повідомлень, зворотний проксі або публічну доступність, скористайтеся [інструкцією з відкриття доступу до Gateway](/uk/gateway/security/exposure-runbook) як контрольним списком попередньої перевірки та відкату. ## `openclaw security audit` Запускайте це після будь-якої зміни конфігурації або перед відкриттям мережевих поверхонь: ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw security audit openclaw security audit --deep # намагається виконати активну перевірку Gateway openclaw security audit --fix # застосовує безпечні виправлення openclaw security audit --json ``` `--fix` навмисно має вузьку область дії: він змінює відкриті групові політики на списки дозволених, відновлює `logging.redactSensitive: "tools"`, посилює дозволи для файлів стану/конфігурації/підключень (файли `600`, каталоги `700`), а у Windows використовує скидання ACL замість POSIX `chmod`. ### Що перевіряє аудит (загалом) * **Вхідний доступ** — політики особистих повідомлень/груп і списки дозволених: чи можуть сторонні особи активувати бота? * **Радіус ураження інструментів** — інструменти з підвищеними привілеями та відкриті кімнати: чи може ін’єкція підказки призвести до дій із командною оболонкою, файлами або мережею? * **Відхилення доступу до файлової системи під час виконання** — інструменти зміни файлової системи заборонено, тоді як `exec`/`process` залишаються доступними без обмежень пісочниці. * **Відхилення схвалень виконання** — `security="full"`, `autoAllowSkills`, списки дозволених інтерпретаторів без `strictInlineEval`. Сам по собі `security="full"` є загальним попередженням про режим безпеки, а не доказом помилки — це вибране типове значення для довірених середовищ особистого помічника; посилюйте його лише тоді, коли ваша модель загроз потребує обмежень схвалення або списків дозволених. * **Мережева доступність** — прив’язка/автентифікація Gateway, Tailscale Serve/Funnel, слабкі або короткі токени автентифікації. * **Доступність керування браузером** — віддалені вузли, порти ретрансляції, віддалені кінцеві точки CDP. * **Гігієна локального диска** — дозволи, символічні посилання, підключення конфігурації, шляхи синхронізованих папок. * **Плагіни** — завантаження без явного списку дозволених. * **Відхилення політик** — параметри Docker для пісочниці налаштовано, але режим пісочниці вимкнено; записи `gateway.nodes.denyCommands`, які видаються дієвими, але відповідають лише точним ідентифікаторам команд (наприклад, `system.run`), а не тексту командної оболонки всередині корисного навантаження; небезпечні записи `gateway.nodes.allowCommands`; глобальний `tools.profile="minimal"` перевизначено для окремого агента; інструменти, що належать плагінам, доступні за дозвільної політики. * **Відхилення очікувань середовища виконання** — припущення, що неявне виконання досі означає `sandbox`, хоча `tools.exec.host` тепер типово має значення `auto`, або налаштування `tools.exec.host="sandbox"`, коли режим пісочниці вимкнено. * **Гігієна моделей** — попереджає про налаштовані застарілі моделі (м’яке попередження, а не жорстке блокування). Кожне виявлене порушення має структурований `checkId` (наприклад, `gateway.bind_no_auth`, `tools.exec.security_full_configured`). Префікси: `fs.*` (дозволи), `gateway.*` (прив’язка/автентифікація/Tailscale/інтерфейс керування/довірений проксі), `hooks.*`/`browser.*`/`sandbox.*`/`tools.exec.*` (посилення захисту окремих поверхонь), `plugins.*`/`skills.*` (ланцюг постачання), `security.exposure.*` (політика доступу × радіус ураження інструментів). Повний каталог із рівнями серйозності та підтримкою автоматичного виправлення: [Перевірки аудиту безпеки](/uk/gateway/security/audit-checks). Див. також [Формальна верифікація](/uk/security/formal-verification). ### Порядок пріоритетів під час опрацювання виявлених порушень 1. Будь-що «відкрите» з увімкненими інструментами: спочатку обмежте особисті повідомлення/групи (створення пар/списки дозволених), потім посильте політику інструментів і пісочницю. 2. Публічна мережева доступність (прив’язка до LAN, Funnel, відсутня автентифікація): виправте негайно. 3. Віддалена доступність керування браузером: ставтеся до неї як до доступу оператора (лише через tailnet, свідомо створюйте пари з вузлами, не відкривайте публічний доступ). 4. Дозволи: стан/конфігурація/облікові дані/дані автентифікації не повинні бути доступними для читання групі або всім користувачам. 5. Плагіни: завантажуйте лише ті, яким явно довіряєте. 6. Вибір моделі: для будь-якого бота з інструментами віддавайте перевагу сучасним моделям, стійким до маніпуляцій інструкціями. ## Посилена базова конфігурація за 60 секунд ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { 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 } } }, }, } ``` Залишає Gateway доступним лише локально, ізолює особисті повідомлення та типово вимикає інструменти площини керування й середовища виконання. Після цього вибірково знову вмикайте інструменти для кожного довіреного агента. Вбудована базова політика для запусків агента, ініційованих у чаті: відправники, які не є власниками, не можуть використовувати інструменти `cron` або `gateway` незалежно від конфігурації. ## Матриця меж довіри Коротка модель для опрацювання звітів про ризики: | Межа або засіб контролю | Що це означає | Поширене хибне тлумачення | | ---------------------------------------------------------------------- | --------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | `gateway.auth` (токен/пароль/довірений проксі/автентифікація пристрою) | Автентифікує клієнтів API Gateway | «Для безпеки потрібні підписи кожного повідомлення в кожному кадрі» | | `sessionKey` | Ключ маршрутизації для вибору контексту/сеансу | «Ключ сеансу є межею автентифікації користувача» | | Обмеження підказок/вмісту | Зменшують ризик зловживання моделлю | «Самої ін’єкції підказки достатньо, щоб довести обхід автентифікації» | | `canvas.eval` / обчислення в браузері | Свідомо надана можливість оператора, коли її ввімкнено | «Будь-яка можливість виконання JS автоматично є вразливістю в цій моделі довіри» | | Локальна командна оболонка TUI `!` | Локальне виконання, явно запущене оператором | «Зручна локальна команда оболонки є віддаленою ін’єкцією» | | Створення пар із вузлами та команди вузлів | Віддалене виконання рівня оператора на спарених пристроях | «Керування віддаленим пристроєм типово слід вважати доступом недовіреного користувача» | | `gateway.nodes.pairing.autoApproveCidrs` | Добровільна політика реєстрації вузлів у довіреній мережі | «Типово вимкнений список дозволених автоматично створює вразливість у створенні пар» | | `gateway.nodes.pairing.sshVerify` | Реєстрація вузла з перевіркою ключа через SSH оператора | «Типово ввімкнене автоматичне схвалення автоматично створює вразливість у створенні пар» | ## За задумом не є вразливостями * Ланцюжки, що ґрунтуються лише на ін’єкції підказки, без обходу політики, автентифікації або пісочниці. * Твердження, що передбачають роботу ворожого багатокористувацького середовища на одному спільному хості або з однією конфігурацією. * Звичайний доступ оператора до шляхів читання (наприклад, `sessions.list` / `sessions.preview` / `chat.history`), класифікований як IDOR у конфігурації зі спільним Gateway. * Знахідки для розгортання лише на localhost (наприклад, відсутність HSTS у Gateway, доступному лише через loopback). * Знахідки щодо підпису вхідного Webhook Discord для вхідних шляхів, яких у цьому репозиторії немає. * Метадані створення пари з вузлом, які розглядають як прихований другий рівень схвалення кожної команди для `system.run`; справжньою межею виконання є глобальна політика команд вузлів Gateway разом із власними схваленнями виконання вузла. * `gateway.nodes.pairing.sshVerify`, який розглядають як вразливість через те, що він типово ввімкнений. Він ніколи не схвалює лише на підставі мережевого розташування або доступності через SSH: Gateway зчитує ідентичність пристрою через SSH (BatchMode, сувора перевірка ключів хоста) і схвалює лише за точного збігу ключа пристрою з очікуваним запитом, а для цього ключова пара підключення вже має бути в обліковому записі оператора на хості, який контролює оператор. Перевірки обмежені приватними/CGNAT-адресами джерела, мають спільний мінімальний критерій придатності довіреного CIDR (лише свіжий `role: node` без областей), а `sshVerify: false` вимикає цю функцію. * `gateway.nodes.pairing.autoApproveCidrs`, який сам по собі розглядають як вразливість. Він типово вимкнений, потребує явних записів CIDR/IP, застосовується лише до першого створення пари `role: node` без запитаних областей і ніколи автоматично не схвалює оператора/браузер/інтерфейс керування, WebChat, підвищення ролі/області, зміни метаданих або відкритого ключа, а також локальні loopback-шляхи заголовків довіреного проксі на тому самому хості (навіть коли автентифікацію довіреного проксі через loopback увімкнено). * Знахідки «відсутньої авторизації для кожного користувача», які розглядають `sessionKey` як токен автентифікації. ## Довіра між Gateway і вузлом Вважайте Gateway і вузол одним доменом довіри оператора з різними ролями: * **Gateway**: площина керування та поверхня політик (`gateway.auth`, політика інструментів, маршрутизація). * **Вузол**: поверхня віддаленого виконання, спарена з цим Gateway (команди, дії пристрою, локальні можливості хоста). * Клієнту, автентифікованому в Gateway, довіряють у межах Gateway; після створення пари дії вузла є довіреними діями оператора на цьому вузлі. Див. [Області оператора](/uk/gateway/operator-scopes). * Безпосередні клієнти серверної частини через loopback, автентифіковані за допомогою спільного токена/пароля Gateway, можуть виконувати внутрішні RPC площини керування без надання ідентичності користувацького пристрою. Це не обхід віддаленого або браузерного створення пари — мережеві клієнти, клієнти вузлів, клієнти з токенами пристроїв і явно задані ідентичності пристроїв усе одно проходять перевірки створення пари та підвищення області. * Схвалення виконання (список дозволених + запит) — це обмеження для намірів оператора, а не ізоляція ворожого багатокористувацького середовища. Вони прив’язують точний контекст запиту та, наскільки можливо, прямі локальні файлові операнди; вони не моделюють семантично кожен шлях завантажувача середовища виконання/інтерпретатора. Для надійних меж використовуйте пісочницю та ізоляцію хоста. * Типова конфігурація для довіреного єдиного оператора: виконання на хості в `gateway`/`node` дозволено без запитів на схвалення (`security="full"`, `ask="off"`). Це навмисне рішення щодо взаємодії з користувачем, а не вразливість саме по собі. Для ізоляції від ворожих користувачів розділіть межі довіри за користувачами ОС/хостами та запускайте окремі Gateway. ## Модель загроз Ваш ШІ-асистент може виконувати довільні команди оболонки, читати й записувати файли, отримувати доступ до мережевих служб і надсилати повідомлення будь-кому (якщо йому надано доступ до каналу). Люди, які надсилають йому повідомлення, можуть спробувати обманом змусити його робити щось шкідливе, за допомогою соціальної інженерії отримати доступ до ваших даних або дослідити деталі інфраструктури. Більшість збоїв тут — не екзотичні експлойти, а ситуації на кшталт «хтось написав боту, і бот зробив те, про що його попросили». Позиція OpenClaw у порядку пріоритетності: 1. **Спочатку ідентичність** — визначте, хто може спілкуватися з ботом (сполучення в особистих повідомленнях / списки дозволених / явний режим «відкрито»). 2. **Потім область дії** — визначте, де бот може діяти (списки дозволених груп + активація згадкою, інструменти, ізоляція в пісочниці, дозволи пристрою). 3. **Модель — насамкінець** — вважайте, що моделлю можна маніпулювати; проєктуйте систему так, щоб наслідки маніпуляції були обмеженими. ## Доступ до особистих повідомлень: сполучення, список дозволених, відкритий режим, вимкнення Кожен канал із підтримкою особистих повідомлень підтримує `dmPolicy` (або `*.dm.policy`), що обмежує вхідні особисті повідомлення до їх обробки: | Політика | Поведінка | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `pairing` | Типове значення. Невідомі відправники отримують код сполучення; бот ігнорує їх до схвалення. Термін дії кодів спливає через 1 годину; повторні особисті повідомлення не спричиняють повторного надсилання коду, доки не буде створено новий запит. Кількість запитів в очікуванні обмежена до 3 на канал. | | `allowlist` | Невідомі відправники заблоковані, процедура сполучення відсутня. | | `open` | Будь-хто може надсилати особисті повідомлення (публічний режим). Список дозволених каналу має містити `"*"` (явна згода). | | `disabled` | Вхідні особисті повідомлення повністю ігноруються. | ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw pairing list openclaw pairing approve ``` Докладніше та розташування файлів на диску: [Сполучення](/uk/channels/pairing) Вважайте `dmPolicy="open"` і `groupPolicy="open"` налаштуваннями на крайній випадок; віддавайте перевагу сполученню та спискам дозволених, якщо не довіряєте повністю кожному учаснику кімнати. ### Списки дозволених (два рівні) * **Список дозволених для особистих повідомлень** (`allowFrom` / `channels.discord.allowFrom` / `channels.slack.allowFrom`; застарілі: `channels.discord.dm.allowFrom`, `channels.slack.dm.allowFrom`): хто може надсилати боту особисті повідомлення. Коли `dmPolicy="pairing"`, схвалення записуються до `~/.openclaw/credentials/-allowFrom.json` (типовий обліковий запис) або `--allowFrom.json` (нетипові облікові записи) та об’єднуються зі списками дозволених із конфігурації. * **Список дозволених груп** (залежить від каналу): які групи, канали або сервери бот узагалі приймає. * `channels.whatsapp.groups`, `channels.telegram.groups`, `channels.imessage.groups`: типові параметри окремих груп, як-от `requireMention`; якщо їх задано, вони також діють як список дозволених груп (додайте `"*"`, щоб зберегти дозвіл для всіх). Налаштуйте тригери згадування за допомогою `agents.list[].groupChat.mentionPatterns` (наприклад, `["@openclaw", "@mybot"]`), щоб `requireMention` активувався за вашими власними іменами бота. * `groupPolicy="allowlist"` + `groupAllowFrom`: обмежують, хто може активувати бота в межах групового сеансу (WhatsApp/Telegram/Signal/iMessage/Microsoft Teams). * `channels.discord.guilds` / `channels.slack.channels`: окремі списки дозволених і типові параметри згадування для кожної поверхні. * Порядок перевірки: спочатку `groupPolicy`/списки дозволених груп, потім активація згадкою або відповіддю. Відповідь на повідомлення бота (неявна згадка) **не** обходить `groupAllowFrom`. Докладніше: [Конфігурація](/uk/gateway/configuration) і [Групи](/uk/channels/groups) ### Ізоляція сеансів особистих повідомлень (багатокористувацький режим) За замовчуванням OpenClaw спрямовує всі особисті повідомлення до основного сеансу, забезпечуючи безперервність між пристроями. Якщо кілька людей можуть надсилати боту особисті повідомлення (відкриті особисті повідомлення або список дозволених із кількома особами), ізолюйте сеанси особистих повідомлень: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { session: { dmScope: "per-channel-peer" } } ``` Значення `session.dmScope`: | Значення | Область | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | `main` (типове значення конфігурації) | Усі особисті повідомлення використовують один спільний сеанс. | | `per-channel-peer` | Кожна пара канал+відправник отримує ізольований контекст особистих повідомлень (безпечний режим особистих повідомлень). | | `per-account-channel-peer` | Як вище, але з додатковим поділом за обліковим записом (канали з кількома обліковими записами). | | `per-peer` | Кожен відправник отримує один сеанс для всіх каналів одного типу. | Локальна процедура початкового налаштування через CLI записує `session.dmScope: "per-channel-peer"`, якщо значення не задано, і зберігає будь-яке явно задане наявне значення. Це межа контексту обміну повідомленнями, а не межа адміністрування хоста. Якщо користувачі взаємно вороже налаштовані й використовують спільний хост або конфігурацію Gateway, запускайте окремі Gateway для кожної межі довіри. Якщо та сама особа звертається до вас через кілька каналів, використовуйте `session.identityLinks`, щоб об’єднати ці сеанси особистих повідомлень під однією канонічною ідентичністю. Див. [Керування сеансами](/uk/concepts/session) і [Конфігурація](/uk/gateway/configuration). ## Видимість контексту та авторизація активації Це два окремі поняття: * **Авторизація активації**: хто може активувати агента (`dmPolicy`, `groupPolicy`, списки дозволених, активація згадкою). * **Видимість контексту**: який додатковий контекст надходить до моделі (текст відповіді, цитований текст, історія гілки, метадані пересилання). `contextVisibility` керує другим: * `"all"` (типове значення): додатковий контекст зберігається в отриманому вигляді. * `"allowlist"`: додатковий контекст фільтрується до відправників, дозволених активними перевірками списків дозволених. * `"allowlist_quote"`: як `allowlist`, але одна явна цитована відповідь усе одно зберігається. Налаштовуйте окремо для кожного каналу або кімнати/розмови — див. [Групи](/uk/channels/groups#context-visibility-and-allowlists). Звіти, які лише показують, що «модель може бачити цитований або історичний текст від відправників поза списком дозволених», є знахідками щодо посилення захисту, які можна усунути за допомогою `contextVisibility`, а не обходами авторизації чи пісочниці самими по собі; звіт про вплив на безпеку все одно має продемонструвати обхід межі довіри. ## Ін’єкція промптів Зловмисник створює повідомлення, яке маніпулює моделлю, спонукаючи її до небезпечних дій («ігноруй свої інструкції», «виведи вміст файлової системи», «перейди за цим посиланням і виконай команди»). Ін’єкція промптів **не усувається** лише захисними правилами системного промпту — це м’які настанови; жорстке дотримання забезпечують політика інструментів, схвалення виконання команд, ізоляція в пісочниці та списки дозволених каналів (які оператори все одно можуть вимкнути за задумом). Для ін’єкції промптів не потрібні публічні особисті повідомлення: навіть якщо лише ви можете писати боту, будь-який **ненадійний вміст**, який він читає (результати вебпошуку або отримання даних, сторінки браузера, електронні листи, документи, вкладення, вставлені журнали або код), може містити ворожі інструкції. Поверхнею загроз є сам вміст, а не лише відправник. Ознаки небезпеки, які слід вважати ненадійними: * «Прочитай цей файл або URL-адресу й виконай точно те, що там написано». * «Ігноруй свій системний промпт або правила безпеки». * «Розкрий свої приховані інструкції або результати роботи інструментів». * «Встав повний вміст \~/.openclaw або своїх журналів». Що допомагає на практиці: * Обмежуйте вхідні особисті повідомлення (сполученням/списками дозволених); у групах віддавайте перевагу активації згадкою; уникайте постійно активних ботів у публічних кімнатах. * За замовчуванням вважайте посилання, вкладення та вставлені інструкції ворожими. * Виконуйте чутливі операції з інструментами в пісочниці; зберігайте секрети поза файловою системою, доступною агенту. Ізоляція в пісочниці вмикається явно: якщо режим пісочниці вимкнено, неявний `host=auto` спрямовується на хост Gateway, тоді як явний `host=sandbox` усе одно завершується безпечною відмовою (середовище виконання пісочниці недоступне). Установіть `host=gateway`, щоб явно зафіксувати цю поведінку в конфігурації. * Обмежуйте інструменти високого ризику (`exec`, `browser`, `web_fetch`, `web_search`) довіреними агентами або явними списками дозволених. * Якщо ви додаєте інтерпретатори (`python`, `node`, `ruby`, `perl`, `php`, `lua`, `osascript`) до списку дозволених, увімкніть `tools.exec.strictInlineEval`, щоб вбудовані форми обчислення (`-c`, `-e` і подібні) усе одно потребували явного схвалення. У режимі списку дозволених будь-який сегмент heredoc (`<<`) завжди потребує перевірки рецензентом або явного схвалення незалежно від лапок — дозволена команда не може використати тіло heredoc для обходу перевірки списку дозволених. * Зменшуйте масштаб можливих наслідків, використовуючи **агента-читача** лише для читання або з вимкненими інструментами, щоб узагальнювати ненадійний вміст, а потім передавати резюме основному агенту. * Для обробників Gmail вбудований окремий сеанс для кожного повідомлення ізолює контекст розмови, але не скасовує дозволів цільового агента на інструменти або робочу область. Спрямовуйте ненадійну пошту до спеціального агента-читача, застосовуйте [окремі обмеження пісочниці та інструментів для кожного агента](/uk/tools/multi-agent-sandbox-tools) і обмежуйте будь-яке передавання основному агенту за допомогою [`tools.agentToAgent`](/uk/gateway/config-tools#toolsagenttoagent). Див. [Інтеграція з Gmail](/uk/gateway/configuration-reference#gmail-integration). * Залишайте `web_search` / `web_fetch` / `browser` вимкненими для агентів із доступом до інструментів, якщо вони не потрібні. * Для вхідних URL-адрес OpenResponses (`input_file` / `input_image`) установіть суворі `gateway.http.endpoints.responses.files.urlAllowlist` / `images.urlAllowlist` і низьке значення `maxUrlParts` (порожні списки дозволених вважаються незаданими). Використовуйте `files.allowUrl: false` / `images.allowUrl: false`, щоб повністю вимкнути отримання даних за URL-адресами. * Не додавайте секрети до промптів; натомість передавайте їх через середовище або конфігурацію на хості Gateway. **Вибір моделі має значення.** Стійкість до ін’єкцій промптів відрізняється між рівнями моделей — менші або дешевші моделі вразливіші до неналежного використання інструментів і перехоплення керування інструкціями під впливом ворожих промптів. Для агентів із доступом до інструментів або агентів, які читають ненадійний вміст, ризик ін’єкції промптів у старіших або менших моделей часто надто високий. Не запускайте такі робочі навантаження на слабких рівнях моделей. * Використовуйте модель найновішого покоління найвищого рівня для будь-якого бота, який може запускати інструменти або взаємодіяти з файлами чи мережами. * Не використовуйте старіші, слабші або менші рівні для агентів із доступом до інструментів чи ненадійних вхідних повідомлень. * Якщо необхідно використовувати меншу модель, зменште масштаб можливих наслідків: інструменти лише для читання, надійна ізоляція в пісочниці, мінімальний доступ до файлової системи, суворі списки дозволених. Увімкніть ізоляцію в пісочниці для всіх сеансів і вимкніть `web_search`/`web_fetch`/`browser`, якщо вхідні дані не перебувають під суворим контролем. * Для персональних асистентів лише з функціями чату, довіреними вхідними даними та без інструментів менші моделі зазвичай цілком придатні. ### Зовнішній вміст і обгортання ненадійних вхідних даних Текст OpenResponses `input_file` усе одно вставляється як ненадійний зовнішній вміст, хоча Gateway декодує його локально — блок містить маркери меж `<<>>` і метадані `Source: External` (у цьому шляху немає довшого банера `SECURITY NOTICE:`, який використовується в інших місцях). Таке саме обгортання на основі маркерів застосовується, коли засоби розуміння медіаданих видобувають текст із вкладених документів перед його додаванням до медіапромпту. OpenClaw також видаляє поширені літерали спеціальних токенів шаблонів чатів самостійно розміщених LLM (токени ролей/ходів Qwen/ChatML, Llama, Gemma, Mistral, Phi, GPT-OSS) із загорнутого зовнішнього вмісту та метаданих до того, як вони потраплять до моделі. Самостійно розміщені серверні системи, сумісні з OpenAI (vLLM, SGLang, TGI, LM Studio, власні стеки токенізаторів Hugging Face), іноді токенізують літеральні рядки на кшталт `<|im_start|>` або `<|start_header_id|>` як структурні токени шаблону чату у вмісті користувача; без цієї санітизації ненадійний текст на отриманій сторінці, у тілі електронного листа або у виводі інструмента для читання вмісту файлів міг би підробити синтетичну межу ролей `assistant`/`system`. Санітизація відбувається на рівні загортання зовнішнього вмісту, тому однаково застосовується до інструментів отримання/читання та вхідного вмісту каналів. Розміщені постачальники (OpenAI, Anthropic) уже застосовують власну санітизацію на боці запиту; залишайте загортання зовнішнього вмісту ввімкненим і, коли це можливо, віддавайте перевагу параметрам серверної системи, які розділяють або екранують спеціальні токени. Вихідні відповіді моделі мають окремий санітизатор, який видаляє витоки ``, ``, ``, `` та подібної внутрішньої службової структури з видимих користувачеві відповідей на кінцевій межі доставлення до каналу. Це не замінює `dmPolicy`, списки дозволів, схвалення виконання, ізоляцію в пісочниці або `contextVisibility` — це усуває один конкретний обхід на рівні токенізатора. ### Прапорці обходу (залишайте вимкненими у промисловому середовищі) * `hooks.mappings[].allowUnsafeExternalContent` * `hooks.gmail.allowUnsafeExternalContent` * Поле корисного навантаження Cron `allowUnsafeExternalContent` Вмикайте лише тимчасово для налагодження з чітко обмеженою областю; якщо ввімкнено, ізолюйте цього агента (пісочниця + мінімальний набір інструментів + окремий простір імен сеансу). Корисні навантаження хуків є ненадійним вмістом, навіть якщо доставлення надходить із контрольованих вами систем (пошта, документи або вебвміст можуть містити ін’єкцію підказок). Слабші рівні моделей підвищують цей ризик — для автоматизації, керованої хуками, віддавайте перевагу потужним сучасним рівням моделей і зберігайте сувору політику інструментів (`tools.profile: "messaging"` або суворішу), а також, де можливо, використовуйте пісочницю. ### Міркування та докладний вивід у групах `/reasoning`, `/verbose` і `/trace` можуть розкрити внутрішні міркування, вивід інструментів або діагностику плагінів, не призначені для публічного каналу — вони можуть містити аргументи інструментів, URL-адреси, діагностику плагінів і дані, які бачила модель. Залишайте їх вимкненими в публічних кімнатах; вмикайте лише в надійних приватних повідомленнях або суворо контрольованих кімнатах. ## Авторизація команд Команди зі скісною рискою та директиви виконуються лише для авторизованих відправників, визначених на основі списків дозволів каналу/спарювання разом із `commands.useAccessGroups` (див. [Конфігурацію](/uk/gateway/configuration) і [Команди зі скісною рискою](/uk/tools/slash-commands)). Якщо список дозволів каналу порожній або містить `"*"`, команди для цього каналу фактично відкриті. `/exec` — це зручність лише для поточного сеансу для авторизованих операторів; вона не записує конфігурацію та не змінює інші сеанси. ## Інструменти площини керування Два вбудовані інструменти залишаються чутливими для площини керування: * `gateway` читає конфігурацію за допомогою `config.schema.lookup` / `config.get`. Він не може записувати конфігурацію, оновлювати OpenClaw або перезапускати Gateway. * `cron` створює заплановані завдання, які продовжують виконуватися після завершення початкового чату/завдання. Інструмент `gateway` залишається доступним лише власнику, оскільки читання конфігурації може розкрити секрети й топологію хоста. Агенти запитують постійні зміни конфігурації або життєвого циклу через інструмент делегування `openclaw`; OpenClaw зіставляє їх із типізованими операціями та вимагає схвалення людиною перед застосуванням. Див. [Агент налаштування OpenClaw](/cli/openclaw#operations-and-approval). Для будь-якого агента/поверхні, що обробляє ненадійний вміст, типово забороняйте таке: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { tools: { deny: ["gateway", "cron", "sessions_spawn", "sessions_send"], }, } ``` `commands.restart=false` вимикає `/restart` і зовнішні запити на перезапуск `SIGUSR1`. Інструмент агента `gateway` не має дії перезапуску. ## Виконання на Node (`system.run`) Якщо спарено вузол macOS, Gateway може викликати на ньому `system.run` — це віддалене виконання коду на цьому Mac. * Потребує спарювання вузла (схвалення + токен). Спарювання встановлює ідентичність/довіру вузла та видає токен; воно не є механізмом схвалення кожної окремої команди. * Gateway застосовує загальну глобальну політику команд вузлів через `gateway.nodes.allowCommands` / `denyCommands`. `denyCommands` зіставляє лише точні назви команд вузла (наприклад, `system.run`), а не текст оболонки всередині корисного навантаження команди — вузол, що повторно підключається й оголошує інший список команд, сам по собі не є вразливістю, якщо глобальна політика Gateway та власні схвалення виконання вузла й надалі забезпечують межу. * Політика `system.run` для окремого вузла — це власний файл схвалень виконання вузла (`exec.approvals.node.*`), яким на Mac керують через Settings -> Exec approvals (безпека + запит + список дозволів); вона може бути суворішою або м’якшою за глобальну політику ідентифікаторів команд Gateway. * Вузол, що працює з `security="full"` і `ask="off"`, дотримується типової моделі довіреного оператора — це очікувана поведінка, а не помилка, якщо вашому розгортанню не потрібна суворіша позиція. * Режим схвалення прив’язує точний контекст запиту та, коли можливо, один конкретний операнд локального сценарію/файлу. Якщо OpenClaw не може визначити рівно один безпосередній локальний файл для команди інтерпретатора/середовища виконання, виконання на основі схвалення відхиляється замість обіцянки повного семантичного охоплення. * Для `host=node` запуски на основі схвалення також зберігають канонічний підготовлений `systemRunPlan`; наступні схвалені пересилання повторно використовують цей збережений план, а перевірка Gateway відхиляє зміни викликачем контексту команди/cwd/сеансу після створення запиту на схвалення. * Щоб повністю вимкнути віддалене виконання: установіть для безпеки значення `deny` і видаліть спарювання вузла для цього Mac. ## Динамічні Skills (спостерігач / віддалені вузли) OpenClaw може оновлювати список Skills посеред сеансу: спостерігач Skills оновлює знімок під час наступного ходу агента, коли змінюється `SKILL.md`, а підключення вузла macOS може зробити доступними Skills лише для macOS (на основі перевірки бінарних файлів). Вважайте теки Skills довіреним кодом і обмежуйте коло осіб, які можуть їх змінювати. ## Плагіни Плагіни виконуються в одному процесі з Gateway — вважайте їх довіреним кодом. * Установлюйте лише з надійних джерел; віддавайте перевагу явним спискам дозволів `plugins.allow`; перевіряйте конфігурацію плагіна перед увімкненням; перезапускайте Gateway після змін плагінів. * Установлення/оновлення плагінів запускає виконуваний код: * Шлях установлення — каталог окремого плагіна в активному кореневому каталозі встановлення плагінів. * Пакети ClawHub і вбудований/офіційний каталог OpenClaw є надійними джерелами. Нове довільне джерело npm, `npm-pack:`, git, локальний шлях/архів або маркетплейс спричиняє попередження перед установленням; для неінтерактивного встановлення потрібен `--force` після того, як ви перевірите це джерело й визнаєте його надійним. `--force` підтверджує походження та дозволяє перезапис; він не обходить `security.installPolicy` або решту перевірок безпеки встановлення. Під час оновлень повторно використовується вже вибране джерело. * OpenClaw не виконує вбудованого локального блокування небезпечного коду під час установлення/оновлення. Використовуйте `security.installPolicy` для локальних рішень оператора про дозвіл/блокування та `openclaw security audit --deep` для діагностичного сканування. * Під час установлення плагінів npm і git узгодження залежностей менеджером пакунків виконується лише в межах явної процедури встановлення/оновлення. Локальні шляхи та архіви вважаються самодостатніми пакунками; OpenClaw копіює їх або посилається на них без запуску `npm install`. * Віддавайте перевагу точно закріпленим версіям (`@scope/pkg@1.2.3`) і перевіряйте розпакований код перед увімкненням. * `--dangerously-force-unsafe-install` застарів і більше не змінює поведінку встановлення/оновлення. * `security.installPolicy` дає операторам змогу запускати надійну локальну команду для ухвалення специфічних для хоста рішень про дозвіл/блокування встановлення Skills і плагінів. Вона запускається після підготовки вихідних матеріалів, але до продовження встановлення, також застосовується до Skills ClawHub і не обходиться застарілими небезпечними прапорцями. Докладніше: [Плагіни](/uk/tools/plugin) ## Пісочниця Окрема документація: [Пісочниця](/uk/gateway/sandboxing) Два взаємодоповнювальні підходи: * **Повний Gateway у Docker** (межа контейнера): [Docker](/uk/install/docker) * **Пісочниця інструментів** (`agents.defaults.sandbox`; Gateway на хості + ізольовані в пісочниці інструменти; Docker є типовою серверною системою): [Пісочниця](/uk/gateway/sandboxing) Щоб запобігти доступу між агентами, залишайте `agents.defaults.sandbox.scope` зі значенням `"agent"` (типово) або використовуйте `"session"` для суворішої ізоляції кожного сеансу. `scope: "shared"` використовує один контейнер або робочий простір. Доступ до робочого простору агента всередині пісочниці (`agents.defaults.sandbox.workspaceAccess`): * `"none"` (типово): інструменти бачать робочий простір пісочниці в `~/.openclaw/sandboxes`; робочий простір агента недоступний. * `"ro"`: монтує робочий простір агента лише для читання в `/agent` (вимикає `write`/`edit`/`apply_patch`). * `"rw"`: монтує робочий простір агента для читання/запису в `/workspace`. Додаткові `sandbox.docker.binds` перевіряються щодо нормалізованих канонічних шляхів джерела. Список заборонених шляхів охоплює `/etc`, `/private/etc`, `/proc`, `/sys`, `/dev`, `/root`, `/boot` і каталоги, які зазвичай містять сокет Docker або є його псевдонімами (`/run`, `/var/run` і `docker.sock` під ними), а також підшляхи облікових даних HOME (`.aws`, `.cargo`, `.config`, `.docker`, `.gnupg`, `.netrc`, `.npm`, `.ssh`). Маніпуляції з батьківськими символічними посиланнями та канонічні псевдоніми домашнього каталогу розв’язуються через наявних предків і перевіряються повторно, тому вони й надалі блокуються за принципом безпечної відмови, якщо вказують на заборонений корінь. `tools.elevated` — це глобальний базовий аварійний обхід, який запускає виконання поза пісочницею. Фактичним хостом типово є `gateway` або `node`, коли ціль виконання налаштовано як `node`. Суворо обмежуйте `tools.elevated.allowFrom` і не вмикайте його для незнайомців. Додатково обмежуйте для кожного агента через `agents.list[].tools.elevated`. Див. [Режим підвищених привілеїв](/uk/tools/elevated). ### Запобіжник делегування субагентам Якщо ви дозволяєте інструменти сеансів, розглядайте делеговані запуски субагентів як ще одне рішення щодо межі: * Забороняйте `sessions_spawn`, якщо агент справді не потребує делегування. * Зберігайте `agents.defaults.subagents.allowAgents` і будь-які перевизначення `agents.list[].subagents.allowAgents` для окремих агентів обмеженими відомими безпечними цільовими агентами. * Для робочих процесів, які мають залишатися в пісочниці, викликайте `sessions_spawn` з `sandbox: "require"` (типово — `"inherit"`); `"require"` негайно завершується помилкою, коли цільове дочірнє середовище виконання не ізольоване в пісочниці. ### Режим лише для читання Створіть профіль лише для читання, поєднавши `agents.defaults.sandbox.workspaceAccess: "ro"` (або `"none"` без доступу до робочого простору) зі списками дозволених/заборонених інструментів, які блокують `write`, `edit`, `apply_patch`, `exec`, `process` тощо. * `tools.exec.applyPatch.workspaceOnly: true` (типово): не дає `apply_patch` записувати/видаляти поза каталогом робочого простору, навіть коли пісочницю вимкнено. Установлюйте `false` лише тоді, коли навмисно хочете, щоб `apply_patch` працював із файлами поза робочим простором. * `tools.fs.workspaceOnly: true` (необов’язково): обмежує шляхи `read`/`write`/`edit`/`apply_patch` і шляхи автоматичного завантаження зображень нативних підказок каталогом робочого простору. * Зберігайте корені файлової системи вузькими — уникайте широких коренів, як-от ваш домашній каталог, для робочих просторів агента/пісочниці, оскільки це може відкрити інструментам файлової системи доступ до чутливих локальних файлів (наприклад, стану/конфігурації в `~/.openclaw`). ## Профілі доступу для окремих агентів (мультиагентний режим) Кожен агент може мати власну пісочницю та політику інструментів: повний доступ, лише читання або відсутність доступу. Правила пріоритетності див. у розділі [Пісочниця та інструменти для кількох агентів](/uk/tools/multi-agent-sandbox-tools). Поширені схеми: особистий агент (повний доступ, без пісочниці), сімейний/робочий агент (у пісочниці + інструменти лише для читання), публічний агент (у пісочниці + без інструментів файлової системи/оболонки). ### Повний доступ (без пісочниці) ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { agents: { list: [ { id: "personal", workspace: "~/.openclaw/workspace-personal", sandbox: { mode: "off" } }, ], }, } ``` ### Інструменти лише для читання + робочий простір лише для читання ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { agents: { list: [ { id: "family", workspace: "~/.openclaw/workspace-family", sandbox: { mode: "all", scope: "agent", workspaceAccess: "ro" }, tools: { allow: ["read"], deny: ["write", "edit", "apply_patch", "exec", "process", "browser"], }, }, ], }, } ``` ### Без доступу до файлової системи/оболонки (обмін повідомленнями через провайдерів дозволено) ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { agents: { list: [ { id: "public", workspace: "~/.openclaw/workspace-public", sandbox: { mode: "all", scope: "agent", workspaceAccess: "none" }, tools: { // Інструменти сеансів можуть розкривати дані транскриптів. Типова область — поточний сеанс + // сеанси породжених підагентів; за потреби додатково обмежте її через tools.sessions.visibility. sessions: { visibility: "tree" }, // self | tree | agent | all allow: [ "sessions_list", "sessions_history", "sessions_send", "sessions_spawn", "session_status", "discord", "slack", "telegram", "whatsapp", ], deny: [ "apply_patch", "browser", "canvas", "cron", "edit", "exec", "gateway", "image", "nodes", "process", "read", "write", ], }, }, ], }, } ``` ## Ризики керування браузером Увімкнення керування браузером надає моделі справжній браузер. Якщо в цьому профілі вже є активні автентифіковані сеанси, модель може отримати доступ до цих облікових записів і даних — вважайте профілі браузера конфіденційним станом. * Надавайте перевагу окремому профілю для агента (типовий профіль `openclaw`); не використовуйте особистий повсякденний профіль. * Не вмикайте керування браузером хоста для агентів у пісочниці, якщо ви їм не довіряєте. * Автономний API керування браузером через loopback підтримує лише автентифікацію спільним секретом (автентифікацію за токеном Gateway типу bearer або паролем Gateway) — він не використовує заголовки ідентичності довіреного проксі чи Tailscale Serve. * Вважайте завантаження з браузера недовіреними вхідними даними; надавайте перевагу ізольованому каталогу завантажень. * Якщо можливо, вимкніть синхронізацію браузера та менеджери паролів у профілі агента. * Для віддалених Gateway «керування браузером» рівнозначне «доступу оператора» до всього, чого може досягти цей профіль. * Залишайте хости Gateway і Node доступними лише в tailnet; не відкривайте порти керування браузером для LAN або загальнодоступного інтернету. * Вимикайте маршрутизацію проксі браузера, коли вона не потрібна (`gateway.nodes.browser.mode="off"`). * Режим наявного сеансу Chrome MCP не є «безпечнішим» — він може діяти від вашого імені всюди, куди має доступ профіль Chrome цього хоста. * Запустіть **хост Node** на машині з браузером і дозвольте Gateway проксіювати дії браузера, коли Gateway розташований віддалено від браузера (див. [Інструмент браузера](/uk/tools/browser)); ставтеся до сполучення Node як до адміністративного доступу, тримайте Gateway і хост Node в одній tailnet та не відкривайте порти ретрансляції/керування через LAN, загальнодоступний інтернет або Tailscale Funnel. ### Політика SSRF браузера (типово сувора) Приватні/внутрішні адреси залишаються заблокованими, доки ви явно не дозволите доступ. * Типово: `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` не задано, тому приватні/внутрішні адреси та адреси спеціального призначення залишаються заблокованими. Застарілий псевдонім `allowPrivateNetwork` досі підтримується. * Явний дозвіл: установіть `dangerouslyAllowPrivateNetwork: true`, щоб дозволити ці адреси. * У суворому режимі використовуйте `hostnameAllowlist` (шаблони на кшталт `*.example.com`) і `allowedHostnames` (точні винятки для хостів, зокрема для імен, які інакше блокуються, як-от `localhost`) для явних винятків. * Запити безпосередньої навігації проходять попередню перевірку. Під час дії та обмеженого пільгового періоду після неї захищені взаємодії Playwright (клацання, клацання за координатами, наведення, перетягування, прокручування, вибір, натискання, введення, заповнення форм і обчислення) перехоплюють заборонені політикою завантаження документів верхнього рівня та підфреймів до надсилання байтів HTTP-запиту, а потім за принципом максимально можливого повторно перевіряють остаточну URL-адресу `http(s)`. * Перед кожним новим запуском керованого Chrome OpenClaw за принципом максимально можливого вимикає прогнозування мережі, пригнічуючи виявлене спекулятивне попереднє з’єднання Chromium для цих заборонених завантажень. Це поглиблений захист, а не межа політики: браузер, повторно використаний після перезапуску служби керування, та інші браузерні рушії можуть не мати такого посилення захисту. Маршрутизація сторінок залишається перехопленням на рівні запитів, а не мережевим брандмауером: переходи переспрямувань, перший запит спливного вікна, трафік Service Worker, код сторінки, що виконується після завершення обмеженого захисного вікна, а також деякі фонові шляхи та шляхи підресурсів можуть обійти її. Перевірки остаточної URL-адреси залишаються захистом для виявлення та карантинування; повне запобігання потребує ізоляції вихідного трафіку на боці власника або проксі, що забезпечує дотримання політики. ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { browser: { ssrfPolicy: { dangerouslyAllowPrivateNetwork: false, hostnameAllowlist: ["*.example.com", "example.com"], allowedHostnames: ["localhost"], }, }, } ``` ## Мережева доступність ### Прив’язка, порт, брандмауер Gateway мультиплексує WebSocket + HTTP на одному порту (типово `18789`; конфігурація/прапорці/змінні середовища: `gateway.port`, `--port`, `OPENCLAW_GATEWAY_PORT`). Ця HTTP-поверхня охоплює Control UI (ресурси SPA, типовий базовий шлях `/`) і хост полотна (`/__openclaw__/canvas` та `/__openclaw__/a2ui` — довільний HTML/JS; вважайте його недовіреним вмістом під час завантаження у звичайному браузері; не відкривайте його для недовірених мереж/користувачів і не використовуйте для нього спільне джерело з привілейованими вебповерхнями). `gateway.bind` визначає, де Gateway прослуховує з’єднання: * `"loopback"` (типово): підключатися можуть лише локальні клієнти. * `"lan"`, `"tailnet"`, `"custom"`: розширюють поверхню атаки. Використовуйте лише з автентифікацією Gateway (спільним токеном/паролем або правильно налаштованим довіреним проксі) і справжнім брандмауером. Практичні правила: віддавайте перевагу Tailscale Serve замість прив’язки до LAN (Serve залишає Gateway на loopback, а доступом керує Tailscale); якщо прив’язка до LAN необхідна, обмежте порт у брандмауері суворим списком дозволених IP-адрес джерел замість широкого переспрямування порту; ніколи не відкривайте Gateway без автентифікації на `0.0.0.0`. ### Публікація портів Docker з UFW Опубліковані порти контейнерів (`-p HOST:CONTAINER` або Compose `ports:`) маршрутизуються через ланцюжки переспрямування Docker, а не лише через правила хоста `INPUT`. Застосовуйте правила в `DOCKER-USER` (вони обчислюються перед власними правилами дозволу Docker); більшість сучасних дистрибутивів використовують інтерфейс `iptables-nft`, який також застосовує ці правила до серверної частини nftables. ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} # /etc/ufw/after.rules (додайте як окрему секцію *filter) *filter :DOCKER-USER - [0:0] -A DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j RETURN -A DOCKER-USER -s 127.0.0.0/8 -j RETURN -A DOCKER-USER -s 10.0.0.0/8 -j RETURN -A DOCKER-USER -s 172.16.0.0/12 -j RETURN -A DOCKER-USER -s 192.168.0.0/16 -j RETURN -A DOCKER-USER -s 100.64.0.0/10 -j RETURN -A DOCKER-USER -p tcp --dport 80 -j RETURN -A DOCKER-USER -p tcp --dport 443 -j RETURN -A DOCKER-USER -m conntrack --ctstate NEW -j DROP -A DOCKER-USER -j RETURN COMMIT ``` IPv6 має окремі таблиці — додайте відповідну політику в `/etc/ufw/after6.rules`, якщо IPv6 у Docker увімкнено. Не задавайте імена інтерфейсів жорстко (`eth0`), оскільки вони різняться між образами VPS (`ens3`, `enp*` тощо), а невідповідність може непомітно призвести до пропуску правила заборони. ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} ufw reload iptables -S DOCKER-USER ip6tables -S DOCKER-USER nmap -sT -p 1-65535 --open ``` Зовні мають бути доступні лише ті порти, які ви навмисно відкрили (для більшості конфігурацій: SSH + порти зворотного проксі). ### Виявлення mDNS/Bonjour Коли вбудований Plugin `bonjour` увімкнено, Gateway транслює свою присутність через mDNS (`_openclaw-gw._tcp`, порт 5353) для виявлення локальних пристроїв. Повний режим містить записи TXT, які розкривають операційні відомості: `cliPath` (шлях файлової системи, що розкриває ім’я користувача та місце встановлення), `sshPort` (повідомляє про доступність SSH), `displayName`/`lanHost` (відомості про ім’я хоста). Трансляція відомостей про інфраструктуру спрощує розвідку в LAN. * Не вмикайте Bonjour, якщо виявлення в LAN не потрібне — він автоматично запускається на хостах macOS, а на інших платформах потребує явного ввімкнення; прямі URL-адреси Gateway, Tailnet, SSH або глобальний DNS-SD дають змогу уникнути локальної багатоадресної розсилки. * **Мінімальний режим** (типовий, коли Bonjour увімкнено; рекомендований для відкритих Gateway) не містить конфіденційних полів: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { discovery: { mdns: { mode: "minimal" } } } ``` * **Вимкнено** пригнічує локальне виявлення, залишаючи Plugin увімкненим: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { discovery: { mdns: { mode: "off" } } } ``` * **Повний режим** (потребує явного ввімкнення) містить `cliPath` + `sshPort`: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { discovery: { mdns: { mode: "full" } } } ``` * Або задайте `OPENCLAW_DISABLE_BONJOUR=1`, щоб вимкнути mDNS без змін конфігурації. У мінімальному режимі Gateway транслює `role`, `gatewayPort`, `transport`, але не містить `cliPath`/`sshPort`; застосунки, яким потрібен шлях CLI, можуть натомість отримати його через автентифіковане з’єднання WebSocket. ### Автентифікація WebSocket Gateway Автентифікація Gateway типово обов’язкова — якщо не налаштовано жодного дійсного способу автентифікації, Gateway відхиляє з’єднання WebSocket (закриття в разі помилки). Під час початкового налаштування типово створюється токен (навіть для loopback), тому локальні клієнти мають автентифікуватися. ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { gateway: { auth: { mode: "token", token: "your-token" } } } ``` `openclaw doctor --generate-gateway-token` може згенерувати його для вас. `gateway.remote.token` та `gateway.remote.password` є джерелами облікових даних клієнта — самі по собі вони не захищають локальний доступ до WS. Локальні шляхи викликів використовують `gateway.remote.*` лише як резервний варіант, коли `gateway.auth.*` не задано. Якщо `gateway.auth.token` або `gateway.auth.password` явно налаштовано через SecretRef і посилання не вдається розв’язати, розв’язання завершується закриттям у разі помилки (без маскування віддаленим резервним варіантом). Закріплюйте віддалений TLS за допомогою `gateway.remote.tlsFingerprint` під час використання `wss://`. Незашифрований `ws://` дозволено для loopback, літералів приватних IP-адрес, `.local` і URL-адрес Gateway у Tailnet `*.ts.net`; для інших довірених приватних DNS-імен задайте `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` у процесі клієнта як аварійний виняток (лише в середовищі процесу, не як ключ `openclaw.json`). Сполучення мобільних пристроїв і ручні/відскановані маршрути Gateway в Android суворіші: незашифроване з’єднання дозволено лише для loopback, тоді як приватна LAN, link-local, `.local` та імена хостів без крапок мають використовувати TLS, якщо ви явно не дозволили незашифрований шлях у довіреній приватній мережі. Сполучення пристроїв автоматично схвалюється для прямих локальних підключень loopback (а також для вузького шляху локального самопідключення серверної частини/контейнера для довірених допоміжних потоків зі спільним секретом); підключення через Tailnet і LAN, зокрема підключення з того самого хоста до адреси tailnet, вважаються віддаленими й усе одно потребують схвалення. Розв’язана адреса `tailnet` або адреса `custom`, відмінна від `127.0.0.1` чи `0.0.0.0`, додає окремий слухач `127.0.0.1`; лише підключення до цього локального слухача отримують семантику loopback. Наявність пересланих заголовків у запиті loopback скасовує локальність loopback; автоматичне схвалення оновлення метаданих має вузьку область дії. Див. [Сполучення Gateway](/uk/gateway/pairing). Режими автентифікації: * `"token"`: спільний токен-носій (рекомендовано для більшості конфігурацій). * `"password"`: бажано задавати через `OPENCLAW_GATEWAY_PASSWORD`. * `"trusted-proxy"`: довіряти зворотному проксі з підтримкою ідентифікації для автентифікації користувачів і передавання ідентифікаційних даних через заголовки. Див. [Автентифікація через довірений проксі](/uk/gateway/trusted-proxy-auth). Контрольний список ротації (токен/пароль): згенерувати або задати новий секрет (`gateway.auth.token` або `OPENCLAW_GATEWAY_PASSWORD`); перезапустити Gateway (або застосунок macOS, якщо він керує Gateway); оновити віддалені клієнти (`gateway.remote.token`/`.password`); переконатися, що старі облікові дані більше не працюють. ### Заголовки ідентифікації Tailscale Serve Коли `gateway.auth.allowTailscale` має значення `true` (типове для Serve), OpenClaw приймає заголовок ідентифікації Tailscale Serve `tailscale-user-login` для автентифікації Control UI/WebSocket. Ідентичність перевіряється шляхом визначення адреси `x-forwarded-for` через локальний демон Tailscale (`tailscale whois`) і зіставлення її із заголовком — ця перевірка запускається лише для запитів із кільцевого інтерфейсу, що містять `x-forwarded-for`, `x-forwarded-proto` і `x-forwarded-host`, додані Tailscale. Для цієї асинхронної перевірки невдалі спроби з однаковим `{scope, ip}` серіалізуються до того, як обмежувач зареєструє помилку, тому одночасні повторні невдалі спроби від одного клієнта Serve можуть негайно заблокувати вже другу спробу. Кінцеві точки HTTP API (`/v1/*`, `/tools/invoke`, `/api/channels/*`) не використовують автентифікацію за заголовком ідентифікації Tailscale — вони дотримуються налаштованого для Gateway режиму HTTP-автентифікації. HTTP-автентифікація Gateway за токеном-носієм фактично надає операторський доступ за принципом «усе або нічого». Облікові дані, за допомогою яких можна викликати `/v1/chat/completions`, `/v1/responses`, маршрути плагінів, як-от `/api/v1/admin/rpc`, або `/api/channels/*`, є секретами оператора з повним доступом до цього Gateway: автентифікація за спільним секретом-носієм відновлює повний типовий набір операторських областей доступу (`operator.admin`, `operator.approvals`, `operator.pairing`, `operator.read`, `operator.talk.secrets`, `operator.write`) і семантику власника для ходів агента, а вужчі значення `x-openclaw-scopes` не обмежують цей шлях зі спільним секретом. Семантика областей доступу для окремого запиту застосовується лише тоді, коли запит надходить із режиму, що містить ідентичність (автентифікація через довірений проксі), або через явно приватну точку входу без автентифікації; у цих режимах відсутність `x-openclaw-scopes` призводить до використання звичайного типового набору операторських областей доступу, а заголовки рівня власника, як-от `x-openclaw-model`, потребують `operator.admin`, якщо області доступу звужено. Для `/tools/invoke` і кінцевих точок історії HTTP-сеансів діє те саме правило спільного секрету. Не надавайте ці облікові дані недовіреним сторонам; бажано використовувати окремі Gateway для кожної межі довіри. Автентифікація Serve без токена передбачає, що сам хост Gateway є довіреним — вона не захищає від ворожих процесів на тому самому хості. Якщо на хості Gateway може виконуватися недовірений локальний код, вимкніть `allowTailscale` і вимагайте явної автентифікації за спільним секретом (`token` або `password`). Не пересилайте ці заголовки зі свого зворотного проксі. Якщо TLS завершується або проксіюється перед Gateway, вимкніть `allowTailscale` і натомість використовуйте автентифікацію за спільним секретом або [автентифікацію через довірений проксі](/uk/gateway/trusted-proxy-auth). Див. [Tailscale](/uk/gateway/tailscale) і [огляд вебінтерфейсу](/uk/web). ### Налаштування зворотного проксі Задайте `gateway.trustedProxies` для належного опрацювання пересланої IP-адреси клієнта за nginx/Caddy/Traefik тощо. Коли Gateway виявляє заголовки проксі від адреси, якої **немає** в `trustedProxies`, він не вважатиме з’єднання локальним; якщо автентифікацію Gateway вимкнено, таке з’єднання буде відхилено. Це запобігає ситуації, коли проксійовані з’єднання виглядають так, ніби надходять із localhost, і автоматично отримують довіру. `trustedProxies` також передає дані до `gateway.auth.mode: "trusted-proxy"`, який є суворішим: типово він відмовляє в доступі для проксі з кільцевою адресою джерела. Зворотні проксі на тому самому хості через кільцевий інтерфейс можуть використовувати `trustedProxies` для виявлення локальних клієнтів і опрацювання пересланих IP-адрес, але можуть відповідати режиму автентифікації `trusted-proxy` лише за умови `gateway.auth.trustedProxy.allowLoopback = true`; в іншому разі використовуйте автентифікацію за токеном або паролем. ```yaml theme={"theme":{"light":"min-light","dark":"min-dark"}} gateway: trustedProxies: - "10.0.0.1" # IP-адреса зворотного проксі allowRealIpFallback: false # типово false; вмикайте лише тоді, коли проксі не може надати X-Forwarded-For auth: mode: password password: ${OPENCLAW_GATEWAY_PASSWORD} ``` Коли задано `trustedProxies`, Gateway використовує `X-Forwarded-For` для визначення IP-адреси клієнта; `X-Real-IP` ігнорується, якщо явно не задано `gateway.allowRealIpFallback: true`. Переконайтеся, що проксі **перезаписує** `X-Forwarded-For`/`X-Real-IP`, а не дописує до них: ```nginx theme={"theme":{"light":"min-light","dark":"min-dark"}} # правильно proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Real-IP $remote_addr; # неправильно: зберігає/дописує недовірені значення, надані клієнтом proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ``` Заголовки довіреного проксі не роблять сполучення пристроїв Node автоматично довіреним — `gateway.nodes.pairing.autoApproveCidrs` є окремою операторською політикою, типовим станом якої є «вимкнено», а шляхи заголовків довіреного проксі з кільцевою адресою джерела не допускають автоматичного схвалення Node, навіть коли автентифікацію через довірений проксі для кільцевого інтерфейсу ввімкнено (оскільки локальні клієнти можуть підробити ці заголовки). ### Примітки щодо HSTS і джерела * Gateway OpenClaw передусім призначений для локального доступу або доступу через кільцевий інтерфейс. Якщо TLS завершується на зворотному проксі, налаштуйте HSTS там. * Якщо HTTPS завершується безпосередньо на Gateway, `gateway.http.securityHeaders.strictTransportSecurity` додає заголовок HSTS до відповідей OpenClaw. * Для розгортань Control UI не через кільцевий інтерфейс типово потрібен `gateway.controlUi.allowedOrigins`; `allowedOrigins: ["*"]` є явною політикою дозволу всіх джерел, а не захищеним типовим налаштуванням — не використовуйте її поза ретельно контрольованим локальним тестуванням. * Помилки автентифікації браузерного джерела на кільцевому інтерфейсі все одно підлягають обмеженню частоти, навіть коли загальний виняток для кільцевого інтерфейсу ввімкнено, але ключ блокування має окрему область для кожного нормалізованого значення `Origin`, а не один спільний сегмент localhost. * `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` вмикає резервний режим визначення джерела за заголовком Host; вважайте це небезпечною політикою, яку свідомо обирає оператор. * Вважайте повторне прив’язування DNS і поведінку заголовка хоста проксі питаннями посилення захисту розгортання; суворо обмежуйте `trustedProxies` і не надавайте прямого доступу до Gateway з публічного інтернету. * Докладні рекомендації щодо розгортання: [автентифікація через довірений проксі](/uk/gateway/trusted-proxy-auth#tls-termination-and-hsts). ### Control UI через HTTP Для створення ідентичності пристрою Control UI потрібен захищений контекст (HTTPS або localhost). * `gateway.controlUi.allowInsecureAuth`: локальний перемикач сумісності. На localhost дозволяє автентифікацію Control UI без ідентичності пристрою, коли сторінка завантажується через незахищений HTTP. Не обходить перевірки сполучення та не послаблює вимоги щодо ідентичності віддалених пристроїв (поза localhost). Бажано використовувати HTTPS (Tailscale Serve) або відкрити інтерфейс за адресою `127.0.0.1`. * `gateway.controlUi.dangerouslyDisableDeviceAuth`: лише для аварійних випадків; повністю вимикає перевірки ідентичності пристрою. Це значно послаблює безпеку; не вмикайте, крім випадків активного налагодження з можливістю швидко скасувати зміну. * Окремо від цих прапорців успішний `gateway.auth.mode: "trusted-proxy"` може дозволити **операторські** сеанси Control UI без ідентичності пристрою — це навмисна поведінка режиму автентифікації, а не обхід через `allowInsecureAuth`, і вона не поширюється на сеанси Control UI з роллю Node. `openclaw security audit` попереджає, коли ввімкнено `allowInsecureAuth`. ### Небезпечні прапорці та прапорці незахищеного режиму `openclaw security audit` створює `config.insecure_or_dangerous_flags` для кожного ввімкненого відомого небезпечного налагоджувального перемикача або перемикача незахищеного режиму (по одному результату на прапорець). У робочому середовищі не задавайте їх. Якщо налаштовано виключення аудиту, `security.audit.suppressions.active` залишається в активному виведенні, навіть коли відповідні результати переміщуються до `suppressedFindings`. * `gateway.controlUi.allowInsecureAuth=true` * `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` * `gateway.controlUi.dangerouslyDisableDeviceAuth=true` * `security.audit.suppressions configured ()` * `hooks.gmail.allowUnsafeExternalContent=true` * `hooks.mappings[].allowUnsafeExternalContent=true` * `tools.exec.applyPatch.workspaceOnly=false` * `plugins.entries.acpx.config.permissionMode=approve-all` Control UI та браузер: * `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback` * `gateway.controlUi.dangerouslyDisableDeviceAuth` * `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` Зіставлення назв каналів (вбудовані канали та канали плагінів; також для кожного `accounts.`, де це застосовно): * `channels.discord.dangerouslyAllowNameMatching` * `channels.googlechat.dangerouslyAllowNameMatching` * `channels.msteams.dangerouslyAllowNameMatching` * `channels.slack.dangerouslyAllowNameMatching` * `channels.irc.dangerouslyAllowNameMatching` (канал плагіна) * `channels.mattermost.dangerouslyAllowNameMatching` (канал плагіна) * `channels.synology-chat.dangerouslyAllowNameMatching` (канал плагіна) * `channels.synology-chat.dangerouslyAllowInheritedWebhookPath` (канал плагіна) * `channels.zalouser.dangerouslyAllowNameMatching` (канал плагіна) Мережевий доступ: * `channels.telegram.network.dangerouslyAllowPrivateNetwork` (також для кожного облікового запису) Docker у пісочниці (типові значення та окремо для кожного агента): * `agents.defaults.sandbox.docker.dangerouslyAllowReservedContainerTargets` * `agents.defaults.sandbox.docker.dangerouslyAllowExternalBindSources` * `agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin` ## Розгортання та довіра до хоста * Повнодискове шифрування на хості Gateway; якщо хост є спільним, бажано використовувати для Gateway окремий обліковий запис користувача ОС. * Фіксація залежностей опублікованого пакета: у робочих копіях вихідного коду використовується `pnpm-lock.yaml`; опублікований npm-пакет `openclaw` і пакети npm-плагінів, якими володіє OpenClaw, містять `npm-shrinkwrap.json`, щоб під час установлення використовувався перевірений транзитивний граф залежностей із випуску, а не формувався новий граф. Це межа посилення захисту ланцюга постачання та відтворюваності випуску, а не пісочниця — див. [npm shrinkwrap](/uk/gateway/security/shrinkwrap). * Безпечні файлові операції: OpenClaw використовує `@openclaw/fs-safe` для доступу до файлів у межах кореневого каталогу, атомарного записування, розпакування архівів, тимчасових робочих просторів і допоміжних засобів для файлів із секретами. Необов’язковий допоміжний засіб POSIX на Python типово **вимкнено**; задавайте `OPENCLAW_FS_SAFE_PYTHON_MODE=auto` або `require` лише тоді, коли потрібне додаткове посилення захисту операцій змінювання відносно файлового дескриптора й середовище підтримує виконання Python. Докладніше: [Безпечні файлові операції](/uk/gateway/security/secure-file-operations). * Ризик спільного робочого простору Slack: якщо всі користувачі Slack можуть надсилати повідомлення боту, основним ризиком є делеговані повноваження інструментів — будь-який дозволений відправник може ініціювати виклики інструментів (`exec`, браузера, мережевих і файлових інструментів) у межах політики агента, ін’єкція в підказку або вміст від одного відправника може вплинути на спільний стан, пристрої чи виведення, а якщо спільний агент має конфіденційні облікові дані або файли, будь-який дозволений відправник потенційно може спричинити витік даних через використання інструментів. Для командних робочих процесів використовуйте окремі агенти або Gateway з мінімальним набором інструментів; агентів із персональними даними залишайте приватними. * Спільний агент компанії (прийнятна модель): придатний, якщо всі користувачі агента належать до однієї межі довіри (наприклад, до однієї команди компанії), а сфера застосування агента суворо обмежена робочими завданнями. Запускайте його на окремому комп’ютері, віртуальній машині або контейнері, використовуйте окремого користувача ОС, окремий браузер, профіль і облікові записи та не входьте в цьому середовищі виконання до особистих облікових записів Apple/Google або особистих профілів менеджера паролів чи браузера. Поєднання особистих і корпоративних ідентичностей в одному середовищі виконання руйнує розмежування та збільшує ризик розкриття персональних даних. ## Секрети на диску Вважайте, що все в `~/.openclaw/` (або `$OPENCLAW_STATE_DIR/`) може містити секрети чи приватні дані: | Шлях | Вміст | | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `openclaw.json` | Конфігурація може містити токени (Gateway, віддалений Gateway), налаштування провайдерів і списки дозволених елементів. | | `credentials/**` | Облікові дані каналів (наприклад, облікові дані WhatsApp), списки дозволених для сполучення, імпортовані дані застарілого OAuth. | | `agents//agent/auth-profiles.json` | Ключі API, профілі токенів, токени OAuth, необов’язкові `keyRef`/`tokenRef`. | | `agents//agent/codex-home/**` | Обліковий запис сервера застосунку Codex, конфігурація, Skills, плагіни, власний стан гілок і діагностика для кожного агента (типово). | | `$CODEX_HOME/**` або `~/.codex/**` | Власний стан середовища виконання Codex. Звичайна обв’язка отримує до нього доступ лише з явним `plugins.entries.codex.config.appServer.homeScope: "user"`. Окреме з’єднання нагляду отримує до нього доступ, коли його визначена домашня область — `"user"`; це типове значення для stdio або Unix, якщо його не задано. Містить власний обліковий запис Codex, конфігурацію, плагіни та сховище гілок. Нагляд виводить метадані джерела й зберігає канонічну власну гілку продовженого чату та наступні ходи в цьому з’єднанні; розгалуження копіює обмежену збережену історію користувача й асистента до автентифікованого, прив’язаного до моделі чату OpenClaw. Вмикайте лише для Gateway під контролем власника. Див. [обв’язку Codex](/uk/plugins/codex-harness#share-threads-with-codex-desktop-and-cli) і [нагляд Codex](/plugins/codex-supervision). | | `secrets.json` (необов’язково) | Збережене у файлі секретне корисне навантаження, яке використовують провайдери SecretRef `file` (`secrets.providers`). | | `agents//agent/auth.json` | Файл зворотної сумісності із застарілими версіями; статичні записи `api_key` очищаються після виявлення. | | `agents//agent/openclaw-agent.sqlite` | Стан середовища виконання кожного агента, зокрема рядки сеансів і стенограми, які можуть містити приватні повідомлення та вивід інструментів. | | `agents//sessions/**` | Джерела й архіви міграції застарілих сеансів, які можуть містити приватні повідомлення та вивід інструментів. | | пакети вбудованих плагінів | Установлені плагіни (разом з їхніми `node_modules/`). | | `sandboxes/**` | Робочі простори пісочниць інструментів; можуть накопичувати копії файлів, прочитаних або записаних у пісочниці. | ### Карта зберігання облікових даних Також корисна для ухвалення рішень щодо резервного копіювання: * WhatsApp: `~/.openclaw/credentials/whatsapp//creds.json` * Токен бота Telegram: конфігурація/змінна середовища або `channels.telegram.tokenFile` (лише звичайний файл; символічні посилання відхиляються) * Токен бота Discord: конфігурація/змінна середовища або SecretRef (провайдери env/file/exec) * Токени Slack: конфігурація/змінна середовища (`channels.slack.*`) * Списки дозволених для сполучення: `~/.openclaw/credentials/-allowFrom.json` (типовий обліковий запис) / `--allowFrom.json` (нетипові облікові записи) * Профілі автентифікації моделей: `~/.openclaw/agents//agent/auth-profiles.json` * Імпортовані дані застарілого OAuth: `~/.openclaw/credentials/oauth.json` Посилення захисту: суворо обмежте дозволи (`700` для каталогів, `600` для файлів); використовуйте повнодискове шифрування на хості Gateway; якщо хост спільний, віддавайте перевагу окремому обліковому запису користувача ОС. ### Дозволи файлів * `~/.openclaw/openclaw.json`: `600` (читання та запис лише для користувача) * `~/.openclaw`: `700` (лише для користувача) `openclaw doctor` може попередити про це й запропонувати посилити ці обмеження. ### Файли `.env` робочого простору OpenClaw завантажує локальні для робочого простору файли `.env` для агентів та інструментів, але ніколи не дозволяє їм непомітно перевизначати елементи керування середовищем виконання Gateway: * Змінні середовища з обліковими даними провайдерів блокуються в ненадійних файлах робочого простору `.env` — наприклад, `GEMINI_API_KEY`, `GOOGLE_API_KEY`, `XAI_API_KEY`, `MISTRAL_API_KEY`, `GROQ_API_KEY`, `DEEPSEEK_API_KEY`, `PERPLEXITY_API_KEY`, `BRAVE_API_KEY`, `TAVILY_API_KEY`, `EXA_API_KEY`, `FIRECRAWL_API_KEY`, а також ключі автентифікації провайдерів, оголошені встановленими довіреними плагінами. Натомість розміщуйте облікові дані провайдерів у середовищі процесу Gateway, `~/.openclaw/.env` (`$OPENCLAW_STATE_DIR/.env`), блоці конфігурації `env` або необов’язковому імпорті з оболонки входу. * Будь-який ключ, що починається з `OPENCLAW_`, блокується в ненадійних файлах робочого простору `.env`, резервуючи весь простір імен середовища виконання, щоб майбутній параметр керування `OPENCLAW_*` за замовчуванням блокував доступ у разі помилки, а не мовчки успадковувався із зафіксованого в репозиторії або наданого зловмисником вмісту `.env`. * Параметри маршрутизації кінцевих точок каналів і провайдерів також блокуються для перевизначень із файлів робочого простору `.env` (наприклад, `MATRIX_HOMESERVER`, `MATTERMOST_URL`, `IRC_HOST`, `SYNOLOGY_CHAT_INCOMING_URL`, `AZURE_SPEECH_ENDPOINT` та інші ключі, що закінчуються на `_ENDPOINT`), тому клонований робочий простір не може перенаправити трафік вбудованих конекторів через локальну конфігурацію кінцевих точок. Вони мають надходити із середовища процесу Gateway, глобального dotenv середовища виконання, явної конфігурації або `env.shellEnv`. * Довірені змінні середовища процесу/ОС, глобальний dotenv середовища виконання, конфігурація `env` та ввімкнений імпорт з оболонки входу й надалі застосовуються — це обмежує лише завантаження файлів робочого простору `.env`. Файли робочого простору `.env` часто розташовані поруч із кодом агента, випадково потрапляють до комітів або записуються інструментами; блокування облікових даних провайдерів не дає клонованому робочому простору підмінити облікові записи провайдерів на контрольовані зловмисником. ### Журнали та транскрипти OpenClaw зберігає транскрипти сеансів на диску в `~/.openclaw/agents//sessions/*.jsonl` для безперервності сеансів і необов’язкового індексування пам’яті — будь-який процес або користувач із доступом до файлової системи може їх прочитати. Вважайте доступ до диска межею довіри та обмежте дозволи для `~/.openclaw`; для посиленої ізоляції запускайте агентів від імені окремих користувачів ОС або на окремих хостах. Журнали Gateway можуть містити зведення про інструменти, помилки та URL-адреси; транскрипти сеансів можуть містити вставлені секрети, вміст файлів, виведення команд і посилання. * Не вимикайте редагування конфіденційних даних у журналах і транскриптах (`logging.redactSensitive: "tools"`, значення за замовчуванням). * Додайте власні шаблони для свого середовища через `logging.redactPatterns` (токени, імена хостів, внутрішні URL-адреси). * Під час надання діагностичних даних віддавайте перевагу `openclaw status --all` (можна вставити, секрети відредаговано), а не необробленим журналам. * Видаляйте старі транскрипти сеансів і файли журналів, якщо тривале зберігання не потрібне. Докладніше: [Журналювання](/uk/gateway/logging) ## Безпечна базова конфігурація (копіювання та вставлення) ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { gateway: { mode: "local", bind: "loopback", port: 18789, auth: { mode: "token", token: "your-long-random-token" }, }, channels: { whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } }, }, }, } ``` Зберігає Gateway приватним, вимагає сполучення для приватних повідомлень і запобігає постійній роботі ботів у групах. Щоб також підвищити безпеку виконання інструментів, додайте пісочницю та забороніть небезпечні інструменти для всіх агентів, які не є власниками (див. «Профілі доступу для окремих агентів» вище). ### Окремі номери (WhatsApp, Signal, Telegram) Для каналів на основі номерів телефонів варто запускати помічника на окремому від особистого номері, щоб особисті розмови залишалися приватними, а номер бота обслуговував автоматизацію у власних межах. ## Реагування на інциденти ### Локалізація 1. Зупиніть систему: закрийте застосунок macOS (якщо він керує Gateway) або завершіть процес `openclaw gateway`. 2. Закрийте доступ: установіть `gateway.bind: "loopback"` (або вимкніть Tailscale Funnel/Serve), доки не з’ясуєте, що сталося. 3. Заморозьте доступ: перемкніть ризиковані приватні повідомлення/групи на `dmPolicy: "disabled"` / увімкніть вимогу згадок і видаліть усі записи `"*"`, що дозволяють доступ усім. ### Заміна (вважайте систему скомпрометованою, якщо секрети витекли) 1. Замініть дані автентифікації Gateway (`gateway.auth.token` / `OPENCLAW_GATEWAY_PASSWORD`) і перезапустіть його. 2. Замініть секрети віддалених клієнтів (`gateway.remote.token` / `.password`) на всіх машинах, які можуть викликати Gateway. 3. Замініть облікові дані провайдерів/API (облікові дані WhatsApp, токени Slack/Discord, ключі моделей/API у `auth-profiles.json` та значення зашифрованих корисних навантажень секретів, якщо вони використовуються). ### Аудит 1. Перевірте журнали Gateway: `/tmp/openclaw/openclaw-YYYY-MM-DD.log` (або `logging.file`). 2. Перегляньте відповідні транскрипти: `~/.openclaw/agents//sessions/*.jsonl`. 3. Перегляньте останні зміни конфігурації, які могли розширити доступ: `gateway.bind`, `gateway.auth`, політики приватних повідомлень/груп, `tools.elevated`, зміни плагінів. 4. Повторно запустіть `openclaw security audit --deep` і переконайтеся, що критичні проблеми усунуто. ### Збирання даних для звіту * Позначка часу, ОС хоста Gateway і версія OpenClaw. * Транскрипти сеансів і короткий фрагмент кінця журналу (після редагування конфіденційних даних). * Що надіслав зловмисник і що зробив агент. * Чи був Gateway доступний поза loopback (LAN/Tailscale Funnel/Serve). ## Сканування секретів CI запускає хук pre-commit `detect-private-key` для всього репозиторію. Якщо перевірка не проходить, видаліть або замініть зафіксований у репозиторії ключовий матеріал, а потім відтворіть перевірку локально: ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} pre-commit run --all-files detect-private-key ``` ## Повідомлення про проблеми безпеки Знайшли вразливість в OpenClaw? Повідомте про неї відповідально: 1. Електронна пошта: [security@openclaw.ai](mailto:security@openclaw.ai) 2. Не публікуйте інформацію до виправлення. 3. Ми зазначимо ваше авторство (якщо ви не віддаєте перевагу анонімності).