Почему CLI NotHoly, а не обычный помощник в терминале

Помощник в терминале, который отказывается читать disassembly или набросать payload, мало полезен для работы по безопасности. Тот, что запускает ваши команды на своём сервере, хуже, потому что трафик к вашей цели уходит с адреса, который никто не вносил в scope. CLI NotHoly не делает ни того, ни другого. Он работает на вашей машине, действует только с вашего одобрения, а модель за ним берёт работу, а не читает нотацию. Методология в сценарии pentest; здесь речь об инструменте.

#Он работает там, где ваши инструменты

notholy открывает агента в вашем проекте. Он читает и ищет файлы, правит и пишет их, запускает команду, и достаёт до lookup CVE, базы знаний и web-поиска. Каждая команда и каждая запись идут на вашей машине, под вашим пользователем, и режим по умолчанию спрашивает перед каждой. Режим plan это только чтение, auto-edit пишет без вопроса, но всё равно спрашивает перед запуском команды, а yolo не спрашивает ничего и его надо задавать на каждый запуск. Серверы NotHoly никогда не запускают ничего против ваших целей. Заметки проекта идут в NOTHOLY.md, а содержимое файлов и вывод команд считаются данными, никогда инструкциями агенту, так что подложенный README не уведёт его. Slash-команды меняют модель, режим и усилие reasoning посреди сессии, /cost показывает, сколько потратил прогон, а сессии хранятся в ~/.notholy/sessions с правами только для владельца.

#Scope, который можно навязать

notholy engage записывает, чего может касаться тест, и проверяет каждую команду против этого перед запуском. Вы даёте имя, scope из hosts, wildcard, IP и CIDR, ссылку на вашу авторизацию и временное окно. Команда в scope проходит обычное одобрение. Цель вне scope заставляет вас набрать host и пишет исключение в лог, а yolo выключен, пока engagement активен. Каждое решение идёт в log.jsonl с командой, целями, кодом выхода и хэшем вывода, каждая строка сцеплена с предыдущей, так что запись защищена от подделки. Правила живут вне repo, так что репозиторий не подсунет свой scope. Документация агента в терминале содержит флаги.

notholy engage init --name acme-q4 --scope "*.acme-staging.test,10.20.0.0/24" --auth "contract 2026-117"

#Пропустите через pipe или рулите другими агентами

Для разового ответа notholy "..." читает стандартный ввод, так что инструменты, которые вы уже запускаете, могут его кормить.

git diff | notholy "review this diff for injection bugs"

notholy connect и notholy run направляют Claude Code, Codex или OpenCode на модели NotHoly и регистрируют локальный MCP-сервер с инструментами CVE, advisory и базы знаний, так что агент, которым вы уже пользуетесь, получает эти данные без ключа в своей конфигурации. connect сначала делает бэкап конфигурации инструмента, а --undo его восстанавливает, и ключ остаётся в login самого CLI, а не в файле инструмента. Долгая сессия сжимается до того, как пройдёт размер контекста модели, с резюме, которое хранит цель, решения и находки.

#Где не подходит

Страж engagement читает текст команды и не резолвит DNS, так что он ловит ошибку, а не продуманный обход. Это не sandbox, и команда всё ещё может достать до host, который она не называет. yolo запускает всё без вопроса и может менять файлы и запускать команды, которые вы не прочитали, так что держите его для черновой папки. Команда, которую вы одобряете, идёт с вашими правами, так что читайте карточку до того, как разрешить. CLI нужен login, так что он привязан к аккаунту и e-mail. Модель может ошибаться, как любая модель, и вывод это черновик для проверки, а не результат, которому можно верить. Он также не заменяет суждения: scope, авторизация и решение запускать ваши.

Держите команды, файлы и риск на своей машине, а чтение оставьте модели. Поставьте CLI, потом пополните небольшой баланс на тарифах.