Як Rippling «вкрала» ідею MCP-агента Runlayer: урок із захисту AI-інновацій

Коли рік довіри стає зброєю

Інсайдер із Rippling надіслав CEO Runlayer Ендрю Берману одне коротке повідомлення: у компанії існував проєкт зі створення «фактично клону» — «майже копія один в один» — MCP-шлюзу Runlayer. Стартап, за яким стоять Khosla Ventures і Felicis із загальним фінансуванням $42 млн, майже рік передавав потенційному клієнту вихідний код, дорожню карту продукту й архітектуру шлюзу. 28 липня 2026 року Runlayer подала позов, який став першим судовим розглядом щодо інтелектуальної власності в екосистемі Model Context Protocol, — Runlayer v. Rippling у Південному окрузі Нью-Йорка.

Але це не просто корпоративна драма в залі суду. Це детальна схема того, як цінні AI-інновації розкриваються, відтворюються й оскаржуються, — і пряме попередження для будь-якого бізнесу, що будує, купує або залежить від AI-агентів. Нижче розберемо, що зробило Runlayer вразливою, і покажемо конкретні кроки, які ви можете зробити інакше.

Що насправді сталося

Щоб зрозуміти, чому ця справа важлива далеко за межами двох технологічних компаній, потрібно розібратися з технічною суттю конфлікту.

У центрі суперечки — MCP-шлюз: централізований рівень управління між AI-агентами й MCP-серверами, який вирішує критичні корпоративні завдання — автентифікацію, контроль доступу, спостережуваність і застосування політик безпеки. Сам Model Context Protocol є відкритим стандартом: Anthropic випустила його у листопаді 2024 року як основу для безпечного підключення AI-моделей і агентів до зовнішніх даних та інструментів. Протокол безкоштовний. Те, що продають компанії на кшталт Runlayer, — це захищена обгортка навколо нього: контроль доступу, журнали аудиту, логіка управління агентами.

Продукт Runlayer саме такою обгорткою і був. І саме її, згідно з позовом, нібито скопіювала Rippling.

Як випробування перетворилося на передачу технологій

Хронологія подій майже хрестоматійна. Rippling — компанія з управління персоналом і кадровими процесами, оцінена в $16,8 млрд, — звернулася до Runlayer як потенційний клієнт. Сторони підписали взаємну угоду про нерозголошення й угоду про випробування продукту, яка прямо забороняла Rippling копіювати інтелектуальну власність Runlayer або створювати похідні твори.

Приблизно 12 місяців Runlayer надавала Rippling широкий доступ до своїх технологій: вихідний код, плани розвитку продукту. Оцінка була ретельною, практичною й технічно глибокою — такою, якої потребують корпоративні угоди, щоб рухатися вперед. Потім переговори про ціну довгострокового комерційного контракту зайшли в глухий кут. 12 червня 2026 року Runlayer призупинила послуги. Того самого дня надійшло повідомлення від інсайдера.

Rippling підтвердила запуск власного MCP-шлюзу. Представник компанії категорично відкинув звинувачення, назвавши позов «панічною спробою Runlayer уникнути конкуренції шляхом фабрикації». Компанія стверджує, що будує продукт виключно на власній інформації. Справа зараз розглядається судом: Runlayer добивається тимчасової заборони й грошової компенсації; інтереси стартапу представляє Sullivan & Cromwell LLP.

Кожне архітектурне обговорення, яке ви проводите з потенційним клієнтом, кожен крайній випадок, який вирішуєте на спільному дзвінку, — ви не просто продаєте. Ви навчаєте. А те, чому ви навчили, компанія з сотнями інженерів може перетворити на продукт.

Чому це перша справа, але не остання

Момент не випадковий. MCP-шлюзи стрімко стають ключовою корпоративною інфраструктурою. До середини 2026 року конкуренція в цьому сегменті вже загострювалась: Freshworks анонсувала Freddy AI Agent Studio та MCP Gateway у травні 2026 року, а AWS запустила Bedrock AgentCore Gateway як керований інфраструктурний рівень для підключення агентів через MCP-сумісні інтерфейси.

Коли технологічна категорія переходить від експериментальної до критично важливої, економіка вибору «будувати чи купувати» змінюється. Така компанія, як Rippling, має сотні інженерів. Коли вендор виставляє значну річну суму за продукт, який ці інженери впевнені, що відтворять за кілька кварталів, хтось у кімнаті неминуче береться за калькулятор. Спокуса стає особливо сильною, коли річний продуктовий пілот уже відповів на більшість складних архітектурних питань.

Саме це робить справу Runlayer структурно іншою від типових суперечок про комерційну таємницю. Нібито крадіжка відбулася не через злом даних і не через корпоративне шпигунство в класичному розумінні. Вона нібито відбулася через легітимний бізнес-процес — оцінку продукту, — який проводився на підставі підписаних угод і за повного технічного сприяння з боку вендора.

