Какво всъщност обхваща един тест за проникване в AI

Оценка на AI сигурността може да включва административни услуги, извличане на данни, действия на агенти, prompt injection и обичайни приложни контроли. Това са свързани, но различни направления. Определете кои са в обхвата и какви доказателства ще даде всяко, вместо да приемате, че етикетът определя дълбочината или метода.

Тестване с помощта на AI и тестване на AI приложения

Това са различни понятия. При тест с помощта на AI изкуственият интелект се използва за изследване на софтуер, който може изобщо да няма AI функционалности. Оценката на AI сигурността изследва приложение с такива функционалности: правата, потоците от данни, административните услуги и действията на агентите. Самата оценка може да използва ръчни, автоматизирани или комбинирани техники.

Услугата на Pixel отговаря на втория въпрос. Уточнете кои AI компоненти и акаунти са в обхвата и какви доказателства ви трябват. За сравнение на начините на изпълнение прочетете ръководството ни за автоматизирано тестване и тестове от специалисти.

Защо „тествайте нашия AI“ е неясно искане

Онзи, който пита, почти винаги има едно конкретно притеснение наум и почти никога не казва кое. Едни и същи няколко се появяват в разговорите ни за обхват и изискват наистина различна работа.

„Може ли да бъде убеден да каже нещо смущаващо?“ Въпрос за поведението на модела — откази, тон, предубеденост, небезопасен изход. Отговаря се чрез red teaming на безопасността спрямо политика за съдържанието: упражнение по съдържание, не по сигурност.

„Добро ли е това нещо?“ Точност, честота на халюцинации, качество на извличането — проблем на оценяването, измерван спрямо маркиран набор от данни със система за оценяване от екипа, който е изградил функцията.

„Имаме ли право да пуснем това?“ Управление и задължения: документация, класификация на риска, човешки надзор, водене на записи. Отправните точки са NIST AI Risk Management Framework, ISO/IEC 42001 и, където се прилага, Регламентът на ЕС за изкуствения интелект. Работа по увереност, обикновено с участието на одитор или юридически съветник.

„Може ли някой да използва тази функционалност, за да получи данни или контрол, които не бива да има?“ Това е тест за проникване — оторизация, граници на доверие, данни за достъп и достижима повърхност за атака, отговорено от някой, който опитва атаките и ви показва какво е проработило.

Това не са степени на едно и също нещо. Доставчик може да свърши отлична работа по едното и да остави другите три недокоснати, а тъй като и четирите се продават като „тестване на сигурността на AI“, можете да купите едното, вярвайки, че сте получили друго.

Първият риск обикновено е административният слой

Почти целият публичен разговор за сигурността на AI е за инжектирането на промпти. Това е действителен клас атаки, наистина труден за поправяне, и се демонстрира прекрасно на среща. Но AI функционалност вътре в бизнес приложение не е модел. Тя е малка разпределена система със собствена административна повърхност: нещо съхранява конфигурацията на промптите, нещо държи данните за достъп, които процесът използва, за да достигне обектното хранилище и обкръжаващите бизнес системи, нещо създава, обучава и изтрива модели, нещо задейства задачите, които внасят вашите данни. Всичко това е конфигурация, всичко е изложено през HTTP, и го виждаме достижимо от потребители, за които никога не е било предвидено.

Prompt injection може да разкрие данни или да предизвика опасна употреба на инструменти, когато приложните контроли го позволяват. Административните записи могат да дадат друг пряк път към конфигурация и credentials според правата им. Тествайте и двата вида според достижимите възможности и очакваните права. Нашият анализ на административния слой обяснява защо го включваме рано; това не е причина да се изключват рисковете от prompt injection.

Един ангажимент прави това осезаемо. В корпоративна SaaS платформа с вградени генеративни AI функционалности, тествайки като обикновен неадминистраторски потребител на клиентска организация, намерихме административните услуги на AI да приемат привилегировани операции за запис от обикновен бизнес потребител. Токенът твърдеше, че не е администратор, а административният интерфейс правилно скриваше екраните си — само от страна на клиента. AI услугите зад него не налагаха никаква проверка за администратор от страна на сървъра и приемаха записи само въз основа на груби обхвати на нивото на услугата. Този потребител можеше да запише и прочете обратно идентификационните данни до обектното хранилище на AI процеса, на практика избирайки къде се записват данните за обучение и изпълнение на модела на процеса; да запише конфигурацията на генеративните AI промпти; да запише отделно хранилище с данни за достъп до бизнес система; да задейства задачата за зареждане на данни; и да управлява целия жизнен цикъл на модела.

