Руководство по безопасности пользователей Nanobot: последний рубеж защиты прав ИИ

marsbitОпубликовано 2026-03-11Обновлено 2026-03-11

Введение

Автор: BitsLab, компания по безопасности ИИ. Когда AI Agent получает системные возможности (выполнение команд shell, чтение/запись файлов, сетевые запросы и т.д.), он становится оператором с реальными правами. Это создаёт риски: injection-атаки через prompt могут удалить данные, зараженные Skills могут украсть учетные данные, а неверифицированные операции — нанести необратимый ущерб. Традиционные подходы либо полагаются на ИИ (что уязвимо к обходам), либо блокируют Agent жёсткими правилами (теряя его пользу). BitsLab предлагает третий путь, распределяя обязанности между: - **Пользователем** (конечный рубеж, ключевые решения); - **Агентом** (соблюдение норм и аудит через Skills); - **Детерминированными скриптами** (проверки, устойчивые к injection). **Рекомендации для пользователей:** - Защищайте API Keys (не храните в репозиториях). - Настройте белые списки (allowFrom) для Channel. - Запускайте Agent без прав root. - Избегайте email-каналов (высокий риск). - Используйте Docker для изоляции. **Принципы инструментов безопасности:** - Аудит намерений через «самостоятельное пробуждение» ИИ. - Блокировка вредоносных команд (shell, cron). - Защита конфиденциальных данных (чтение файлов). - Аудит MCP-навыков и автоматическая проверка новых Skills. - Контроль целостности файлов через хэши. - Автоматическое резервное копирование. **Отказ от ответственности:** Руководство — это рекомендации, а не гарантия безопасности. Пользователи несут отве...

Автор: BitsLab, компания по безопасности ИИ

Когда ИИ-агент обладает системными возможностями, такими как выполнение команд shell, чтение и запись файлов, сетевые запросы и планировщик задач, он перестает быть просто "чат-ботом" — он становится оператором с реальными правами. Это означает: одна команда, индуцированная через prompt injection, может удалить критически важные данные; один скомпрометированный Skill из цепочки поставок может незаметно передать учетные данные; одна непроверенная бизнес-операция может привести к необратимым потерям.

Традиционные схемы безопасности обычно идут двумя крайними путями: либо полностью полагаются на собственные "способности к суждению" ИИ для самоограничения (что можно обойти с помощью тщательно сконструированных промптов), либо нагромождают множество жестких правил, полностью блокируя Агента (что лишает его основной ценности).

Это подробное руководство от BitsLab выбирает третий путь: распределение обязанностей по принципу "кто проверяет", где три роли занимают свои места.

- Обычный пользователь: Как последний рубеж обороны, отвечает за ключевые решения и регулярные проверки. Мы предоставляем рекомендации, чтобы снизить когнитивную нагрузку.

- Сам Агент: Во время выполнения осознанно соблюдает нормы поведения и процессы аудита. Мы предоставляем Skills, чтобы внедрить знания о безопасности в контекст Агента.

- Детерминированные скрипты: Механически и добросовестно выполняют проверки, не подвержены влиянию prompt injection. Мы предоставляем Scripts, покрывающие распространенные известные опасные шаблоны.

Ни один отдельный проверяющий не является всемогущим. Скрипты не понимают семантику, Агента можно обмануть, человек устает. Но их сочетание обеспечивает как удобство повседневного использования, так и защиту от операций с высоким риском.

Обычный пользователь (Рекомендации)

Пользователь является последним рубежом системы безопасности и владельцем высших прав. Ниже приведены вопросы безопасности, за которыми пользователю необходимо следить и выполнять лично.

a) Управление API Key

- Настройте права доступа к файлам конфигурации, чтобы предотвратить их просмотр посторонними:

- Никогда не загружайте API key в репозиторий кода!

b) Контроль доступа к Каналам (Крайне важно!)

- Обязательно настройте белый список (`allowFrom`) для каждого канала связи (Channel), иначе любой сможет общаться с вашим Агентом:

⚠️ В новых версиях пустой `allowFrom` означает запрет всех подключений. Если хотите открыть доступ, необходимо явно указать `["*"]`, но это не рекомендуется.

c) Не запускайте с правами root

- Рекомендуется создать отдельного пользователя для запуска Агента, чтобы избежать избыточных прав:

