Когато AI асистентът чете пощата ви: как го пазим от чужди инструкции

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

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

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

СЪДЪРЖАНИЕ: Кога съдържанието се превръща в команда; как обработваме външните данни; граници на защитата; достъп и действия; въпроси към доставчика; откъде да започнете.

Проблемът започва, когато чужд текст получи право да командва

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

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

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

Полезният въпрос е по-прост: когато външен текст влезе в контекста, с който работи асистентът, какво го задържа в ролята на информация?

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

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

Какво правим, преди материалът да стигне до основния асистент

Вътрешните ни инструкции посочват sanitize.py като пътя, през който външните данни минават, преди да достигнат Claude. Изрично са включени имейли, събития в календара, заявки за поддръжка и съдържание от социални мрежи.

Описаният процес има 3 слоя: проверка по зададени текстови шаблони, оценка на смисъла чрез Haiku и ограждане на съдържанието с XML маркери. Всеки слой има различна задача.

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

Това описание обаче не показва кои точно атаки улавят правилата. В оперативната бележка няма списък на шаблоните, измерена успеваемост или резултати от опити за заобикаляне. Мога да опиша документираната мярка. Не мога да ѝ припиша измерено ниво на защита, за което няма доказателства в материалите.

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

Има важна подробност: това се случва преди основния асистент, не преди всеки модел. Самият Haiku е модел. Когато оценявате поверителността, трябва да знаете какво съдържание получава той, а не само какво стига до асистента, който изпълнява задачата.

Последният слой поставя XML маркери около материала. Това са обозначения, които отделят даден текст от останалия контекст. Нашите инструкции изрично определят съдържанието в <external_data> като недоверено.

Асистентът може да го използва, за да отговори на възложената задача. То обаче не получава право да задава нови задачи само защото е дошло през свързан инструмент.

Защо съчетаваме тези проверки

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

Практическата стойност е в ясно описания път за обработка и разграничаването между чуждо съдържание и разрешени инструкции. Така не разчитаме само на общото указание асистентът да внимава.

Но маркерите са текст, не физическа преграда. Проверката чрез модел остава преценка на модел. А правилото всички външни данни да минават през определен процес не е равнозначно на независим одит, който доказва, че всяка интеграция го спазва.

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

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

Филтърът не поправя прекалено широкия достъп

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

Проверените ни бележки за Copilot посочват именно това: продуктът работи с правата на потребителя, а лошо управляваният достъп до съдържание остава проблем. Това е извод от прегледа на източници, не независим тест на нашата защита или обща присъда за корпоративните асистенти.

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

Същата проверка бих направила и за действията. Да прочетеш заявка, да подготвиш отговор и да го изпратиш са различни права. В разговора с доставчика трябва да е ясно кои от тях има асистентът и кой разрешава промените.

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

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

Тази граница е нужна и извън пощата

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

Същият въпрос важи за уебстраница: възлагаме на асистента да я прочете или неволно ѝ позволяваме да ръководи работата му? Проучването разглежда извлеченото съдържание като възможен източник на чужди инструкции. Кратката оперативна бележка обаче не доказва покритието на всеки браузър или уебинструмент. То трябва да се провери отделно.

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

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

И още нещо: проверката на пощата не е обещание за защита на цялата фирма. Всеки добавен източник или инструмент променя пътя, който трябва да бъде проверен.

Какво бих поискала да ми покаже доставчикът

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

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

Бих поискала и доказателства за ограниченията. Какви тестове са проведени? Какви пропуски са известни? Разграничава ли доставчикът описание на архитектура от наблюдаван резултат? Схемата на защитите и доказателството, че работят, отговарят на различни въпроси.

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

Не ми трябва обещание, че никога няма да има грешка. Трябва ми достатъчно конкретика, за да реша коя работа мога да възложа на системата и къде да запазя човешката проверка.

Започнете със задача, чиито граници можете да обясните

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

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

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

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