9 стартапов в области безопасности приложений, которые борются с рисками ИИ

ИИ стирает границы безопасности между кодом, пайплайном и runtime. Эти стартапы спешат заполнить пробелы.

На протяжении нескольких последних лет безопасность приложений строилась вокруг относительно стабильной модели: разработчики пишут код, пайплайны собирают и тестируют его, а runtime-контроли пытаются поймать то, что просачивается дальше. У каждого этапа были свои инструменты, свои команды и свои представления о том, где именно возникает риск.

Эта модель ломается.

На RSAC 2026 самые интересные стартапы не просто добавляли «AI» к уже существующим категориям. Они реагировали на более фундаментальный сдвиг: ИИ сжимает жизненный цикл разработки ПО, размывая границы между написанием кода, его развертыванием и эксплуатацией. Во многих случаях эти шаги теперь происходят одновременно или управляются одними и теми же AI agents.

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

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

• влево — к требованиям и intent,
• влево — к инструментам, которые генерируют код,
• влево — к пайплайнам, которые собирают и отправляют код, и
• вниз — к runtime-средам, где код выполняется.

Ниже — стартапы, которые показывают, как смещаются эти контрольные точки и почему старые предположения о том, где именно нужно закреплять trust, больше не работают.

AppSentinels: защита workflows, а не только endpoints

Компания с корнями в API security (см. наш обзор RSAC 2025), AppSentinels расширила охват, чтобы закрывать потребности безопасности в AI-driven системах. По мере того как AI agents и сервисы все чаще взаимодействуют через API, риск больше не ограничивается отдельными endpoints. Он заключается в том, как эти endpoints связываются между собой.

Фокус компании — понимать и защищать то, как API используются в комбинации, а не по отдельности. «Это не один endpoint… это то, как workflows сшиваются вместе», — сказал Puneet Tutliani, сооснователь и CEO AppSentinels. Именно в этой «сшивке» и возникают проблемы.

Agents могут автоматизировать сложные последовательности действий через API, часто со скоростью машины. Делая это, они способны выявлять логические уязвимости, обходить controls или создавать непреднамеренные побочные эффекты, которые было бы трудно вызвать вручную. Традиционные инструменты API security, ориентированные на отдельные запросы или endpoints, плохо подходят для обнаружения такого поведения.

AppSentinels решает эту задачу, сочетая continuous testing с runtime governance, пытаясь моделировать и отслеживать workflows по мере их выполнения. Недавнее дополнение к продуктовой линейке — явная поддержка agent-driven взаимодействий, включая видимость того, какие agents работают и как они используют API и tools.

Это естественное развитие более раннего позиционирования компании. AppSentinels по-прежнему сосредоточена на защите business logic, но теперь в эту логику входят AI agents как полноценные участники.

Проблема — в сложности. Моделировать workflows через множество API, сервисов и agents по своей природе трудно, и многие организации все еще не могут даже инвентаризировать свои endpoints, не говоря уже о понимании того, как они взаимодействуют. Но по мере того как приложения становятся более composable и agent-driven, такая видимость становится все более срочной.

Aurva: отслеживание identity и access в мире, управляемом agents

Если AppSentinels сосредоточена на швах в workflows, то Aurva фокусируется на том, кто или что фактически выполняет работу.

В нашем обзоре за 2025 год Aurva делала упор на runtime data visibility и на то, как информация проходит через приложения. В этом году акцент сместился в сторону identity и access, особенно в контексте AI agents.

Суть проблемы в том, что agents часто требуют широких прав, чтобы функционировать. Они обращаются к API, запрашивают data stores и взаимодействуют с множеством систем от имени пользователей. В результате возникают сложные цепочки identity и authorization, которые трудно отслеживать и еще труднее ограничивать.

Подход Aurva — отслеживать эти цепочки в реальном времени, сопоставляя активность на уровне kernel с данными об identity и access, чтобы понимать, что делают agents, к каким данным они обращаются, какие permissions используют и как именно ими распоряжаются. Проблема заключается не только в visibility, но и в понимании поведения agents, сказал CEO Aurva Apuru Garg.

Это различие важно. Традиционные системы identity and access management определяют, что должно быть разрешено. Aurva пытается показать, что происходит на самом деле, и где permissions могут быть шире, чем нужно.

На данный момент платформа в основном сосредоточена на detection и analysis, а не на enforcement. Это ограничивает ее способность выступать прямой контрольной точкой, но она все же закрывает пробел. По мере того как agents становятся более автономными, возможность отслеживать их действия между системами становится обязательным условием для meaningful access control.

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