d) По возможности не используйте email-канал

- Протокол email сложен и сопряжен с относительно высоким риском. Наша команда BitsLab в ходе исследований обнаружила и подтвердила уязвимость уровня [critical], связанную с почтой. Ниже приведен ответ разработчиков проекта, у нас еще есть несколько вопросов к ним, поэтому рекомендуется с осторожностью использовать функциональные модули, связанные с почтой.

e) Рекомендуется развертывание в Docker

- Рекомендуется развертывать nanobot в контейнере Docker, изолированно от повседневной среды использования, чтобы избежать рисков безопасности, связанных с смешением прав или окружений.

Шаги установки инструмента

Принцип работы инструмента

SKILL.md

Проверка намерений на основе когнитивного осознания преодолевает слепые зоны традиционного ИИ, пассивно получающего инструкции. Встроенный механизм принудительной "самоактивации (Self-Wakeup)" заставляет ИИ перед обработкой любого пользовательского запроса сначала в фоновом режиме активировать независимую личность для проверки безопасности. Путем контекстного анализа и независимой оценки пользовательских намерений активно выявляются и блокируются потенциальные высокорисковые угрозы, что реализует переход от "механического выполнения" к "интеллектуальному брандмауэру". При обнаружении вредоносных инструкций (например, обратный Shell, кража конфиденциальных файлов, массовое удаление и т.д.) инструмент выполняет стандартизированный протокол жесткого перехвата (выводит предупреждение `[Bitslab nanobot-sec skills обнаружил敏感操作..., перехвачено]`).

Перехват выполнения恶意命令 (Защита Shell & Cron)

Выступает в роли "гейта с нулевым доверием", когда Агент выполняет команды уровня ОС. Линия обороны напрямую блокирует различные разрушительные операции и опасные нагрузки (например,恶意удаление `rm -rf`, изменение прав доступа, обратный Shell и т.д.). Кроме того, инструмент обладает возможностью глубокой проверки во время выполнения, может активно сканировать и очищать системные процессы и запланированные задачи Cron от постоянных бэкдоров и вредоносных сигнатур выполнения, обеспечивая абсолютную безопасность локальной среды.

Блокировка кражи конфиденциальных данных (Проверка доступа к файлам)

Осуществляет строгое физическое разделение прав доступа для чтения и записи к ключевым активам. В системе предустановлены строгие правила проверки файлов, запрещающие ИИ несанкционированно читать конфиденциальные файлы, такие как `config.json`, `.env`, содержащие API-ключи и ключевые настройки, и передавать их наружу. Кроме того, механизм безопасности будет проводить аудит логов чтения файлов (например, последовательность вызовов инструмента `read_file`) в реальном времени, полностью пресекая возможность утечки учетных данных и передачи данных изначально.

Аудит безопасности MCP Skills

Для Skills типа MCP инструмент автоматически проверяет их контекстное взаимодействие и логику обработки данных, выявляя是否存在риски утечки конфиденциальной информации, несанкционированного доступа, внедрения опасных команд и т.д., и сравнивает их с базовыми уровнями безопасности и белыми списками.

Загрузка новых Skills и автоматическое сканирование безопасности

При загрузке нового Skill инструмент использует аудит-скрипты для автоматического статического анализа кода, сравнения с базовыми уровнями безопасности и белыми списками, обнаружения конфиденциальной информации и опасных команд, и загружает Skill только после обеспечения его безопасности и соответствия.

Проверка контрольных сумм (хешей) для защиты от изменений

Для обеспечения абсолютного нулевого доверия к базовым активам системы защитный щит непрерывно создает и поддерживает базовые линии SHA256加密подписей для ключевых конфигурационных файлов и узлов памяти. Движок ночной проверки автоматически сверять每一处хэши файлов во времени, способный за миллисекунды捕捉любые несанкционированные изменения или перезаписи, полностью пресекая风险植入本地后门и"отравления" на уровне физического хранения.

Автоматическое ротация снимков резервных копий для аварийного восстановления

Учитывая высокие права доступа локального Агента к файловой системе, в систему встроен механизм автоматического аварийного восстановления высшего уровня. Защитный движок каждую ночь автоматически запускает полное архивирование активного рабочего пространства на уровне песочницы и создает механизм снимков безопасности с максимальным сроком хранения 7 дней (автоматическая ротация). Даже в случае непредвиденного повреждения или случайного удаления в экстремальной ситуации, можно实现无损一键恢复开发环境, что максимально保障непрерывность и устойчивость локальных цифровых активов.