Для будь-якого бізнесу, що працює на перетині AI-розробки й корпоративних продажів, це незручна правда: найнебезпечніший момент для вашої AI-інновації — це сама демонстрація.

І це не єдина IP-суперечка навколо Rippling. У 2025 році сама компанія подала позов проти конкурента Deel, звинувативши його в корпоративному шпигунстві в іншій справі. Та справа нічого не доводить у контексті звинувачень Runlayer, але добре ілюструє, наскільки агресивно ринок корпоративного програмного забезпечення епохи AI судиться з приводу конкурентних дій — і чому надійний захист інтелектуальної власності в AI-стратегії давно перестав бути опцією.

Що насправді означає «захист AI-інновації»

Більшість керівників вважають, що захист інтелектуальної власності — це патентування. У світі AI-агентів цей рефлекс неповний і нерідко запізнілий. Ось що справа Runlayer говорить про реальний стек захисту.

Юридичні інструменти — необхідна умова, але не достатня

Runlayer зробила все правильно на папері. NDA підписана. Угода про пілот підписана — з прямою забороною копіювання. Це, як зауважив TechCrunch, «стандартний шаблон для пілотів у корпоративному ПЗ». Та Runlayer все одно опинилася у федеральному суді.

Урок не в тому, що NDA марні — вони обов'язкові, і юридична позиція Runlayer саме на них і тримається. Урок у тому, що юридичні інструменти створюють відповідальність, а не перепону. NDA не зупиняє добре забезпечену компанію від стратегічного рішення — вона створює наслідки після нього.

За законом про комерційну таємницю захист залежить від дотримання розумних заходів безпеки — не лише договірних, а й операційних та технічних. Суди оцінюють: що саме є «таємним», чому ця інформація має самостійну економічну цінність завдяки своїй закритості, і як відповідач її незаконно отримав або використав. Якщо ви не можете довести, що ставилися до інформації як до справді конфіденційної — не тільки на папері, — ваша позиція слабшає.

Технічний рівень захисту

Між «ми підписали NDA» і «ми продумали, що саме розкриваємо» є конкретна операційна різниця. Для AI-інфраструктурних компаній, що проводять корпоративні пілоти, вона виглядає так:

• Поетапне розкриття: спочатку функціональні можливості, архітектурні деталі — лише після підтвердження комерційних намірів. Потенційний клієнт не потребує вашого вихідного коду, щоб зрозуміти, чи вирішує ваш продукт його завдання.
• Пісочниця для пілотів: замість розгортання виробничого стека — побудуйте тестове середовище, яке демонструє результат, не розкриваючи реалізацію. Це як шоурум замість заводського цеху.
• Технічне маркування: вбудовуйте в код, документацію чи вихідні дані відстежувані маркери, які дозволять довести походження у суперечці. Ця технологія існує, і серйозні AI-інфраструктурні компанії вже починають її використовувати.
• API з обмеженим доступом: замість того щоб відкривати повну логіку шлюзу, пропонуйте обмежений API, який проксіює функціональність, не розкриваючи архітектуру площини управління.

Головне архітектурне розуміння: можна показати, що продукт працює, не пояснюючи точно, як він працює. Ця відмінність — не лише захист IP, а й краща інженерія продажів.

Організаційний рівень

Окрім юридичних і технічних засобів, є людський рівень, який компанії систематично недооцінюють. Позов Runlayer став можливим завдяки інсайдеру Rippling, який добровільно попередив стартап. Це означає, що хтось усередині Rippling відчув достатній дискомфорт від того, що відбувалося, щоб порушити мовчання. Це організаційний сигнал, а не лише юридичний.

Для компаній, які є покупцями AI-інновацій — оцінюють вендорів, проводять пілоти, будують внутрішні інструменти, — ця справа є і питанням корпоративного управління. Чи є у вас чіткі внутрішні правила про те, що інженери можуть і не можуть використовувати з вендорських пілотів? Чи вони виконуються, а не просто написані? Де проходить межа між «вчитися у вендора» і «будувати за тим, що вендор показав»? По мірі того як AI-агенти вбудовуються в закупівлі, комплаєнс і робочі процеси затвердження, ці питання набувають прямих операційних наслідків. Детальніше про те, як загрози для AI-агентних бізнесів розвиваються у 2026 році, і які управлінські рамки з'являються у відповідь.

Проблема зрілості екосистеми MCP

Справа Runlayer v. Rippling — це, як зауважив один із аналізів, сигнал того, що MCP «вийшов за межі свого початкового статусу колаборативного протокольного експерименту й став оскаржуваною комерційною категорією». Цей перехід має конкретні наслідки для того, як бізнес має думати про AI-агентну інфраструктуру.