Backline: замыкая цикл между выявлением и исправлением

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

Годами безопасность приложений отлично генерировала findings. Но она гораздо хуже справлялась с тем, чтобы эти findings действительно устранялись. Предположение Backline состоит в том, что этот разрыв только растет. По мере того как ИИ ускоряет разработку, объем уязвимостей увеличивается, а способность устранять их масштабируется медленнее.

Ответ компании — автоматизировать сам процесс remediation.

Backline интегрируется с репозиториями и системами CI/CD, чтобы выявлять exploitable vulnerabilities, генерировать исправления и проверять эти исправления через существующие workflows сборки и тестирования. Цель — не просто приоритизация, а сквозное закрытие проблемы. Как сказал сооснователь Backline и VP of R&D Aviad Chen, «Вопрос уже не в том, какая уязвимость важна, а в том, как исправлять их в масштабе».

Если ранние инструменты были сосредоточены на triage, то Backline пытается сжать весь цикл от обнаружения до устранения в единый автоматизированный процесс. В теории это позволяет командам поспевать за возросшим выпуском AI-driven разработки.

Риск, разумеется, в том, что появятся новые ошибки. Автоматически сгенерированные исправления должны быть корректными, учитывать контекст и быть безопасными для развертывания. Backline пытается закрыть все эти требования, проверяя изменения внутри пайплайна до того, как они попадут в production, но организациям потребуется время и подтверждения, чтобы поверить в такой подход.

Тем не менее направление очевидно. В среде, где уязвимости могут обгонять человеческое remediation, автоматизация превращается из удобства в необходимость.

Backslash: защита AI development toolchain

В традиционных software development pipelines путь от идеи до кода был относительно контролируемым. Сегодня этот путь часто проходит через растущий набор AI tools: coding assistants, agents, plugins, серверы Model Context Protocol (MCP) и внешние сервисы, многие из которых работают вне формального надзора.

Backslash сосредоточена именно на этом промежуточном слое — AI development toolchain.

Компания дает видимость того, какие AI tools и agents используются внутри организации, а также предоставляет policy controls и guardrails, регулирующие их взаимодействие. Что еще важнее, она пытается контролировать, как данные перемещаются между этими компонентами, закрывая риски вроде prompt injection и непреднамеренного раскрытия данных.

Ключевая идея в том, что attack surface больше не ограничивается кодовой базой. Это вся цепочка tools, которые преобразуют intent в результат. Как объяснил Field CTO Backslash Gil Friedman, security teams уже имеют дело не с одним разработчиком, который пишет код, а с tools, стоящими между инициативой и результатом.

У этого сдвига два последствия. Во-первых, security teams часто не имеют даже базовой видимости того, какие AI tools используются, особенно когда их начинают применять неразработчики. Во-вторых, традиционные controls вроде network monitoring или endpoint detection плохо улавливают взаимодействия между agents, plugins и локальными процессами.

Ответ Backslash — endpoint-level «guardian», который инвентаризирует эти компоненты, оценивает их риск и применяет policies к тому, что можно устанавливать или запускать.

Проблема, как и во многих новых категориях, в ясности. Терминология — agents, MCPs, skills и т. д. — продолжает меняться, и границы между категориями тоже еще формируются. Но проблема срочная: теперь, когда AI tools стали частью development pipeline, их нужно защищать именно как его часть.

Chainloop: встраивание governance в software factory

Chainloop решает другую точку отказа, которую усилила AI-powered разработка: что происходит, когда ИИ ускоряет все остальное.

По мере ускорения разработки governance становится узким местом. Chainloop выступает как control plane для software supply chain, собирая artifacts по всему пайплайну — изменения кода, результаты сборки, данные сканирования и deployments — чтобы создать центральную, проверяемую систему учета. Платформа также применяет guardrails в формате policy-as-code, автоматически enforcing требования во всем пайплайне.

Компания не пытается стать еще одним scanning tool. Она стремится стать системой, которая определяет и обеспечивает, как software проходит путь от commit до production.

Мотивация проста: ИИ резко ускоряет «inner loop» разработки, но «outer loop» — security, compliance и governance — не поспевает. Как описал это сооснователь и CEO Chainloop Daniel Liszka, организации теперь могут генерировать и отправлять код быстрее, чем когда-либо, но интеграция, compliance и security по-прежнему медленные. Ответ Chainloop — автоматизировать этот outer loop.