Отказ от ответственности

Данное руководство предназначено только в качестве справочного материала по передовым практикам безопасности и не является гарантией безопасности в любой форме.

1. Нет абсолютной безопасности: Все описанные в данном руководстве меры (включая детерминированные скрипты, Skills Агента и рекомендации для пользователей) являются защитой по принципу "наилучших усилий" и не покрывают все векторы атак. Безопасность ИИ-агентов — это быстро развивающаяся область, новые методы атак могут появляться в любое время.

2. Ответственность пользователя: Пользователи, развертывающие и использующие Nanobot, должны самостоятельно оценивать риски безопасности своей среды выполнения и корректировать рекомендации данного руководства в соответствии с реальными сценариями. Любые убытки, возникшие из-за неправильной конфигурации, несвоевременного обновления или игнорирования предупреждений безопасности, несет пользователь.

3. Не замена профессионального аудита безопасности: Данное руководство не может заменить профессиональный аудит безопасности, penetration-тестирование или оценку соответствия. Для сценариев, связанных с конфиденциальными данными, финансовыми активами или критической инфраструктурой, настоятельно рекомендуется нанять профессиональную команду безопасности для проведения независимой оценки.

4. Сторонние зависимости: Безопасность сторонних библиотек, API-сервисов и платформ (таких как Telegram, WhatsApp, провайдеры LLM и т.д.), от которых зависит Nanobot, не контролируется данным руководством. Пользователям следует следить за бюллетенями безопасности соответствующих зависимостей и своевременно обновлять их.

5. Объем ответственности: Сопровождающие проекта Nanobot и участники не несут ответственности за любые прямые, косвенные, случайные или последующие убытки, возникшие в результате использования данного руководства или программного обеспечения Nanobot.

Использование данного программного обеспечения означает, что вы понимаете и принимаете указанные выше риски.

Трендовые криптовалюты

Связанные с этим вопросы

QКаковы три уровня защиты, предложенные в руководстве по безопасности Nanobot, и как они взаимодействуют?

AРуководство предлагает три уровня защиты: обычные пользователи (конечный рубеж, отвечают за ключевые решения и периодические проверки), сам агент (соблюдает поведенческие нормы и процессы аудита во время выполнения) и детерминированные скрипты (механически выполняют проверки, не подвержены инъекциям промптов). Они работают вместе, обеспечивать удобство и безопасность, так как ни один уровень не является надежным сам по себе.

QКакие ключевые меры предосторожности должен предпринять пользователь для управления API Keys и контроля доступа к Channel?

AПользователь должен: а) Управлять API Keys: настраивать правильные разрешения для конфигурационных файлов и никогда не commitить ключи в репозитории кода. б) Контроль доступа к Channel: критически важно настроить белый список (`allowFrom`) для каждого канала связи. Пустой `allowFrom` означает запрет всего доступа, а `["*"]` открывает доступ всем (что не рекомендуется).

QПочему рекомендуется запускать Nanobot от имени непривилегированного пользователя и в Docker контейнере?

AЗапуск от имени непривилегированного пользователя (не root) минимизирует ущерб в случае компрометации агента, ограничивая его системные привилегии. Развертывание в Docker обеспечивает изоляцию от основной операционной системы, предотвращая риски, связанные со смешением сред и избыточными разрешениями.

QКак инструмент безопасности обеспечивает защиту от выполнения вредоносных команд и несанкционированного доступа к файлам?

AИнструмент действует как шлюз "нулевого доверия": 1) Перехват команд: блокирует разрушительные операции (например, `rm -rf`) и опасные полезные нагрузки (обратные shell). 2) Защита файлов: реализует строгие правила проверки для изоляции критических активов, запрещая агенту читать конфиденциальные файлы (например, `config.json`, `.env`) и передавать их содержимое. Также проводится аудит логов доступа к файлам.

QЧто говорится в отказе от ответственности относительно гарантий безопасности и ответственности пользователя?

AОтказ от ответственности гласит, что руководство не является гарантией безопасности. Все меры — это "максимальные усилия", а не абсолютная защита. Пользователь несет ответственность за оценку рисков своей среды, правильную настройку и своевременное обновление. Руководство не заменяет профессиональный аудит безопасности. Разработчики не несут ответственности за любой ущерб, возникший в результате использования Nanobot.