Протоколи з відкритим кодом дають спільне підґрунтя — всі будують на одному фундаменті. Але цінність завжди є на рівні вище від протоколу: корпоративне захищення, контроль доступу, логіка інтеграції, яка робить агентів достатньо надійними, щоб вони могли торкатися даних про зарплати чи комплаєнс-записів. Цей рівень — власницький. І саме його хочуть конкуренти.

Коли технологія переходить від експериментальної до фундаментальної, починаються IP-битви. Екосистема MCP щойно отримала перший позов. І точно не останній.

Для бізнесу, що будує власні AI-агентні робочі процеси на базі MCP — чи то купуючи шлюз у вендора, чи розробляючи власний, — справа Runlayer є прояснювальною подією. Вона показує, що ця інфраструктура достатньо цінна, щоб за неї битися, і достатньо складна, щоб різниця між «натхнено» і «скопійовано» розглядалася у федеральному суді.

Якщо ваша компанія розгортає AI-агентів, які взаємодіють з HR, фінансовими чи операційними даними, ви вже працюєте саме в цьому спірному просторі. Розуміння того, як AI-агенти застосовуються в операціях компаній сьогодні, допомагає зрозуміти, чому базова інфраструктура — шлюз, який контролює, до чого агенти мають доступ, — стала новим полем конкурентної боротьби.

Практичний фреймворк для тих, хто будує AI-інновації

На основі фактів справи Runlayer і ширшої закономірності в судових суперечках про AI-таємниці — ось робочий фреймворк для будь-якої компанії, що будує власні AI-агентні системи.

Документуйте рано й постійно

Найпоширений провал у суперечках про AI-IP — не відсутність захисту в момент порушення, а відсутність доказів того, що існувало до нього. Зберігайте записи з позначками часу про архітектурні рішення, журнали розробки, проєктну документацію. Системи контролю версій на кшталт Git дають природні журнали аудиту, але їх потрібно доповнювати явною документацією того, що є вашим власницьким внеском, а що побудовано на компонентах із відкритим кодом.

Ця документація служить двом цілям: зміцнює вашу позицію в суді й змушує вашу команду точно розуміти, де насправді живе конкурентна перевага. Багато команд, коли їх просять сформулювати свою «секретну формулу», виявляють, що вона конкретніша — і краще захищається — ніж вони думали.

Будуйте комерційні відносини з явним урахуванням IP

Стандартні NDA, як показує справа Runlayer, — необхідна умова, але не достатня. Угоди про пілот мають іти далі: прямо вказувати, які матеріали передаються, для яких цілей їх можна використовувати, які технічні засоби контролю запроваджено. Передбачте право аудиту. Визначте, що відбувається з переданими матеріалами, якщо комерційна угода не закрилася.

І зважайте на асиметрію відносин. Коли велика корпорація зі значними інженерними ресурсами входить у пілот зі стартапом, баланс сил спочатку нерівний. Ця асиметрія має відображатися в договірних захисних механізмах — не тому, що кожна корпорація діє недобросовісно, а тому, що наслідки суперечки є екзистенційними для стартапу і керованими для компанії вартістю $16,8 млрд.

Включіть «аудит рову» у свою продуктову дорожню карту

Щокварталу хтось у вашій команді має ставити питання: якби конкурент побачив усе, що ми показали на минулому місяці на демо, — що він зміг би побудувати? Це незручне питання. Але воно прояснює. Воно змушує розрізняти функції, що демонструють цінність, і архітектуру, що створює справжню конкурентну перевагу.

Мета — не параноя, а точність. Ви маєте знати, що захищаєте, перш ніж починати захищатися. І це знання потрібно ще до того, як ви сідаєте за стіл переговорів із компанією, що вирішила провести власний підрахунок «будувати чи купувати».

Якщо ви — покупець, а не продавець

Більшість читачів цієї статті не будують MCP-шлюзи. Вони керують компаніями, яким потрібна AI-агентна інфраструктура, — або розглядають, чи будувати її самостійно. Справа Runlayer говорить і до вас.

Якщо ви оцінюєте вендорів AI-агентів, розумійте: те, що ви дізнаєтеся під час пілоту, має обмеження — не лише етичні, а й юридичні. NDA і угода про пілот, які ви підписуєте, — не формальність. Вони створюють реальні зобов'язання для ваших інженерів і продуктових команд щодо того, що можна використовувати з побаченого. Управлінські правила, які прямо це регулюють — і виконуються на рівні інженерних менеджерів, а не просто підписані юридичним відділом, — стають дедалі необхіднішим інструментом управління ризиками.