Определяя guardrails как code и связывая их напрямую с событиями пайплайна, платформа обеспечивает feedback loops в реальном времени, в том числе и для самих AI agents. На практике это означает, что agents могут итеративно дорабатывать код или конфигурации, пока не будут соблюдены заданные policies, вместо того чтобы полагаться на ручной review.

Это один из самых значимых сдвигов, показанных на RSAC в этом году. Governance, которое долго воспринималось как friction, переосмысливается как infrastructure — то, что необходимо автоматизировать, если AI-driven разработка должна масштабироваться.

Компромисс — сложность. Модель Chainloop требует от организаций мыслить категориями systems, provenance и policy frameworks, а не только tools. Но для команд, которые уже сталкиваются с рисками software supply chain, такой уровень абстракции может оказаться именно тем, что нужно.

FireTail: видимость использования ИИ по всей организации

Описываемая как end-to-end AI security platform, FireTail делает шаг назад, чтобы ответить на более широкий вопрос: кто использует ИИ и как.

Это кажется базовой задачей, но она до сих пор не решена. По мере распространения AI tools их использование выходит за пределы команд разработки и охватывает product managers, analysts и другие бизнес-функции. Во многих случаях у организаций нет четкой инвентаризации того, какие tools используются, какими данными делятся и где могут появляться риски.

FireTail сосредоточена на обеспечении такой видимости.

Платформа отслеживает и использование со стороны сотрудников, например взаимодействие с tools вроде ChatGPT, и использование на уровне приложений, например agents, построенных на cloud AI services. Она агрегирует эту активность в единые потоки журналов, где может выявлять потенциальные проблемы вроде утечки данных, нарушений policies или аномального поведения.

«Первый сценарий использования для каждого клиента — понять, кто каким AI service пользуется», — сказал основатель FireTail Jeremy Snyder. После этого организации могут задавать policies и, в некоторых случаях, enforcing их, особенно на уровне endpoint или browser.

Это другой тип контрольной точки. Она меньше связана с enforcing поведения внутри pipeline и больше — с созданием базовой видимости и governance по всей организации. Это делает FireTail одновременно полезной почти для всех и в некоторой степени периферийной по отношению к core development life cycle. Visibility — необходимое условие контроля, но enforcement требует дополнительных мер.

Тем не менее, по мере того как внедрение ИИ выходит за пределы engineering, такая visibility может стать необходимым первым шагом, особенно для организаций, которые хотят понять свою exposure до того, как решат, как ею управлять.

Raven: trust там, где код выполняется

На дальнем конце software life cycle Raven представляет другой тип сдвига. Вместо того чтобы фокусироваться на коде до его запуска, Raven фокусируется на том, что происходит во время выполнения.

В прошлом году мы описывали Raven как runtime platform, ориентированную на prioritization и detection. В этом году акцент изменился. Компания теперь двигается в сторону runtime prevention, занимая более жесткую позицию в отношении того, что важно, а что нет.

Основная идея проста. Static analysis генерирует большие объемы уязвимостей, многие из которых никогда не проявляются в production. Одновременно ИИ сокращает время, необходимое для обнаружения и эксплуатации реальных слабых мест. В результате традиционная модель поиска известных проблем и их приоритизации на основе CVE теряет актуальность.

Ответ Raven — сосредоточиться на поведении во время выполнения, а не на сигнатурах или известных уязвимостях. Наблюдая за тем, как код выполняется внутри приложения, платформа пытается напрямую выявлять и останавливать exploit activity, независимо от того, была ли уязвимость уже каталогизирована. Как сказал сооснователь и CEO Raven Roi Abitboul, «Мы перестаем полагаться на CVE и смотрим на то, что приложение делает на самом деле».

Это сильное утверждение, но оно отражает более широкий тренд.

Компания использует подход на уровне kernel, чтобы наблюдать за поведением приложений без внедрения кода и без изменения runtime environment, стремясь минимизировать влияние на производительность. С этой точки обзора она может выявлять аномальное поведение в библиотеках или функциях и блокировать выполнение в реальном времени.

Именно здесь Raven расходится с большей частью текущего нарратива вокруг ИИ. Пока многие вендоры делают ставку на AI-driven detection, Raven утверждает, что ИИ слишком медленный для real-time prevention, и использует его выборочно — для анализа и приоритизации. В результате получается модель, в которой runtime считается окончательной контрольной точкой. Если ранние этапы провалились или были обойдены, enforcement все равно происходит там, где код выполняется.