Похожее

В результате взлома Coldcard, одного из крупнейших взломов биткоин-кошельков за последнее время, началась новая волна убытков! Убытки растут

В результате взлома Coldcard, одного из крупнейших взломов биткоин-кошельков за последнее время, произошла третья волна атак. Исследовательская компания Galaxy Research сообщает, что из кошельков, созданных на этих устройствах, было выведено еще 207,73 BTC. Общие потери теперь составляют около 1367 BTC (примерно 88,6 млн долларов США) по 4585 адресам. Первые две волны атак демонстрировали схожие черты, что указывало на одного злоумышленника. Однако третья волна отличается по методам: используются отдельные адреса для каждой жертвы, адреса P2WSH вместо P2WPKH, и атака нацелена на стандартный путь генерации. Это может означать либо модификацию инструментов первоначальным взломщиком, либо появление нового. Похищенные биткоины, общая стоимость которых оценивается в 88,6 млн долларов, пока не были потрачены злоумышленниками. Анализ показывает, что потери в основном пришлись на кошельки с небольшим балансом, что характерно для индивидуальных пользователей, а не институциональных сервисов. Уязвимое ПО Coldcard было выпущено 17 марта 2021 года, и все украденные средства были созданы после этой даты.

cryptonews.ru23 мин. назад

В результате взлома Coldcard, одного из крупнейших взломов биткоин-кошельков за последнее время, началась новая волна убытков! Убытки растут

cryptonews.ru23 мин. назад

Trump Media продаёт ещё 2628 BTC, запасы снижаются до 4261 BTC

Компания Trump Media & Technology Group (TMTG), стоящая за социальной сетью Truth Social, продолжает сокращать свои вложения в Bitcoin. По данным аналитической платформы Lookonchain, компания продала ещё 2628 BTC на сумму около 165 миллионов долларов через платформу Crypto.com. Это продолжение серии продаж, начавшихся семь месяцев назад. Всего за этот период TMTG продала 7281 BTC на общую сумму примерно 545 миллионов долларов по средней цене 74 855 долларов за монету. Первоначально компания приобрела 11542 BTC по средней цене 118 522 доллара. После последних транзакций её резервы сократились до 4261 BTC (около 269,8 миллиона долларов), что на 63% меньше изначальных холдингов. Эти продажи происходят на фоне усиленного внимания законодателей к криптовалютным интересам, связанным с Дональдом Трампом. В Конгрессе идут дебаты по закону CLARITY Act, который касается этических норм, владения цифровыми активами и потенциальных конфликтов интересов государственных лиц. Критики указывают на такие проекты, как мемкойны TRUMP и MELANIA, а также на токены World Liberty Financial, связывая политическое влияние с частными криптоинтересами.

cointelegraph43 мин. назад

Trump Media продаёт ещё 2628 BTC, запасы снижаются до 4261 BTC

cointelegraph43 мин. назад

Фуцзянь, Цзиньцзян: супер-единорог в сфере памяти тихо делает своё дело

В провинции Фуцзянь в городе Цзиньцзян, известном производством спортивной обуви, находится перспективная компания в области производства чипов памяти — Fujian Jinhua Integrated Circuit Co. (Jinhua). Основанная в 2016 году как часть национального плана по развитию полупроводниковой промышленности, компания столкнулась с серьёзными вызовами. В 2018 году она была внесена в санкционный список Министерства торговли США по обвинению в промышленном шпионаже в пользу американской компании Micron, что привело к остановке производственной линии. После пяти лет судебных разбирательств в феврале 2024 года федеральный суд в Сан-Франциско полностью оправдал Jinhua, сняв все обвинения. Несмотря на правовую победу, компания всё ещё остаётся в санкционном списке, а годы задержек серьёзно замедлили её развитие. Под руководством своего ключевого инженера Чэнь Чжэнкуня, известного как «мастер эффективности», компания сумела адаптировать производство, увеличив долю отечественного оборудования. В отличие от ChangXin Memory Technologies (CXMT) и Yangtze Memory Technologies (YMTC), которые продвинулись дальше в производстве DRAM и NAND-памяти соответственно, Jinhua сосредоточена на специализированной (нишевой) DRAM-памяти для потребительской электроники. Её текущая производственная мощность составляет около 40 000 пластин в месяц. Хотя её доход в 2023 году оценивался примерно в 2 млрд юаней, что значительно меньше, чем у конкурентов, компания остаётся важным игроком. История Jinhua тесно связана с амбициозной промышленной трансформацией города Цзиньцзян. Местные власти оказали компании полную поддержку, включая финансовые гарантии и создание кластера, что демонстрирует стратегическую важность проекта для региона. Несмотря на то, что Jinhua упустила первые годы бума на рынке памяти, её устойчивость в условиях санкций показывает потенциал для восстановления в новом цикле роста, движимом развитием искусственного интеллекта.