Сравнението със съседната услуга за идентичност показва, че платформата може да налага административно ограничение. AI услугите изискват собствена ефективна политика за права. Тест само на отговорите на модела не покрива тези API операции; това не доказва липса на prompt injection или че една обща административна роля е подходяща за всяка AI операция.

Какво всъщност е в обхвата

Шест области. Първите две произвеждат по-голямата част от сериозните констатации.

Административният слой на AI

Изброяване на всяка административна операция, която AI компонентът излага — конфигурация на промпти и шаблони, точки за разширение, където се вплитат специфични за клиентската организация инструкции, записи с данни за достъп и връзки, създаване, обучение и изтриване на модели, внедряване, задействане на зареждане — после опит на всяка от тях с потребителя с най-малко права, който може да се удостовери. Четенето и записът се тестват отделно, защото рутинно се различават. Онова, което искате обратно, е запис операция по операция какво е наложил сървърът, а не уверение, че областта е защитена чрез роли.

Оторизация и изолация на AI данните между клиентски организации

AI функционалностите генерират и съхраняват много: нишки от разговори, заредени документи, векторни представяния, генерирани артефакти. Те обикновено се помещават в нова услуга със собствено хранилище и собствено пространство от идентификатори, свързана със сесията за удостоверяване, но често не и със съществуващия модел на платформата за оторизация на обекти. Затова тестерът създава съдържание като двама потребители в една и съща роля и като потребители в две клиентски организации, разменя идентификаторите в двете посоки и тества извличането, метаданните, експортирането и изтриването отделно. Производните артефакти заслужават собствено внимание: генерирано резюме може да е по-чувствително от всеки запис зад него, защото анализът е стойността.

Границата на оторизация на агента и инструментите

Ако функцията може да прави неща — да извиква вътрешни API, да чете запис, да създава заявка, да изпълнява запитване — решаващият въпрос е под чия власт действа. Носи ли всяко извикване на инструмент идентичността на крайния потребител и бива ли оторизирано спрямо нея, или агентът държи една служебна идентичност, достатъчно широка да обслужва всички? Вторият модел е чест и прави агента класически „объркан заместник“: потребител с право върху данните на един регион задава въпрос, а инструментът отговаря от всички. Тестването му означава изброяване на списъка с инструменти, после опит през агента да се направи това, което искащият потребител не може да направи директно. OWASP Agentic Security Initiative е разумна публична препратка тук.

Инжектиране на промпти, пряко и косвено

Прякото инжектиране е потребителят, който отменя инструкциите в собствения си ход. Косвеното инжектиране е интересното: инструкции, поставени в съдържание, което системата зарежда — документ, коментар по заявка, уеб страница, име на файл — и по-късно третирани като достоверни. Там инжектирането спира да бъде фокус, защото нападателят не се нуждае от акаунт, за да го достигне.

Настоявайте инжектирането да бъде тествано за последствие. „Моделът произведе недопустим текст“ е слаба констатация; „съдържание, поставено в зареден документ, накара агента да извика инструмент и да върне данните на друг потребител“ е действителна. Полезният товар не е констатацията; констатацията е това, което той е достигнал.

Пътят на данните и съхранението

Следвайте данните. Къде отиват промптите, разговорите, качените файлове и изходите, кои компоненти и трети страни ги виждат, какво се журналира и с каква подробност, колко дълго всяко хранилище го пази, какво се случва при изтриване. Журналите и следите са повтарящ се проблем, защото инструментите за наблюдаемост на AI процеси улавят пълните тела на промптите и отговорите и после стоят някъде с далеч по-широк достъп от приложението. Проверете дали хранилището зад артефактите е достижимо без сесия и дали данните му за достъп са дълготрайни и широко обхватни.

Обикновената уеб и API сигурност на AI крайните точки

