HackerNoon Weekly Digest

01

Спред-оператор переписал chatId: одна строка во Flowise отдала чужие диалоги

✍ aviral srivastava HackerNoon ⏱ ≈10 мин ai-agent-security vulnerability-research

О чём

Разбор CVE-2026-69258: в конце объектного литерала flowConfig стоит ...incomingInput.overrideConfig, и всё, что пришло в теле запроса, перекрывает поля выше — включая идентичность разговора. Нужная проверка apiOverrideStatus в файле есть, но лежит двадцатью строками ниже и на этот путь не распространяется. Читать стоит не ради Flowise: «переопределение параметров запроса» есть в любом оркестраторе, и пишет оно в тот же объект, где хранится сессия.

🔑 Главное

Неаутентифицированный POST на /api/v1/prediction/:id подменяет chatId и открывает чужую переписку; перечислить цели помогает GET /api/v1/public-chatflows.
Через chatHistory модели подсовывают выдуманное прошлое. С моделью не спорят — ей просто выдают другую историю.
Приёмник — резолвер шаблонов {{$flow.*}} на lodash get, поэтому вложенные ключи адресуются на любой глубине.
CVSS 4.0 — 8,8. Версии по 3.1.2 включительно уязвимы, починено в 3.1.3: PR #6279, коммит 23b997e, спред заменён на pick по списку разрешённых полей.
Дыра: приведённый в статье grep ищет пять конкретных имён переменных и не ловит ...userInput — тот самый случай, что вынесен в заголовок. Список надо расширять руками, иначе получите ложное «чисто».

⚡ Попробовать за вечер

Пройтись по своему TS-сервису: grep -rnE '\.\.\.[A-Za-z_$][A-Za-z0-9_$.]*' --include='*.ts' src/ и отобрать спреды, куда попадает тело запроса.
Вторым проходом найти шлюзы (apiOverrideStatus|allowOverride|canOverride) и сверить два списка по файлу и строке.
Над каждым неприкрытым спредом прочитать объявленные ключи: нашли chatId, sessionId, userId — заменить на явный pick(input, ALLOWED).
Метрика: ни одного спреда из тела запроса без списка разрешённых полей рядом.

🔗 Read on HackerNoon Advisory GHSA PR #6279

02

Почта для агента без права писать: односторонний mbsync вместо галочки «read-only»

✍ Ivan Kuznetsov HackerNoon large-language-models docker authentication

О чём

Автор собрал MCP-сервер к своему ящику и сделал «только чтение» свойством схемы, а не настройки: mbsync зеркалит IMAP в локальный maildir, конфиг сервер генерирует сам при старте в приватный временный каталог, так что переправить Sync Pull на Sync Push некому. Поиск отдан notmuch, а сам Go-процесс ходит в IMAP ровно один раз за аккаунт — на LIST. Полезно всем, кто пускает агента к чужому тексту.

🔑 Главное

Зеркало односторонним делают четыре директивы: Sync Pull, Create Near, Remove None, Expunge None. Удаление на сервере не доезжает до диска, запись с диска — до сервера.
Одиннадцать read-only инструментов поверх streamable HTTP, OAuth-сервер живёт в том же процессе, зависимостей всего две.
Против инъекций — одна точка: весь текст письма проходит через render(), который заворачивает его в маркеры и ломает попытки подделать закрывающий. Смещения для пагинации считаются по исходному тексту, чтобы чистка не сдвинула границы страниц.
Эксплуатация описана честно: квота IMAP у Gmail около 2 500 МБ в сутки; зависший сокет держал блокировку восемь часов, лечится дедлайном в час и удвоением паузы; PDF на 2 МБ разворачивается в 2,7 МБ base64, поэтому вложения отдаются ссылками.
Дыра: установочного пути в статье нет — ни compose-файла, ни секции IMAPAccount вокруг тех четырёх директив, ни шагов регистрации OAuth. И «только чтение» не равно «безопасно»: автор сам пишет, что одна парольная фраза открывает весь ящик, а neutralize() мешает подделать маркер, но не обезвреживает само содержимое письма.