Якщо ви будуєте AI-агентну інфраструктуру всередині компанії, справа висвічує інший ризик: ризик ненавмисно створити похідний продукт. Якщо ваша команда глибоко вивчала зовнішніх вендорів, задокументуйте незалежність свого внутрішнього шляху розробки. Суди, що розглядають позови про комерційну таємницю, запитують, чи була розробка незалежною, — і здатність це довести залежить від записів, які існували до суперечки, а не після.

Є й тихіший ризик, який накопичується з часом: без чіткого фреймворку захисту IP керівники постійно реагують на ситуації, замість того щоб формувати стратегію. Лідери, які отримують довіру ради директорів та інвесторів, — це ті, хто ставиться до AI-управління як до проактивної дисципліни, а не юридичного хвоста. Коли ваша AI-стратегія системна — задокументована, керована й обґрунтована — це читається як лідерство, а не везіння.

FAQ

Що таке MCP-шлюз і чому він цінний? MCP-шлюз — це рівень управління між AI-агентами й корпоративними системами даних, який відповідає за автентифікацію, контроль доступу й застосування політик безпеки. Його цінність — у захищеній обгортці навколо відкритого MCP-протоколу: корпоративній логіці безпеки та відповідності, яка дозволяє AI-агентам безпечно взаємодіяти з чутливими бізнес-даними.

Що конкретно Runlayer стверджує проти Rippling? Runlayer стверджує, що після майже річного пілоту — під час якого компанія передала вихідний код, дорожню карту й архітектуру шлюзу в рамках взаємної NDA й угоди про пілот із прямою забороною копіювання — Rippling використала цю інформацію для побудови конкуруючого MCP-шлюзу, що є «майже копією один в один» продукту Runlayer. Позов містить звинувачення в розкритті комерційної таємниці, недобросовісній конкуренції та порушенні договору.

Як відреагувала Rippling? Rippling підтвердила запуск власного MCP-шлюзу, але категорично заперечує звинувачення. Компанія заявила, що будує продукт виключно на власній інформації, і назвала позов «панічною спробою уникнути конкуренції».

Чи насправді NDA вас захищає? NDA створює юридичну відповідальність за порушення — але не перешкоджає неправомірному використанню інформації. Щоб реально захистити AI-інновації, NDA потрібно поєднувати з поетапним розкриттям, пісочницями для пілотів і чіткою документацією про те, що, коли й на яких умовах передавалося. Юридична угода — це підлога вашого захисту, а не стеля.

Що слід зробити перед тим, як ділитися AI-архітектурою з потенційним партнером або клієнтом? Проведіть «аудит рову»: чітко визначте, що є вашим власницьким внеском, а що побудовано на відкритих фреймворках. Спочатку показуйте функціональні можливості, а не архітектурні деталі. Використовуйте обмежені API або пісочниці для пілотів. Переконайтеся, що внутрішня документація створює чіткий хронологічний запис незалежної розробки. І подбайте, щоб угоди про пілот виходили за рамки стандартного шаблону й прямо охоплювали AI-специфічні IP-ризики.

Чи такі суперечки стануть частішими? Так. По мірі того як AI-агентна інфраструктура переходить від експериментальної до критично важливої, економічні ставки за її контроль різко зростають. Справа Runlayer — перший формальний IP-спір в екосистемі MCP, але базова динаміка — відкриті протоколи з власницькими шарами цінності, які оцінюють добре забезпечені потенційні конкуренти, — є структурною. Очікуйте більше справ у цій категорії в міру того, як агентна економіка зрілішає.

---

Позов Runlayer v. Rippling вже робить одну корисну річ: він робить ризик видимим раніше, ніж більшість компаній зіткнуться з ним безпосередньо. Рік інженерної співпраці, провалені комерційні переговори, повідомлення від інсайдера — ця послідовність специфічна для цієї справи, але базова вразливість є універсальною. Будь-яка AI-інновація, яка вимагає глибокого технічного розкриття, щоб довести свою цінність, — це інновація, яку можна зрозуміти, відтворити й протиставити їй конкурента.

Питання для вашого бізнесу не в тому, чи є у вас ризик. Якщо ви будуєте, продаєте або суттєво залежите від власницьких AI-систем — він уже є. Питання в тому, чи ви спроєктували свої комерційні відносини, процеси пілотів і внутрішнє управління з урахуванням цього ризику — або ж ви розраховуєте, що підпис під шаблонною NDA є достатнім.

Для Runlayer це спрацювало як пожежний сповіщувач: сповістив, що пожежа вже почалася. Мета — побудувати те, що не дозволить їй розгорітися взагалі.

Як зараз виглядає ваш процес захисту AI-інновацій — і де, на вашу думку, є прогалини? Запитайте нашого AI-агента, щоб знайти вразливості у вашому конкретному налаштуванні.