Небляскавата част, а прескачането ѝ е грешка. AI крайните точки са уеб крайни точки: удостоверяване на всеки маршрут, включително поточните, оторизация на всеки от тях, ограничаване на честотата и контрол на разходите, ограничения на размера на входните данни, обработка на грешки, която не разкрива стекови следи или вътрешни имена на хостове, конфигурация на CORS, никакви тайни в клиентския пакет. AI функционалностите често се изграждат бързо и встрани от основното приложение, а не вътре в него, затова пропускат защитите на нивото на рамката, които останалата част от платформата получава безплатно. Нашият подход към този слой е на страницата ни за методология; AI работата стои върху него.

Какво не е един AI тест за проникване

Другите три вида работа са действителни и някой трябва да ги върши.

Не е red teaming на безопасността на модела. Дали асистентът може да бъде подтикнат да произведе съдържание с ненавист, предубеденост или извън политиката изисква писмена политика за съдържанието, спрямо която да се измерва, голям обем опити и проверяващи с подходяща подготовка. Отчитаме това, на което се натъкнем, но ако това е действителната ви грижа, искате упражнение по red teaming на безопасността, обикновено с участието на функцията ви по доверие и безопасност или на правния отдел.

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

Не е сертификация за съответствие. Тестът произвежда техническо доказателство, което може да подкрепи дейност по увереност. Той не ви прави съответстващи на каквото и да е, а ние не сме одитор, оценител или сертифициращ орган. Ако за вас се прилага задължение, уговорете какво трябва да показват доказателствата ви с онзи, който ги одобрява, преди определянето на обхвата.

Ако функцията извиква hosted модел, разграничете вашето приложение, оркестрация и данни от инфраструктурата на доставчика. Вашето разрешение не обхваща автоматично неговите системи. Тестването им изисква приложимото разрешение и правила на доставчика; разрешена изследователска програма може да определя отделен обхват.

Какво трябва да дадете на тестерите

AI ангажиментите са необичайно чувствителни към подготовката, защото толкова голяма част от стойността е в тестването на оторизацията — невъзможно без акаунти.

По два акаунта за всяка роля, плюс един администратор. Двама потребители на едно и също ниво на права в една клиентска организация са това, което прави възможно тестването на хоризонталния контрол на достъпа — един достига разговорите и документите на другия. Един акаунт за всяка роля тества само вертикалните граници, по-лесната половина. Административният акаунт изглежда противоинтуитивен, но тестерът трябва да види административната повърхност да работи както е предвидено, за да я изброи и после да я опита отдолу.

Две клиентски организации, ако платформата ви обслужва множество организации. Изолацията между клиентски организации не може да бъде тествана отвътре на една клиентска организация. Ако осигуряването на втори е бавно, започнете, преди да запазите ангажимента.

Среда с данни. Празна база знания и липса на история на разговорите означават, че няма нищо, което да бъде достигнато през граница. Ясно обозначени синтетични данни в корпуса струват повече от достъп до продукционната среда и избягват цяла категория трудни разговори.

Списъкът с инструменти на агента, с параметрите. Всеки инструмент, който моделът може да извика, какво прави, какво приема и под коя идентичност работи. Ако такъв документ не съществува, самото му написване е ценно, а липсата му обикновено е констатация в изчакване.

Писмено изявление какво функцията има право да прави. Най-често липсващото и точката, която най-много променя отчета: кои роли могат да я използват, кои области от данни може да докосва, кои действия може да извършва от името на потребител, какво трябва да откаже. Без това тестерът може да отчете какво прави системата, но не и къде тя се разминава с това, което сте предвидили — а именно тази разлика е констатацията за оторизация.

Бележки по архитектурата и достъпен инженер. Къде се намира слоят за оркестрация, кои хранилища съдържат промпти, векторни представяния и артефакти, кои данни за достъп държи процесът, дали някоя част се управлява от доставчик. После решете писмено дали тестерът може да задейства обучения и задачи за зареждане на данни — не операции само за четене — и на кого да се обади, когато нещо се забие.

Как да различите действителен AI тест от демонстрация на инжектиране на промпт

Обикновено можете да разберете от предложението.

