Почему я не даю AI-блогу доступ ко всему: WordPress, черновики и секреты

TL;DR: Я не даю ежедневному AI-агенту «доступ ко всему»: ему нужны отдельный пароль приложения WordPress и возможность создать черновик с обложкой — но не Telegram-токен и не право самостоятельно публиковать материал. Такая схема не делает автоматизацию неуязвимой, зато уменьшает радиус ошибки и оставляет человеку понятную точку контроля.

Ключевые факты

Факт	Что это значит для моего конвейера	Источник
Пароль приложения WordPress можно создать отдельно, отозвать и проверить его последнее использование	Я не передаю cron-агенту основной пароль от панели и могу отключить именно эту интеграцию	WordPress Core: Application Passwords
REST API WordPress принимает поля status, categories и featured_media при создании записи	Статус черновика, рубрика и обложка задаются явно в одном запросе, а не остаются на волю настроек по умолчанию	WordPress REST API: Posts
Медиа загружаются через отдельный endpoint POST /wp/v2/media	Обложка и статья — две разные операции; успех загрузки картинки ещё не означает, что черновик создан	WordPress REST API: Media
OWASP рекомендует ограничивать доступ к секретам принципом наименьших привилегий и не выводить секреты в логи	Процесс написания статьи не должен получать токены сервисов, которыми он не пользуется	OWASP Secrets Management Cheat Sheet

Почему я перестал считать один файл с токенами «просто настройкой»

У моего ежедневного конвейера понятная работа: выбрать новую тему, проверить факты, сделать обложку, загрузить её в WordPress и создать запись. Из этого списка легко сделать неправильный вывод: раз агент уже автоматический, пусть получает все ключи, которые лежат рядом, — вдруг пригодятся.

Я делаю наоборот. Для текущего запуска агент читает только те значения, которые нужны для генератора изображения и WordPress REST API. Telegram-токен ему не нужен, потому что отправка в канал — задача другого процесса. Даже если токен технически находится на той же машине, отсутствие шага «прочитать и использовать Telegram» — важная граница. Ошибка в авторе черновика не должна автоматически превращаться в ошибку перед всей аудиторией.

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

Что у меня сработало

Лучше всего работает не сложная система безопасности, а несколько скучных явных ограничений:

• в запросе на создание записи всегда стоит status: draft;
• рубрика передаётся числовым ID, а не определяется догадкой;
• обложка сначала загружается как медиа, затем её ID передаётся в featured_media;
• публикация и кросспостинг вынесены в отдельный процесс с отдельной логикой;
• в журнал запуска попадают тема, ID записи и ссылка на редактирование, но не пароли и токены.

Главное здесь — не сам AI. Главное — контракт между этапами. Автор черновика может подготовить материал, но не должен самовольно завершать редакционный цикл.

Что ломается и как я это замечаю

У такой схемы есть неприятная особенность: одна статья создаётся не одним действием. Генератор изображения может вернуть ошибку. Картинка может загрузиться, а запрос создания записи — нет. WordPress может принять запись, но пользовательский meta-параметр SEO-плагина не сохранится. Наконец, другой процесс может изменить статус записи сразу после создания.

Поэтому зелёный ответ одной операции для меня не равен успешному выпуску. После POST-запроса я проверяю полученный объект: есть ли числовой ID, остался ли статус draft, присутствует ли рубрика 73 и привязана ли обложка. Только после успешного создания черновика тема добавляется в журнал уже покрытых материалов. Иначе журнал начнёт уверять меня, что статья существует, хотя в WordPress её нет.

Есть и честное ограничение: хранение ключей в локальном .env — это практичный минимум для моего небольшого процесса, а не эталонное хранилище секретов. Такой файл нельзя коммитить, печатать в диагностике или бездумно отдавать всем процессам. По мере роста системы правильный следующий шаг — отдельное хранилище секретов, ограниченные учётные роли и регулярная проверка того, какие ключи вообще ещё используются.

Частые вопросы (FAQ)

Почему не разрешить агенту сразу публиковать, если текст всё равно проверяется автоматически?

Потому что автоматическая проверка тоже может ошибиться или не запуститься. Черновик создаёт дешёвую и понятную точку остановки: материал уже в WordPress, но ещё не виден читателям.

Пароль приложения WordPress безопаснее обычного пароля?

Он удобнее именно для интеграции: его можно создать и отозвать отдельно, не раскрывая основной пароль. Но сам пароль приложения остаётся секретом и при утечке даёт действия в рамках прав соответствующего пользователя. Поэтому важны HTTPS, ограниченная роль и отсутствие секрета в логах.

Почему нельзя просто хранить все токены в одном .env?

Файл сам по себе не разделяет полномочия. Если любой процесс читает весь файл, компрометация одного шага открывает доступ ко всем сервисам. Минимум — загружать только нужные переменные и не логировать их; лучше — разнести секреты по процессам или использовать специализированное хранилище.

Зачем проверять категорию после создания записи?

Потому что успешный HTTP-ответ ещё не доказывает, что все поля сохранились так, как ожидалось. Для этого дневника правильная категория — часть результата наравне с заголовком и статусом.

Итог

Моя рабочая формула сейчас простая: агент получает ровно те доступы, которые нужны для обложки и черновика; WordPress получает явные draft, рубрику и ID медиа; Telegram остаётся за пределами этого процесса; финальный объект перепроверяется после записи. Это не «безопасность один раз и навсегда», а небольшой радиус ошибки и проверяемый след — именно то, что мне нужно от ежедневной автоматизации блога.

---

Автор: Denis | Дата: 31.10.2026 | Обновлено: 31.10.2026
Denis — трейдер с 10+ летним опытом на форексе и крипторынках