⚡ Попробовать за вечер

Направить mbsync на один аккаунт с теми четырьмя директивами и проиндексировать получившийся maildir через notmuch.
Отдать индекс агенту подпроцессом и проверить запросом вида from:marco date:2025 attachment:zip.
Если свой MCP-сервер уже отдаёт модели чужой текст — свести все строки в один render(), чтобы обёртку нельзя было забыть в одном инструменте из одиннадцати.
Метрика: попытка агента удалить письмо не меняет ничего на сервере.

Схема: односторонний mbsync из IMAP в maildir, индекс notmuch и MCP-сервер с одиннадцатью read-only инструментами — **На картинке:** тот самый односторонний путь — **PULL ONLY** от ящика к зеркалу и подписанное пунктиром **NO WRITE PATH** обратно; те же одиннадцать read-only инструментов, о которых говорит текст.

🔗 Read on HackerNoon Репозиторий

03

MCP-сервер к железу за вечер: dry run по умолчанию и запрет, который нельзя уговорить

✍ Real Paul HackerNoon mcp network-automation ai-agent

О чём

Пошаговая сборка MCP-сервера на FastMCP к Cisco ACI поверх бесплатной песочницы DevNet. Ценность не в Cisco: автор описывает трёхуровневую защиту инструментов, которые что-то меняют, и эти три уровня переносятся на любой MCP-сервер — хоть к Stripe, хоть к кластеру.

🔑 Главное

pip install requests mcp, Python 3.10+, один файл, регистрация одной строкой: claude mcp add aci-lab -- python3 aci_mcp_server.py. Первый прогон вернул все 13 тенантов и сошёлся с дашбордом APIC.
Уровень 1: любой write по умолчанию — dry run, реальное действие требует confirm=True.
Уровень 2: delete_tenant отказывается трогать common, infra и mgmt, причём проверка стоит до ветки с подтверждением — уговорить её нельзя.
Уровень 3 родился из находки: APIC отвечает «успех» на создание Bridge Domain со ссылкой на несуществующий VRF. Автор добавил предварительную проверку _vrf_exists и аудит get_tenant_detail, который помечает «NO VRF (incomplete)». Вывод шире Cisco: результат записи проверяют по независимому сигналу, а не по коду ответа API.
Дыра: confirm=True — не настоящий шлюз, модель вправе выставить его сразу в первом вызове, так что структурно защищает только жёсткий список имён. Пароль от песочницы в статье не назван, тела большинства из 21 инструмента свёрнуты в многоточие, а в репозитории python-dotenv лежит в зависимостях, но load_dotenv() не вызывается — переменные придётся экспортировать руками.

⚡ Попробовать за вечер

Собрать сервер из первых двух шагов, взять доступы к постоянно доступной песочнице на devnetsandbox.cisco.com, экспортировать APIC_PASSWORD и спросить «list all tenants».
Добавить один write-инструмент с тремя уровнями и попросить модель удалить common — она должна отказаться, не предлагая dry run.
Метрика: вызов с confirm=True в первом же сообщении — проходит он мимо dry run или нет.

Схема связи Claude AI с Cisco APIC через MCP-сервер и скриншот консоли APIC — **На картинке:** путь запроса от модели до фабрики и место, где стоят guardrails и валидация; ниже — лог создания объектов и та же иерархия в интерфейсе APIC.

🔗 Read on HackerNoon Репозиторий

04

Устаревшая политика обошла свежую на 0,008 косинуса: эмбеддинги тут ни при чём

✍ Subhash Tatavarthi HackerNoon rag rag-chunking postgresql

О чём

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

🔑 Главное