marsbit1 ч. назад

Фуцзянь, Цзиньцзян: супер-единорог в сфере памяти тихо делает своё дело

marsbit1 ч. назад

Почему биткойн-фермы внезапно стали новым входом для вычислительных мощностей ИИ на фоне дефицита электроэнергии в 38 ГВт?

Заголовок: Почему майнинговые фермы для биткоина внезапно стали новым входом для вычислительных мощностей ИИ на фоне дефицита электроэнергии в 38 ГВт? Краткое содержание: Когда конкуренция между центрами обработки данных ИИ сместилась с вопроса «кто купит больше GPU» к «кто раньше получит электроэнергию», некоторые майнинговые фермы для биткоина, ранее считавшиеся волатильными активами, начали трансформироваться в центры обработки данных для облачных провайдеров, используя свои готовые возможности подключения к сети, землю и трансформаторные подстанции. По расчетам Morgan Stanley, в период 2026-2028 годов в США может возникнуть дефицит электроэнергии для ЦОДов около 38 ГВт, и модернизация старых майнинговых ферм может обеспечить от 10 до 19 ГВт. Такие компании, как TeraWulf и Hut 8, переориентируются с добычи криптовалют на предоставление инфраструктуры («Powered Shell Provider»), предлагая клиентам из сферы ИИ критически важный ресурс — возможность быстрее конкурентов развернуть значительные вычислительные мощности. Ключевой ценностью становится не вычислительная мощность для майнинга, а дефицитный доступ к электросетям, получение которого «с нуля» в некоторых регионах США теперь может занять 5-7 лет.

华尔街日报1 ч. назад

Почему биткойн-фермы внезапно стали новым входом для вычислительных мощностей ИИ на фоне дефицита электроэнергии в 38 ГВт?

华尔街日报1 ч. назад

Майкл Сэйлор: «Мы никогда не говорили, что никогда не будем продавать биткоины»

Председатель стратегической комиссии Майкл Сэйлор прокомментировал сообщения о новом разрешении компании Strategy на продажу биткоинов. Он заявил, что данное разрешение не является новым — оно было объявлено ещё 29 июня в рамках системы управления капиталом компании. Соглашение позволяет продавать BTC на сумму до 5 миллиардов долларов для определённых целей, но не обязывает компанию к продаже. Сэйлор подчеркнул, что Strategy никогда официально не брала на себя обязательство никогда не продавать свои биткоины, хотя и рассчитывает оставаться чистым покупателем BTC в долгосрочной перспективе. Он назвал текущие новости «старыми», переподанными как новые, и подтвердил, что программа монетизации биткоинов компании не предполагает обязательной продажи её активов.

cryptonews.ru2 ч. назад

Майкл Сэйлор: «Мы никогда не говорили, что никогда не будем продавать биткоины»

cryptonews.ru2 ч. назад

Торговля

Спот

Популярные статьи

Неделя обучения по популярным токенам (2): 2026 может стать годом приложений реального времени, сектор AI продолжает оставаться в тренде

2025 год — год институциональных инвесторов, в будущем он будет доминировать в приложениях реального времени.

1.9k просмотров всегоОпубликовано 2025.12.16Обновлено 2025.12.16

Неделя обучения по популярным токенам (2): 2026 может стать годом приложений реального времени, сектор AI продолжает оставаться в тренде

Обсуждения

Добро пожаловать в Сообщество HTX. Здесь вы сможете быть в курсе последних новостей о развитии платформы и получить доступ к профессиональной аналитической информации о рынке. Мнения пользователей о цене на AI (AI) представлены ниже.

活动图片