Dapr 1.18 получил, пожалуй, самое практичное обновление для эпохи AI-агентов: в релиз добавили Verifiable Execution, набор механизмов для криптографической проверки того, кто, как и в какой последовательности исполнял workflow. Для команд, которые уже пускают агентов в финансы, поддержку клиентов или внутренние процессы, это не красивая надстройка, а попытка закрыть неприятный вопрос: можно ли вообще доверять журналу исполнения после того, как агент что-то одобрил, вызвал другой сервис или полез в чувствительные данные.
О релизе 26 июня 2026 года сообщает InfoQ. По данным издания, Diagrid выпустила Dapr 1.18 как open source-обновление и одновременно выкатила эти возможности в своей управляемой платформе Catalyst Cloud. Ключевая идея релиза проста: если у распределённой системы и AI-агента есть право принимать важные решения, бизнесу нужен не только результат, но и проверяемая история того, как этот результат появился.
В центре обновления три функции. Первая — Workflow History Signing: история выполнения workflow подписывается криптографически с использованием идентичностей на базе открытого стандарта SPIFFE. Иначе говоря, журнал исполнения становится не просто логом, а записью с защитой от тихой подмены задним числом. Вторая — Workflow History Propagation: происхождение запроса и цепочка предыдущих действий передаются дальше между сервисами, workflow и приложениями. Это уже про трассировку не только техническую, но и доверительную: downstream-система видит не просто вызов, а контекст его происхождения. Третья — Workflow Attestation, которая даёт workflow и отдельным активностям доверенный контекст исполнения, чтобы политики безопасности и compliance-проверки могли принимать решения, опираясь не на «верим на слово», а на подтверждённую provenance-информацию.
Почему это вообще стало темой для отдельного релиза? Потому что классические workflow-движки давно научились выживать. Они переживают падения инфраструктуры, восстанавливаются после сбоев, автоматически повторяют неудачные операции и в целом хорошо справляются с отказоустойчивостью. Но AI-агенты резко подняли планку требований. Когда агент одобряет финансовую операцию, запрашивает чувствительные данные, вызывает другой агент или крутит долгий процесс через несколько сервисов, вопросов становится больше, чем ответов: кто именно инициировал действие, не меняли ли потом историю исполнения, можно ли доверять итоговому результату и сможет ли аудит вообще восстановить цепочку событий независимо от вендора. До сих пор на этом месте у многих платформ начинался довольно грустный разговор про логи, SIEM и надежду, что всё как-нибудь сойдётся.
По сути, Dapr 1.18 переносит идеи security supply chain из мира сборки ПО в рантайм. За последние годы индустрия успела привыкнуть к подписыванию артефактов, SBOM и attestations для цепочки поставки софта. Организации хотят знать, откуда взялся бинарник, чем он собран и не трогал ли его кто-то по дороге. Теперь тот же запрос переезжает в исполнение приложений и AI-сценариев: мало знать, что контейнер был «чистым», нужно ещё понимать, что происходило после запуска. Diagrid прямо ставит на то, что следующая фаза cloud-native будет строиться уже не только вокруг durable execution, но и вокруг verifiable execution. Звучит громко, но для regulated-сред это вполне земная логика: объяснимость и проверяемость начинают стоить не меньше, чем доступность сервиса.
Особенно это заметно в отраслях, где любой шаг алгоритма потом может оказаться на столе у аудитора или службы внутреннего контроля. В здравоохранении и финансовом секторе важно не только само решение AI-системы, но и доказательство, как оно было принято. Если агент получил доступ к данным клиента, передал задачу другому агенту и инициировал действие в бэк-офисе, одной записи «успешно выполнено» уже недостаточно. Нужна цепочка custody, которую можно независимо проверить. Именно на этот сценарий и нацелены новые функции Dapr: не заменить все механизмы наблюдаемости, а добавить слой криптографического доверия поверх того, что раньше считалось просто технической телеметрией.
При этом релиз не сводится к одной модной теме про агентов. Jobs API, отвечающий за планирование отложенных и регулярных задач, переведён в стабильный статус после производительных тестов и теперь считается готовым для production. Hot Reloading для компонентов и конфигурации стало общедоступной функцией: обновлять настройки можно без перезапуска приложений и без остановки рабочих нагрузок. Для actor runtime добавили более аккуратную сетевую модель: приложение может держать один двунаправленный gRPC-поток для обратных вызовов от Dapr sidecar, вместо того чтобы открывать входящие серверные порты. Для платформенных команд это означает меньше сетевой обвязки и меньшую поверхность атаки. На инфраструктурном уровне в релиз вошли поддержка IPv6 и dual-stack, а также корректная по RFC 7230 обработка hop-by-hop HTTP-заголовков при service invocation.
Отдельно важен контекст рынка. В материале InfoQ упомянуты Microsoft, Agentic AI Foundation и CNCF — все они в последние годы всё чаще говорят не только о производительности AI-систем, но и об управляемости, идентичности, provenance и совместимости. Это хороший индикатор того, куда движется отрасль: внимание смещается от демо-эффекта «агент что-то умеет» к куда менее зрелищному, но гораздо более дорогому вопросу «можно ли это безопасно пустить в production». На этом фоне Dapr 1.18 выглядит не как точечный релиз фреймворка, а как попытка занять место в будущем стеке доверенной оркестрации распределённых приложений и AI-агентов.
Для русскоязычных разработчиков, архитекторов и IT-руководителей здесь сигнал довольно прямой. Если в компании уже обсуждают agentic AI, автоматизацию длинных процессов или передачу критичных действий в полуавтономные workflow, одной отказоустойчивости больше не хватит. Следующий раунд требований придёт со стороны аудита, безопасности и бизнеса: докажите происхождение действия, покажите целостность истории, объясните, почему downstream-сервис вообще должен доверять этому результату. И если такие механизмы начинают появляться в инфраструктурных платформах уже на уровне open source, значит, спор скоро будет не о том, нужен ли криптографический след исполнения, а о том, кто внедрит его раньше и без очередной горы кастомной обвязки.