В топ-5 попали оба куска: устаревший («до 12 недель») с оценкой 0,847 и актуальный («до 18 недель») с 0,839. Разрыв — 0,008, модель взяла тот, что стоял первым.
Базовая линия названа целиком и выглядит как у всех: pypdf, tiktoken с cl100k_base, куски size=512 с overlap=50, text-embedding-3-small, pgvector с LIMIT 5, gpt-4o-mini и системный промпт «отвечай только из контекста».
Оба куска — семантически верные ответы на вопрос. Поэтому лучшее ранжирование их не разделит: разделять нечем, признак различия в индекс не попал.
Дата ревизии лежала в документе трижды (метаданные страницы, история правок, чейнджлог) и умерла в четырёхстрочном extract(), расплющившем документ в одну строку, и в INSERT, сохранившем только content и embedding.
Дыра: это часть 1 из 6, и починка отложена во вторую, ещё не вышедшую. Репозитория нет, корпус внутренний, а запрос, которым получены 0,847 и 0,839, в статье не показан — приведённый SELECT возвращает только текст.

⚡ Попробовать за вечер

Взять свой документ, у которого точно есть две редакции, и задать вопрос, который должен попасть в свежую.
Вывести top-5 вместе с расстоянием — добавить оценку в SELECT, потому что ORDER BY её прячет, — и посмотреть, обгоняет ли устаревший кусок актуальный и несёт ли хоть один из них дату.
Метрика: разрыв порядка 0,008 означает, что чинить надо приём документов, а не ранжирование — смотреть, доезжают ли до строки чанка source, revision_date и superseded_by.

🔗 Read on HackerNoon

05

94,4% против 56,7%: как eval молча выкидывает неответы и переставляет модели местами

✍ Prajwal S. Venkateshmurthy HackerNoon ⏱ ≈11 мин ai-benchmarks llms program-repair

О чём

Автор собрал бенчмарк починки сломанных документов и обнаружил, что главная ошибка живёт не в моделях, а в знаменателе. Урок переносится на любой eval, который делает N запросов и считает точность по полученным ответам: LaTeX здесь просто дешёвый оракул, на котором расхождение видно глазом.

🔑 Главное

10 437 зафиксированных задач (LaTeX 6 568, Typst 3 263, Markdown 606), пересчёт локально на прибитых версиях: Tectonic 0.17.0, Typst 0.15.1, Pandoc 3.10.1, без LLM-судьи.
Из 48 651 попытки 4 352 вернулись пустыми, 2 258 упёрлись в лимит длины, 1 051 не доехала по транспорту, 58 словили лимит запросов. В обычном отчёте этих строк просто нет.
Модель с 94,4% успеха «среди того, на что ответила» даёт 56,7% по всем попыткам, потому что отвечает в 60,1% случаев. Разрыв — 27,5 пункта, и порядок в таблице от этого переворачивается: у Grok-4.3 доставка 100,0%, поэтому обе колонки успеха у него совпадают и равны 84,2%.
Второй оракул расходится с первым: 13,6–18,5% успешно компилирующихся починок заметно меняют содержание документа. «Собралось» и «починено» — разные события.
Дыра: в тексте нет ни одной ссылки — arXiv, Zenodo и DocMut названы словами (репозиторий ниже вытянут из разметки статьи, в прозе его нет). И числа доставки — снимок семи стеков раздачи на один момент, а не свойство моделей: через месяц они не повторятся, в отличие от самого способа считать.

⚡ Попробовать за вечер

Взять сырой лог запросов последнего своего прогона и посчитать три числа вместо одного: доля запросов с пригодным ответом, успех среди них и успех по всем попыткам.
Пересортировать таблицу по третьей колонке, засчитав таймауты, пустые ответы, обрывы по лимиту длины и транспортные ошибки как провалы.
Метрика: если таких попыток у вас ноль, значит вы их не логируете — это и есть находка вечера.

Рисованная схема: ловушка зелёной галочки, расхождение процентов компиляции и сохранности текста — **На картинке:** та же арифметика, что в тексте — 94,4% и 56,7% при доставке 60%, и два оракула, которые расходятся. Подписи на схеме местами набраны с опечатками, числа сверены по тексту статьи.

