Shadow AI вече не е просто служители, използващи неодобрен чатбот. Днес сянка на изкуствен интелект често включва неодобрени агенти с изкуствен интелект работи с реални разрешения: достъп до хранилище, CI/CD токени, API за четене/запис на файлове и съобщения. С други думи, изкуственият интелект в сянка може да се държи като автоматизация на сянка, и затова увеличава риска за сигурността по-бързо, отколкото повечето екипи очакват.
Ето пропускът в сигурността: скритият изкуствен интелект разширява повърхността ви за атака, без да променя контролите ви. Например, един агент може да погълне ненадеждно съдържание, да следва скрити инструкции и след това да извика инструменти, които имат връзка с производствените системи. Следователно, рискът е не само изтичане на данни; той е и... неоторизирани действия изпълнява се със скоростта на машината.
Ако искате практическо определение, можете да цитирате вътрешно: Сянка на изкуствения интелект е всяка функция на изкуствения интелект, използвана без управление, която може да осъществява достъп до чувствителни данни или да задейства реални действия. Съответно, правилният отговор не е „забрана на ИИ“. Вместо това, имате нужда от видимост, минимални привилегии, управление на уменията и одит на извикванията на инструменти, за да контролирате скрития ИИ, без да забавяте доставката.
Какво е Shadow AI?
Shadow AI е използването на инструменти, модели или работни процеси на агенти, свързани с изкуствен интелект. без официално одобрение, наблюдение или управление от ИТ или охрана. Това включва несанкционирани чатботове, разширения за браузър, IDE копилоти и локални или хоствани агенти, свързани с enterprise инструменти. Най-важното е, че сянката на изкуствения интелект създава слепи петна при обработката на данни, контрола на достъпа и одита. Следователно, той може да превърне рутинната дейност на разработчиците в риск за сигурността и съответствието.
Shadow AI срещу Shadow IT срещу Agentic Shadow AI
Сянката на изкуствения интелект (AI) се припокрива със сянката на информационните технологии (IT), но се държи различно. Преди всичко, системите с изкуствен интелект могат уча се от входните данни намлява мащаб деcisйони, докато агентите също могат изпълнява действия чрез инструменти и токени. В резултат на това екипите се нуждаят от по-ясен модел на това, което защитават.
| Измерение | Сянка IT | Shadow AI | Агент Сянка AI |
|---|---|---|---|
| Какво е | Неодобрен софтуер или услуги | Неодобрени инструменти с изкуствен интелект, използвани за работа | Неодобрени AI агенти, които могат да извикват инструменти и да изпълняват действия |
| Типичен пример | Несанкционирани SaaS, плъгини, скриптове | Личен чатбот или редактор с изкуствен интелект, използван с фирмени данни | Агент, свързан с хранилища, CI/CD, имейл, билети, облачни API |
| Основен риск | Излагане на данни, пропуски в съответствието, неуправляем достъп | Изтичане на данни, заобикаляне на политики, непроследено използване на модел | Неоторизирани действия, злоупотреба с привилегии, кражба с помощта на инструменти |
| Скорост на риска | Умерена | Бързо | Много бързо (автоматизация + удостоверения) |
| Пътища за атака | Злоупотреба с идентификационни данни, несигурни конфигурации, злоупотреба с OAuth | Инжектиране на подкани, чувствително регистриране на подкани, проблеми със запазването на данни | Инжектиране на инструменти, верига за доставки на умения, превземане от браузър към локално ниво, прехвърляне на токени |
| Предизвикателство за видимост | Сенчести приложения и неизвестни доставчици | Неизвестно използване на ИИ + неясни потоци от данни | Неизвестно използване на ИИ + скрити извиквания на инструменти + неясно приписване |
| Най-добър първи контрол | SaaS откриване + управление на достъпа | Одобрен AI каталог + правила за редакция + регистриране | Инвентаризация на агенти + минимални привилегии + регистриране на извиквания на инструменти |
| Как изглежда „доброто“ | Одобрен каталог, SSO, регистриране, преглед на доставчика | Одобрен каталог с изкуствен интелект, контроли за съхранение, безопасно боравене с данни | Одобрена среда за изпълнение на агенти, умения в разрешения списък, токени с ограничен обхват, одитирани действия |
Защо рисковете, свързани с агентите на OpenClaw, са важни за DevSecOps
Рисковете на агентите на OpenClaw са от значение, защото агентите променят модела на сигурност от „входни данни, изходни текстови съобщения“ на данни входящи, действия навън, В сянка на изкуствен интелект сценарий, това означава, че един разработчик може да стартира неуправляем агент, който се свързва с хранилища, CI/CD, облачни API и инструменти за съобщения. В резултат на това, сянката на изкуствения интелект се превръща в сянка автоматизация с идентификационни данни.
Тази промяна нарушава общоприети предположения. Например, екипите често третират „локалните агенти“ като нискорискови, защото те работят на лаптоп или се свързват с localhost. Последните инциденти с OpenClaw обаче показват, че браузърът може да се превърне в мост, токените могат да бъдат разкрити и шлюзовете на инструменти могат да бъдат поети, дори в „само локални“ настройки.
Накратко, след като агент може да извиква инструменти, вашият модел на заплахата трябва да включва кражба на токени, злоупотреба с инструменти, компрометиране на веригата за доставки на умения и индиректно инжектиранеВ противен случай ще пропуснете най-рисковата част от сянката на изкуствения интелект.
Най-сериозните инциденти с OpenClaw (потвърдени)
1) CVE-2026-25253 — Завладяване с 1 клик / RCE път чрез злонамерен линк
Въздействие: Максимална (висока вероятност + високо въздействие)
Какво е активирано (високо ниво):
- OpenClaw може да получи
gatewayUrlот низ на заявка и автоматично отваряне на WebSocket връзка без подкана, изпращане на стойност на токен в процеса. - Това излагане на токени може да даде възможност превземане на шлюз и злоупотреба надолу по веригата в зависимост от разрешенията и конфигурацията.
Защо е толкова тежко:
Това превръща „щракване върху връзка“ в „компрометиране на инструментариума на агента“, което е точно начинът, по който се превръща в скрит изкуствен интелект. сянка автоматизация с идентификационни данни.
2) ClawJacked — drive-by уебсайт → localhost WebSocket brute force → пълно отвличане на агент
Въздействие: Много висок (тих + мащабируем модел)
Какво е активирано (високо ниво):
Злонамерен уебсайт може да отвори WebSocket връзка към Localhost и да се насочат към локалната услуга на OpenClaw.
Със слабо удостоверяване, базирано на парола, нападателите биха могли да принудят паролата чрез груба сила и да получат надежден достъп, което ще им позволи пълен контрол на екземпляра на агента.
Защо е толкова тежко:
Това нарушава предположението „localhost е безопасен“. На практика, браузърът се превръща в мост, така че „само локално“ не е реална граница.
3) Злоупотреба с екосистемата от умения: ToxicSkills + злонамерени умения на ClawHub (верига за доставки на умения на агенти)
Въздействие: От високо до максимално (мащаб + постоянство)
Какво е активирано (високо ниво):
Злонамерен или уязвим умения могат да се държат като зависимости: инсталирани от пазар, актуализирани независимо и често работещи с разрешения на ниво агент.
Независим анализ на изследвания 3,984 намерени умения на агент 13.4% (534) имаше поне един критичен проблем, включително разпространение на зловреден софтуер, бързо инжектиране и разкрити тайни.
Примери от реалния свят показват, че нападателите доставят „умения“ с крипто тематика, за да разпространяват зловреден софтуер или да крадат чувствителни данни чрез социално инженерство и обфускирани команди.
Защо е толкова тежко:
Това е риск за веригата за доставки, но за агентите: „умението“ може да наследи способността на агента да чете файлове, да има достъп до тайни или да изпълнява действия с инструменти.
| Инцидент | Тип атака | Потребителско взаимодействие | Първоначално следствие | Източници |
|---|---|---|---|---|
| CVE-2026 25253- | Злонамерена връзка → низ за заявка gatewayUrl → експозиция на токени → поемане на шлюз / път на RCE | 1 клик (UI:R) | Компрометиране на шлюза; потенциално изпълнение надолу по веригата в зависимост от разрешенията | NVD (NIST) INCIBE-CERT Хакерът новини |
| Ноктевидно изтръгнат | Сайт с Drive-by → localhost WebSocket → brute force → отвличане на агент | Посетете сайт | Пълно поемане на контрол от локален агент; достъп до лог/конфигурация/данни | Оазис Секюрити TechRadar Хакерът новини |
| ToxicSkills / злонамерени умения на ClawHub | Пазар на умения като верига за доставки (зловреден софтуер, инжектиране на вируси, разкриване на тайни) | Променлива (умение за инсталиране/използване) | Компрометиране на ниво агент чрез наследени разрешения и злонамерено поведение на уменията | Том Хардуер Хакерът новини |
Случай на употреба: намаляване на риска от сенчестия изкуствен интелект в стил OpenClaw с работен процес на DevSecOps
OpenClaw е полезен казус, защото показва как сянка на изкуствен интелект се превръща в реален оперативен риск: агентът работи „локално“, свързва се с хранилища и pipelineи изведнъж посещение на браузър, токен или умение на трета страна може да се превърне в поглъщане. Целта не е да се забранят агентите. Вместо това е да се гарантира, че работата, управлявана от агентите, протича през същите контроли, на които вече имате доверие за кода и веригата за доставки.
Стъпка 1: Отнасяйте се към „уменията“ на агентите като към зависимости, а не като към безобидни добавки
Повечето инциденти с изкуствен интелект в сянка не започват със сложен експлойт. Те започват с внедряването: разработчик инсталира агент, добавя няколко умения и му дава достъп, „за да работи“. От този момент екосистемата на агентите се държи като екосистема на пакети: уменията се актуализират, появяват се помощни скриптове и ненадежден код може да влиза тихо.
Така че първата стъпка е да се промени начинът на мислене: Всичко, което агентът може да инсталира или изпълни, е част от вашата верига за доставки., В Работен процес на Xygeni, това означава, че не чакате доклад за нарушение. Фокусирате се върху по-ранни сигнали, че даден компонент е рисков или откровено злонамерен, така че приемането спира, преди да се разпространи в хранилищата и машините на разработчиците.
Какво се променя на практика
- Екипите спират копирането и поставянето на „работещи конфигурации на агенти“ без преглед
- Новите умения и помощните пакети се третират като прием на зависими лица, а не като лични инструменти.
Стъпка 2: Направете PRs контролната точка, дори когато промяната е написана от агент
Агентите ускоряват промяната. Това е смисълът. Историята на OpenClaw обаче показва колко бързо „малките промени“ се превръщат в събития, свързани със сигурността, след като са включени токени и шлюзове за инструменти. Следователно, разчитането на „предпазливостта на разработчиците“ не е достатъчно.
Вместо това, изходът на агента се маршрутизира през pull requests и да наложат сканиране по време на PR. По този начин, дори ако агент предложи увеличаване на зависимостите, промяна на скрипт за изграждане или редакция на работен процес в CI, PR се превръща в точката на затруднение, където се прилага политиката. Xygeni се вписва естествено тук, защото е построен за CI/CD и PR работни процеси, така че рисковите промени се улавят преди сливането им.
Типични промени, задвижвани от агенти, които искате да бъдат контролирани
- Надстройки на зависимости и прехвърляне на заключени файлове
- Създаване на скриптове и инсталиране hooks
- Редактиране на работен процес в CI (разрешения, използване на тайни, мрежови повиквания)
- Нови стъпки за автоматизация, които се изпълняват с повишени права
Стъпка 3: Приоритизирайте какво ще използват нападателите, а не само какво откриват скенерите
Сянката на изкуствения интелект увеличава обема. Повече автоматизация означава повече отклонение на зависимостите, повече изместване на конфигурациите и повече „малки промени“ седмично. Следователно екипите могат да се удавят в открития, освен ако приоритизирането не е насочено към реална експлоатационна пригодност.
Тук е важно контекстът на експлойта. Ако е вероятно един проблем да бъде експлоатиран, а друг не, вашият работен процес трябва да отразява тази разлика. Xygeni's подход на приоритизиране е проектиран за тази реалност: намаляване на шума чрез фокусиране на отстраняването на проблемите върху това, което е най-вероятно да има значение на практика.
Просто правило, което се мащабира
- Блокиране или ускоряване на решенията за проблемите с най-висок реален риск
- Отложете шума от нисък сигнал, за да могат инженерите да продължат безопасно да превозват
Стъпка 4: Спрете да приемате, че „localhost е безопасен“
ClawJacked работи като урок, защото атакува едно предположение, което много екипи все още поддържат: „ако е локално, е добре“. В действителност, локалните шлюзове и локалните потребителски интерфейси все още изискват мислене на производствено ниво. Браузърът е част от повърхността на заплахата и „само локално“ не е граница, на която можете да разчитате.
Така че подсилвате локалните услуги, както бихте направили с всеки чувствителен интерфейс:
- Силно удостоверяване (не само избрана от човек парола)
- Ограничения на скоростта и блокировки
- Няма поведение за автоматично свързване, което се доверява на невалидирани входни данни
- Ограничете кой може да се свързва и откъде
Въпреки че Xygeni не е локална защитна стена, тя помага за намаляване на практическото въздействие на моделите за „локално заобикаляне“, като премества прилагането им към pipeline и платформа. Когато контролите са налице CI/CD намлява политики за сигурност, сянката на изкуствения интелект е по-малко вероятно да ги заобиколи, „защото е локална“.
Стъпка 5: Следете за необичайно поведение, което изглежда като злоупотреба с веригата за доставки
Инцидентите в стил OpenClaw често споделят общ режим на отказ: нещо се променя тихо, след което работните процеси започват да се държат различно. Ето защо сигналите, фокусирани върху аномалии, са важни. Ако дадена среда внезапно започне да изтегля необичайни зависимости, да публикува версии бързо или да показва модели, съответстващи на злоупотреба с веригата за доставки, е желателно това да бъде сигнализирано рано.
Откриване на аномалии на Xygeni и системата за ранно предупреждение е в съответствие с тази цел: да се разкриват подозрителни модели рано, преди те да се превърнат в повтарящи се инциденти в екипите.
Сигнали, за които си струва да се внимава
- Внезапни пикове в промените в зависимостите между хранилищата
- Нови пакети/умения с ниска репутация или странни модели на актуализация
- Неочаквани стъпки на CI, които изтеглят среда за изпълнение или изпълняват скриптове
- Необичайни мрежови извиквания от контексти на изграждане
Храна за вкъщи
Този работен процес умишлено не е „специфичен за агента“. Това е DevSecOps модел, който работи за скрит ИИ в голям мащаб: третира умения като зависимости, промени в гейта по време на PR/CI, приоритизиране на това, което е експлоатираемо, спиране на доверието на localhost по подразбиране и ранно откриване на необичайно поведение във веригата за доставки. Ето как намалявате сянка на изкуствен интелект риск без забавяне на доставката.
Сигурност на скрит изкуствен интелект: Какво означава това за екипите на DevSecOps
Сянката на изкуствения интелект вече не е страничен проблем. През 2026 г. това все повече означава агенти с реални разрешения, което превръща прости грешки в инциденти, предизвикани от инструменти. OpenClaw е най-ясното напомняне: рискът не е само това, което моделът „казва“, а това, което агентът може do с жетони, портали и умения.
Съответно, най-ефективният отговор е практически, а не теоретичен. Третирайте уменията на агента като зависимости, насочвайте изхода на агента през PR и CI/CD guardrailsи спрете да приемате, че „localhost е безопасен“. В същото време, приоритизирайте това, което всъщност може да бъде експлоатирано, за да могат екипите да продължат да доставят, без да се давят в шум.
В крайна сметка, не е нужно да забранявате агенти, за да контролирате сигурност в сянка с изкуствен интелектТрябва да се уверите, че работните процеси, управлявани от агенти, не могат да заобиколят същата верига за доставки и контрол на доставката, която вече защитава жизнения цикъл на вашия софтуер.