Сама по себе эта позиция не нова, но контекст изменился. По мере того как ИИ ускоряет и разработку, и генерацию exploit-ов, разрыв между обнаружением уязвимости и ее эксплуатацией продолжает сокращаться. В такой среде enforcement на runtime становится уже не запасным вариантом, а основной защитой.

Seezo: защита того, что будет построено, еще до появления кода

Один из самых радикальных сдвигов в информационной безопасности происходит в самом начале development life cycle.

В прошлые годы вендоры application security сосредотачивались на сканировании кода после его написания. Seezo делает ставку на то, что в мире, управляемом ИИ, это уже слишком поздно. Компания фокусируется на создании security requirements до того, как написан код, формируя то, как и разработчики, и AI agents строят системы с самого начала. Идея проста: если ИИ генерирует большие объемы кода, то контролировать то, что будет построено, важнее, чем анализировать уже построенное задним числом.

Как сказал сооснователь и CEO Seezo Sandesh Mysore Anand, «Стоимость генерации кода упала до нуля, а стоимость его проверки по-прежнему очень высока».

Этот дисбаланс вызывает тихое, но важное изменение. Вместо того чтобы прерывать работу разработчиков сканами и findings, Seezo встраивает security в слой требований — в то место, на которое опираются и люди, и AI-системы, когда пытаются понять intent.

Это не просто история о shift-left. Это признание того, что когда AI agents пишут код, они одновременно читают инструкции. Если в этих инструкциях есть security constraints, итоговый код улучшается еще до того, как попадет в пайплайн.

Компромисс очевиден. Такой подход требует от организаций более дисциплинированного процесса работы с требованиями, чего многие команды исторически избегали. Но по мере роста output ИИ эта дисциплина может стать уже не опциональной.

TestifySec: превращение compliance в непрерывный control

Обещая превратить development pipeline в «live audit feed», TestifySec решает упорную проблему: compliance как gatekeeping-функцию.

В традиционных средах доказательство того, что software соответствует regulatory или security requirements, происходит медленно, вручную и часто оторвано от того, как код реально создается. Эта задержка становится серьезной проблемой, когда разработка ускоряется, особенно если AI agents генерируют изменения быстрее, чем команды успевают их проверять.

Чтобы ответить на этот вызов, TestifySec переносит compliance внутрь самого пайплайна, используя evidence-based model. Вместо reliance на документацию и ручные аудиты платформа сопоставляет код, результаты тестов и artifacts напрямую с security controls и оценивает их непрерывно.

«Теперь организации могут писать software быстро, но мы не можем ship-ить его быстрее, потому что не можем его измерить», — сказал сооснователь и CEO TestifySec Cole Kennedy. Именно этот разрыв в измерении компания и пытается закрыть.

Платформа использует AI agents, чтобы анализировать, какие доказательства должны существовать для конкретного control, а затем ищет эти доказательства в codebase, output-ах пайплайна и сопутствующих artifacts. На практике это означает, что разработчики могут получать feedback по compliance еще до merge кода, а не ждать downstream audit cycle.

Это тонкий, но важный сдвиг. Compliance переходит из статуса постфактум-проверки в непрерывный сигнал внутри CI/CD.

Проблема — в trust. Автоматизированный compliance обещали и раньше, а организации по понятным причинам осторожно относятся к замене человеческой проверки машинными оценками. Но по мере роста скорости разработки альтернатива может оказаться хуже: растущая очередь software, которую нельзя ship-нуть, потому что ее нельзя сертифицировать.

Движение сразу во всех направлениях

Если и был один главный вывод RSAC 2026, то он в том, что отрасль больше не спорит о том, изменит ли ИИ разработку ПО. Он уже это сделал.

Открытым остается вопрос: где должна находиться security, когда границы между разработкой, развертыванием и выполнением больше не работают. Описанные здесь вендоры не сходятся к одному ответу. Вместо этого они переопределяют контрольные точки по всему жизненному циклу — от requirements и toolchains до pipeline, runtime и workflows.

Какие-то из этих подходов окажутся более устойчивыми, чем другие. Не каждый новый слой станет отдельной категорией, и не каждое утверждение выдержит проверку реальностью. Но направление понятно. По мере того как ИИ сжимает software development life cycle и ускоряет как разработку, так и exploitation, безопасность больше не может полагаться на изолированные checkpoints.

Trust нужно обеспечивать непрерывно и в большем числе точек, чем раньше.

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

Материал — перевод статьи с английского.

Оригинал: 9 application security startups combating AI risks