За какво пита разговорът за обхвата? Действителният пита за роли, клиентски организации, списъка с инструменти, къде живеят промптите и данните за достъп, кои операции функцията извършва и под чия идентичност. Повърхностният иска URL и данни за вход, после дава оферта.

Назовава ли обхватът административната повърхност? Ако конфигурацията на промптите, записите с данни за достъп, жизненият цикъл на модела и зареждането на данни отсъстват от документа за обхвата, те ще отсъстват и от отчета.

Колко акаунта и клиентски организации искат? Най-бързият наличен сигнал. Доставчик, който не иска по два потребителя за всяка роля, не е планирал да тества хоризонталния контрол на достъпа, каквото и да обещава разделът за методологията.

Формулирани ли са констатациите като последствия или като изходи? „Моделът може да бъде jailbreak-нат с този низ“ е демонстрация. „Непривилегирован потребител можеше да замени данните за достъп до хранилището на процеса, и ето я заявката“ е констатация. Поискайте да прочетете анонимизирана констатация, преди да подпишете — нашите са в примерния отчет.

Покрива ли повторният тест констатациите за оторизацията? Поправките по контрола на достъпа се прилагат към отчетената крайна точка, а не към съседните ѝ, така че повторен тест, който опитва отново цялата административна повърхност, струва далеч повече от такъв, който проверява отново една заявка. А доставчик, който казва ясно какво не покрива, вдъхва повече доверие за това, което твърди.

Контролен списък за определяне на обхват

Минете през това, преди да се обърнете към когото и да е.

РЕШЕТЕ ПЪРВО
  [ ] На кой въпрос плащам да бъде отговорено?
      сигурност / безопасност / точност / управление
  [ ] Най-лошият реалистичен изход, ако функцията бъде използвана зловредно
  [ ] Коя среда и колко близо съответства на производствената

ОБХВАТ — назовете тези или няма да бъдат тествани
  [ ] Административен слой: конфигурация на промптове и шаблони, точки
      за разширение, записи с данни за достъп и връзки, жизнен цикъл на модела,
      внедряване, задействане на зареждане
  [ ] Оторизация и изолация между наематели за разговори, документи,
      вграждания, генерирани артефакти (четене, запис, експорт, изтриване)
  [ ] Граница агент/инструменти: под чия идентичност работи всеки инструмент
  [ ] Инжектиране на промптове, пряко и косвено, тествано за последствие
  [ ] Път на данните, журналиране и съхранение, вкл. хранилищата за наблюдаемост
  [ ] Уеб/API сигурност на AI крайните точки: удостоверяване, оторизация,
      ограничаване на честотата, ограничения на входните данни, разкриване чрез грешки, CORS
  [ ] Извън обхвата, заявено: инфраструктура на модел на трета страна,
      оценка на точността, red teaming на съдържанието, сертификация

ОСИГУРЕТЕ
  [ ] По два акаунта за всяка роля, в един наемател; плюс един администратор
  [ ] Два наемателя, ако сте многонаемателни
  [ ] Корпус с данни от ясно обозначени синтетични данни
  [ ] Списъка с инструменти: параметри и идентичността, под която работи всеки
  [ ] Какво функцията може да прави и какво трябва да откаже, писмено
  [ ] Бележки по архитектурата и назован, достъпен инженер
  [ ] Писмено съгласие за извиквания на обучение и зареждане

УГОВОРЕТЕ ПРЕДИ ПОДПИСВАНЕ
  [ ] Констатациите носят заявката, акаунта и последствието
  [ ] Повторният тест опитва отново цялата административна повърхност
  [ ] Покритието е съотнесено към публична препратка при поискване
  [ ] Работата с данните, които тестването произвежда, и срокът им на съхранение

Основната идея е достатъчно проста, за да се побере в една среща. AI функционалността е нова система с нова административна повърхност, прикрепена към приложение, чийто модел на права никой не е преразгледал, когато тя е била включена. Тестът, който искате, установява кой може да достигне тази повърхност, под чия власт действа функцията и дали данните, които тя генерира, спазват границите, които останалата част от продукта ви спазва. Инжектирането на промпти принадлежи на обхвата и ние го тестваме — но то е път към тези въпроси, не самият въпрос. Нашата страница за тестване за проникване в AI описва как го провеждаме.