🔗 Read on HackerNoon Репозиторий DocMut

06

Память агента на RocksDB: четыре семейства колонок и обратный индекс вместо эмбеддингов

✍ mukul_sh HackerNoon ⏱ ≈10 мин ai-agents rocksdb claude-code

О чём

Разбор того, как дать кодовому агенту память между сессиями и выставить её MCP-сервером. Интересна не RocksDB, а три правила кодирования ключей: каждое автор оформил падающим тестом, и они переносятся на любое упорядоченное байтовое хранилище.

🔑 Главное

Четыре семейства колонок в одной базе, общий write-ahead log делает запись сразу в несколько семейств атомарной: episodes — сырые события сессии с TTL 7 дней, facts — выжимка с происхождением и без TTL, index — постинги вида token\x00fact_key, metadata — счётчики. Сроков жизни при этом два: истекают только эпизоды.
Поиск — обратный индекс, а не эмбеддинги: постинги одного токена лежат подряд, поэтому частота документа выпадает из скана бесплатно, а idf = math.log(1 + n_docs / len(postings)) обходится без таблицы статистики.
Свежесть подмешивается затуханием recency = 0.5 ** (age / half_life_ms) и сворачивается как 0.5 + 0.5 * recency, чтобы старый, но релевантный факт не выпадал из выдачи совсем.
Три правила ключей: дополнять таймстемп до TS_WIDTH = 13, хранить MAX - ts для скана свежих вперёд и брать \x00 разделителем — иначе поиск rocks цепляет rocksdb. Автор ловит собственный баг: первый токенизатор считал rocksdb-single-writer одним токеном, и запрос «single writer» не находил ничего.
Дыра: MCP-сервер вынесен в заголовок и при этом описан хуже всего — «три инструмента» перечислены только на схеме автора (memory_recall, memory_remember, memory_recent), в прозе назван один memory_remember, а параметров вызова и регистрации сервера у клиента нет нигде. Ссылка на исходники в тексте спрятана за словом «here», адрес в прозе не написан (репозиторий ниже — из разметки статьи). Автор честно отговаривает: отдельная таблица объясняет, когда правильный ответ — SQLite с FTS5.

⚡ Попробовать за вечер

Перепечатать три кодировщика ключей поверх обычного dict, без единой зависимости, и оформить напечатанные в статье проверки настоящими тестами, включая две отрицательные.
Добавить девятистрочный скоринг с idf и затуханием и прогнать его на своей истории сессий; pip install rocksdict ставить только если после этого захочется настоящего бэкенда.
Метрика: тест «без разделителя rocks цепляет rocksdb» падает до правки и проходит после.

Схема: сессии агента через MCP-сервер с единственным read-write handle в RocksDB и четыре семейства колонок — **На картинке:** почему единственный писатель получается сам собой — MCP-сервер и есть тот самый один процесс. Схема сходится с кодом статьи: те же четыре семейства колонок и TTL только у episodes. Имена трёх инструментов сервера собраны здесь в одном месте, в прозе встречается только memory_remember.

🔗 Read on HackerNoon Репозиторий

AI-статьи недели с HackerNoon

Главные статьи недели

Спред-оператор переписал chatId: одна строка во Flowise отдала чужие диалоги

Почта для агента без права писать: односторонний mbsync вместо галочки «read-only»

MCP-сервер к железу за вечер: dry run по умолчанию и запрет, который нельзя уговорить

Устаревшая политика обошла свежую на 0,008 косинуса: эмбеддинги тут ни при чём

94,4% против 56,7%: как eval молча выкидывает неответы и переставляет модели местами

Память агента на RocksDB: четыре семейства колонок и обратный индекс вместо эмбеддингов

На что обратить внимание

🔁 Идемпотентность нужна раньше чекпоинтов

🔭 Наблюдаемость агента без логирования рассуждений

📈 Opus 5 пишет в 2,3 раза больше кода

🛑 Тормоза для автономного агента

Мой план на эту неделю

Метаданные