Prompt injection — гэта не памылковы запыт, які можна выдаліць адным рэгулярным выразам. Гэта парушэнне мяжы даверу, калі змесціва, якое трэба было апрацоўваць як даныя, змяняе паводзіны моўнай мадэлі. У AI-агенце такая змена можа стаць выклікам інструмента, паведамленнем, запісам файла або запытам да іншага сэрвісу. Model Context Protocol (MCP) спрашчае пошук і выклік інструментаў, але адначасова дае недаверанаму тэксту больш шляхоў да мадэлі і прывілеяваных сістэм.
Гэты артыкул прымяняе OWASP GenAI LLM Top 10 2026 да агентаў, якія чытаюць знешні кантэнт і выкарыстоўваюць MCP. Гэта інжынерная мадэль пагроз і кіраўніцтва па абароне, а не аўдыт бяспекі. Ніводны апісаны кантроль не гарантуе поўнай бяспекі. Практычная мэта іншая: дапусціць, што ін’екцыя часам паўплывае на мадэль, і зрабіць выніковае дзеянне абмежаваным, бачным, зварачальным і складаным для перанакіравання.
Чаму мадэль не з’яўляецца мяжой бяспекі
LLM атрымлівае сістэмныя інструкцыі, запыт карыстальніка, знойдзеныя дакументы, апісанні і вынікі інструментаў, гісторыю дыялогу і памяць у адным кантэксце. Раздзяляльнікі і пазнакі могуць растлумачыць палітыку даверу, але не ствараюць архітэктурнай ізаляцыі. Мадэль можа няправільна зразумець пазнаку, прыняць праўдападобны сказ у дакуменце за каманду або скласці небяспечны план з некалькіх нібыта бяскрыўдных падказак.
OWASP LLM01:2026 апісвае prompt injection як змяненне паводзінаў пад уплывам прамога ўводу, атрыманага кантэнту, выніку інструмента, выявы, аўдыё, відэа, прамежкавага кантэксту або пастаяннай памяці. Гэтая катэгорыя адрозніваецца ад раскрыцця адчувальнай інфармацыі, залішняй агентнасці і небяспечнай апрацоўкі вываду, але ў адной атацы яны злучаюцца. Ін’екцыя дае ўплыў, інструмент — прывілей, сакрэт з’яўляецца актывам, а сеткавы запыт, URL або shell-каманда могуць стаць каналам вываду.
Мадэль не павінна захоўваць уліковыя даныя, прымаць рашэнне аб аўтарызацыі або быць адзіным валідатарам аперацыі, якая змяняе стан. Вынесіце гэтыя рашэнні ў дэтэрмінаваны код праграмы. Няхай мадэль тлумачыць і плануе, а сістэма вакол яе прымусова вызначае, што дазволена выканаць.
Мадэль пагроз для агента з MCP
Пачніце з рэальнага патоку даных, а не са схемы, якая заканчваецца на чаце. Вызначце карыстальніка, пастаўшчыка мадэлі, асяроддзе агента, MCP-кліент і серверы, сервер аўтарызацыі, знешнія API, браўзер, файлавую сістэму, памяць, пошукавы індэкс, журналы і выходную сетку. Для кожнай сувязі пазначце, ці стварыў кантэнт карыстальнік, арганізацыя, трэцяя асоба, публічная крыніца або невядомы ўдзельнік.
Нападнікам можа быць шкодны сайт або адпраўнік ліста, аўтар, які змяняе тікет ці рэпазіторый, скампраметаваная залежнасць або MCP-пакет, несумленны аператар інструмента або злодзей токена ці ідэнтыфікатара сесіі. Добрасумленны карыстальнік таксама можа ненаўмысна перадаць ін’екцыю, уставіўшы дакумент з інструкцыямі для іншай сістэмы. Унутраная база не становіцца чыстай толькі таму, што патрабуе ўваходу: запіс мог прыйсці з публічнай формы, сінхранізацыі або ўзламанага ўліковага запісу.
Асобна пералічыце актывы: сістэмныя і распрацоўніцкія інструкцыі, токены, ключы, персанальныя даныя, код, прыватныя дакументы, воблачныя метаданыя, канфігурацыю інструментаў, памяць і магчымасць адпраўляць, выдаляць, купляць, разгортваць або змяняць. Пазначце, што можна чытаць, запісваць або назіраць звонку. Нават інструмент толькі для чытання можа выдаць даныя, калі яго вынік адпраўляецца на адрас нападніка. Інструмент апавяшчэнняў становіцца небяспечным каналам, калі прымае адвольны URL або тэкст.
Для кожнага патоку запішыце інварыянт простымі словамі: «падсумаваць тікет і не выконваць яго інструкцыі», «чытаць толькі гэты рэпазіторый», «падрыхтаваць ліст, але не адпраўляць без пацверджання». Побач зафіксуйце ўмову адмовы: сакрэт у аргуменце інструмента, scope шырэйшы за задачу, запіс па-за працоўнай вобласцю або адрас, не дазволены палітыкай.
Карысная картка рызыкі мае пяць палёў: паверхня дастаўкі, распаўсюджванне, кадаванне, прывілеі і канал уплыву. Дастаўка можа ісці праз чат, вэб-старонку, PDF, апісанне MCP-інструмента, вынік інструмента або памяць. Распаўсюджванне можа перасякаць крокі, сесіі і агентаў. Кадаванне бывае бачным тэкстам, HTML, нябачным Unicode, мовай з малымі рэсурсамі, выявай, аўдыё або абфускацыяй. Прывілеі — гэта асоба і scopes падчас выканання. Канал уплыву стварае наступства.
Прамая і ўскосная ін’екцыя
Прамая ін’екцыя прыходзіць праз шлях, які бачыць карыстальнік. Хтосьці можа папрасіць агента ігнараваць задачу, раскрыць схаваныя інструкцыі, выканаць неабмежаваную каманду або выклікаць інструмент па-за кантэкстам. Сюды адносіцца і сумленны карыстальнік, які ўставіў тэкст з камандай для AI. Jailbreak — выпадак, калі мэта ў абыходзе абароны мадэлі, але для шкоды агенту ён не патрэбны. Ветлівае выкананне фальшывай інструкцыі аб вяртанні грошай усё роўна парушае мяжу праграмы.
Ускосная ін’екцыя знаходзіцца ў змесціве, якое карыстальнік не падаваў як інструкцыю. Вэб-старонка можа запатрабаваць загрузіць кантэкст агента. Укладанне ў лісце можа папрасіць скінуць пароль. Тікет можа загадаць шукаць прыватны рэпазіторый. Payload можа быць у радку базы, загалоўку issue, README, выяве або адказе інструмента. Карыстальнік можа не ўбачыць байты ў HTML, метаданых, згорнутым блоку, выяве або сімвалах нулявой шырыні.
MCP пашырае паверхню ў двух кірунках. Сервер публікуе імёны, апісанні, схемы ўводу, рэсурсы і prompts, якія кліент дадае ў кантэкст мадэлі. Атручанае апісанне можа загадаць спачатку выклікаць іншы інструмент, дадаць сакрэт у аргумент або давяраць URL нападніка. Затым вынік сервера можа выглядаць для мадэлі новай інструкцыяй і выклікаць другі інструмент. Гэта атручванне інструмента або ін’екцыя праз вынік, нават калі паведамленні JSON-RPC карэктныя.
Ставіцеся да метаданых інструмента як да выканальнага ўплыву, а не да дакументацыі. Фіксуйце версіі пакетаў, правярайце серверы, праглядайце апісанні і схемы, параўноўвайце рэлізы і вядзіце інвентар дазволеных магчымасцей кожнага сервера. Подпіс пацвярджае паходжанне, але не даказвае бяскрыўднасць зафіксаванай версіі. Трэба таксама правяраць рэалізацыю і сеткавыя паводзіны.
Ад уплыву да вываду даных
Prompt injection становіцца ўцечкай, калі злучае крыніцу з каналам уплыву. Крыніцай можа быць атручаны issue, які знайшоў агент. Каналам можа быць HTTP-запыт, ліст, публічны каментар, запрашэнне ў каляндар, URL выявы, журнал або аргумент інструмента. Нападніку не патрэбны непасрэдны доступ да прыватных даных, калі агент можа іх прачытаць і звязацца са знешнім светам.
Яўна мадэлюйце «смяротную трыяду»: недавераны кантэнт, адчувальныя даныя і знешні або змяняючы стан канал. Часта надзейней прыбраць адзін элемент, чым распазнаваць кожны шкодны сказ. Агент для даследавання можа праглядаць публічныя старонкі без уваходу і з абмежаванай сеткай. Суматар прыватных дакументаў можа чытаць іх без сеткі і магчымасці адпраўкі. Агент для падрыхтоўкі ліста можа стварыць чарнавік без права адпраўкі.
Не спадзявайцеся толькі на фільтрацыю вываду. Сакрэт можа выйсці ў дапушчальным полі JSON, параметры URL, дыягностыцы інструмента, выяве, прабелах, Unicode або звычайным лісце. Да канала ўплыву ўжывайце палітыку адрасатаў і патокаў інфармацыі. Маскіруйце сакрэты ў журналах і трасіроўках, а выходныя запыты праводзьце праз проксі, які блакуе прыватныя адрасы, невядомыя дамены і нечаканыя метады.
Аўтарызацыя MCP і кантролі OAuth
Для абароненага HTTP-сервера MCP раздзяляйце ролі пратаколу. MCP-сервер — resource server, кліент запытвае доступ ад імя ўладальніка рэсурсу, а authorization server выдае токены. Выконвайце спецыфікацыю аўтарызацыі MCP і патрабаванні OAuth адпаведнай версіі, а не вынаходзьце ўласны proxy-паток.
Прывяжыце токен да патрэбнага MCP-рэсурсу. Спецыфікацыя патрабуе перадаваць кананічны URI сервера ў параметры OAuth resource і ў запыце аўтарызацыі, і ў запыце токена. Сервер павінен праверыць, што токен выдадзены яму. Выкарыстоўвайце загаловак Authorization, а не радок запыту. MCP-сервер не павінен прымаць або перадаваць токен іншага рэсурсу. Для верхняга API патрэбны асобны токен. Перадача токена руйнуе падзел аўдыторыі, аслабляе ліміты і аўдыт і можа ператварыць сервер у проксі ўцечкі.
Абараняйце authorization code з дапамогай PKCE, дакладных зарэгістраваных redirect URI, HTTPS у production і крыптаграфічна выпадковага аднаразовага state. Proxy, які дынамічна рэгіструе кліентаў, павінен атрымаць згоду для кожнага кліента да перанакіравання на старонні сервер. Прывяжыце згоду да client ID і запытаных scopes. Агульная cookie «праграма ўжо ўхвалена» недастатковая і можа стварыць confused deputy.
Лічыце discovery уваходам ад сервера, а не даверанай канфігурацыяй. Дазваляйце толькі схемы і хосты з allowlist, адхіляйце javascript:, data: і file:. Для абароны ад SSRF блакуйце private, loopback, link-local і cloud-metadata дыяпазоны, правярайце кожны redirect і выкарыстоўвайце egress-проксі. Не адкрывайце URL праз shell. Ін’екцыя можа паспрабаваць скарыстаць любы з гэтых шляхоў.
Прымяняйце паступовыя scopes. Пачніце з выяўлення і чытання, запытвайце дакладны дадатковы scope толькі для патрэбнай аперацыі і запісвайце запытаную ды выдадзеную падмноства з correlation ID. Пазбягайце *, all і агульнага адміністрацыйнага scope. Claims не замяняюць аўтарызацыю сервера для кожнага інструмента і аргумента. Кароткажывучыя токены, абароненае сховішча, ротацыя refresh token для публічных кліентаў і асцярожныя журналы зніжаюць шкоду ад крадзяжу.
Лакальны MCP-сервер мае іншую мяжу. Працэс можа мець прывілеі кліента, чытаць файлы, карыстацца сеткай і запускаць каманды. Пакажыце поўную каманду запуску і аргументы да падключэння. Аддавайце перавагу stdio або абароненаму лакальнаму IPC замест HTTP без аўтэнтыфікацыі. Запускайце працэс у sandbox або кантэйнеры з мінімальнымі правамі на файлы, сетку і працэсы, а дадатковыя каталогі і адрасы дазваляйце відавочна.
Шматузроўневая абарона
Найменшыя прывілеі абмяжоўваюць радыус паражэння. Дайце кожнаму агенту толькі інструменты аднаго сцэнарыя. Раздзяліце чытанне, падрыхтоўку, пацверджанне і фіксацыю. Выкарыстоўвайце кароткажывучыя ўліковыя даныя для аперацыі замест пастаяннага токена карыстальніка. Правярайце аўтарызацыю падчас выканання, бо план мадэлі, сесія, апісанне інструмента або рэсурс маглі змяніцца.
Брама пацверджання павінна быць сапраўднай праверкай палітыкі, а не дэкаратыўным дыялогам. Патрабуйце яе для адпраўкі, выдалення, публікацыі, плацяжу, змены правоў, разгортвання, доступу да новага класу даных або новага адрасата. Паказвайце дакладнае дзеянне, аргументы, асобу, мэту, палі даных і чаканы эфект, а не толькі рэзюмэ мадэлі. Пасля адабрэння пералічыце preview і прывяжыце згоду да хэшу аперацыі, каб наступны крок не падмяніў аргументы. Абмяжоўвайце маларызыкоўныя дзеянні, але не прывучайце правяральнікаў ухваляць незразумелыя вокны.
Ізаляцыя абмяжоўвае тое, чаго можа дасягнуць паспяховая ін’екцыя. Раздзяляйце tenants, сесіі і сховішчы памяці. Агент браўзінгу не павінен мець прыватных уліковых даных. Для coding-агента выкарыстоўвайце вузкую рабочую вобласць, забараніце сетку па змаўчанні і дайце асобную identity для ўстаноўкі пакетаў. Спалучайце ізаляцыю працэсу, файлаў, сеткі і браўзера. Кантэйнер сам па сабе не з’яўляецца палітыкай: правярайце mounts, сокеты, identity, egress і шляхі выхаду.
Паходжанне кантэнту робіць рашэнні правяральнымі. Дадавайце крыніцу, аўтара, час атрымання, стан цэласнасці і клас даверу да кожнага дакумента, апісання інструмента і выніку. Захоўвайце іх падчас падсумавання і перадачы паміж агентамі. Паказвайце знешні кантэнт як даныя з бачнай мяжой і пазнакай «не інструкцыя». Пазнака дапамагае мадэлі, але правы павінен прымушаць код. Выдаляйце або нармалізуйце нябачныя сімвалы на межах уводу і адлюстравання, разумеючы, што іншыя атакі застануцца магчымымі.
Правярайце вывад давераным кодам: строгімі схемамі, allowlist інструментаў, тыпізаванымі аргументамі, праверкамі URL і шляхоў, лімітамі памеру і частаты і аўтаматам станаў для кожнага працэсу. Не ператварайце меркаванне другой мадэлі пра бяспеку ў аўтарызацыю. Крытык можа адзначыць падазроны крок, але канчатковае рашэнне павінна быць дэтэрмінаваным. Запісвайце prompt, крыніцы, версіі метаданых, аргументы, рашэнні палітыкі, пацверджанні і адказ без сырых сакрэтаў.
Адвэрсарыяльная ацэнка і эксплуатацыя
Ацэньвайце ўвесь цыкл агента, а не толькі чатавую prompt. Стварыце выпадкі прамога override, схаванага HTML, цытаванага ліста, атручанага тэксту рэпазіторыя, шкоднага апісання MCP, выніку, які просіць другі выклік, міжсесійнага запісу памяці, шматмоўнага і кадзіраванага payload, нябачных сімвалаў, SSRF-метаданых, няправільнай аўдыторыі токена і падмены аргументаў пасля пацверджання. Дадавайце добрасумленны кантэнт, падобны на атаку, каб разам вымяраць ілжывыя спрацоўванні і выкананне задачы.
Тэстуйце адаптыўнага нападніка, які ведае вашы класіфікатары, пазнакі, схемы і правілы пацверджання. Змяняйце фармулёўкі, мадальнасць, парадак інструментаў, час і мэты даных. Статычны benchmark можа паказаць высокі вынік, хоць нападнік знойдзе іншы шлях. Вымярайце поспех атак, несанкцыянаваныя выклікі, адчувальныя байты, што дайшлі да sink, павышэнні scopes, дакладнасць пацверджанняў, час выяўлення і адклікання доступу. Захоўвайце рэгрэсійныя выпадкі пасля кожнай змены мадэлі, prompt, сервера, палітыкі або залежнасці. Працэс можна апісаць у кіраўніцтве па ацэнцы AI-агентаў.
Параўноўвайце архітэктуру з production AI agent architecture. Дэталі OAuth ёсць у MCP server TypeScript with OAuth. Гэтыя ўнутраныя матэрыялы не замяняюць мадэляванне канкрэтнага асяроддзя.
Чэкліст інцыдэнту
Пры падазрэнні на ін’екцыю спыніце паток і адключыце найменшую магчымасць, дастатковую для стрымлівання. Захавайце prompt, крыніцу, паходжанне, апісанне і версію інструмента, аргументы, метаданыя токена без яго значэння, рашэнні палітыкі, пацверджанні, адрасы і час. Вызначце шлях як прамы, ускосны, інструментальны або пастаянны праз памяць. Шукайце той самы payload у іншых tenants, індэксах, чэргах, журналах і перадачах паміж агентамі.
Адклічце і замяніце ўліковыя даныя, якія маглі трапіць у кантэкст або журналы, анулюйце сесіі і абнавіце refresh token, калі трэба. Заблакуйце адрас і закрануты MCP-сервер. Праверце наступныя API на несанкцыянаваныя чытанні, запісы, паведамленні і OAuth grants. Параўнайце выкананыя аргументы з preview, які чалавек убачыў і ўхваліў.
Пасля стрымлівання выдаліце атручаныя запісы памяці і пошуку, аднавіце давераныя метаданыя і дадайце шлях атакі ў рэгрэсійныя тэсты. Зафіксуйце, што ўбачыла мадэль, што дазволіла палітыка, што ўхваліў чалавек і які кантроль не спрацаваў. Паведаміце адказным за інцыдэнт і прыватнасць, калі даныя перасеклі мяжу. Тое, што класіфікатар пазней распазнаў тэкст, не робіць падзею бяскрыўднай.
Чаго абарона не можа абяцаць
Prompt injection застаецца праблемай, якая развіваецца, бо сучасныя мадэлі не ўсталёўваюць фармальнага падзелу паміж інструкцыямі і данымі. Навучанне, класіфікатары, раздзяляльнікі, паходжанне, схемы вываду і праверка чалавека зніжаюць рызыку, але адаптыўны нападнік можа змяніць словы, кадаванне, парадак або мадальнасць. Чалавечае пацверджанне можа не спрацаваць праз стомленасць або зманлівы preview. Няправільна наладжаны sandbox і легітымны зафіксаваны пакет таксама могуць быць небяспечнымі.
Нельга сумленна сцвярджаць, што агент неўразлівы. Можна сказаць, што вызначаны працоўны паток мае выразныя межы даверу, мінімальныя магчымасці, дэтэрмінаваныя праверкі, назіраныя рашэнні, пратэставаныя адмовы і падрыхтаваны адказ. Пераглядайце гэтыя дапушчэнні пасля дадання MCP-сервера, інструмента, памяці, мадэлі, крыніцы даных або выходнага канала. Гэта інжынернае кіраўніцтва, а не сертыфікацыя і не аўдыт бяспекі.
Крыніцы
- OWASP GenAI LLM Top 10 2026
- Спецыфікацыя аўтарызацыі MCP
- Практыкі бяспекі MCP
- OpenAI: Designing AI agents to resist prompt injection
- OpenAI: Understanding prompt injections
- Anthropic: Trustworthy agents in practice
- Google Cloud: AI security and safety for MCP servers
- Microsoft: Protecting against prompt injection attacks