Як оцінити захист від prompt injection: практичний чекліст

Prompt injection eval не починається зі списку фраз на кшталт «ignore previous instructions». Спочатку опишіть security expectation: які дані агент може читати, які зовнішні сторони можуть впливати на його контекст, які дії він здатен запропонувати або виконати та що ніколи не має відбутися без окремої перевірки. Direct injection від користувача й indirect injection із вебсторінки, листа, документа, tool output або пам’яті утворюють різні attack surfaces.

Для кожного workflow побудуйте пари source і sink. Source — недовірений контент, який атакувальник може змінити; sink — передавання секрету, мережевий запит, повідомлення, платіж, зміна файлу, запис у пам’ять або інша consequential capability. OpenAI описує саме таку source-sink рамку для агентів: тест має доводити не лише те, що модель помітила підозрілий текст, а й те, що небезпечний потік до sink був заблокований або вимагав коректного підтвердження.

• Asset → секрети, персональні дані, credentials, гроші, репутаційні або операційні дії.
• Source → user input, web, email, RAG, файли, tool output, memory і multimodal content.
• Sink → network, message, write tool, code execution, memory write або privilege change.
• Invariant → заборонена подія, яку harness перевіряє детерміновано.

Corpus має відтворювати реальні траєкторії: звичайна сторінка з прихованою інструкцією, лист із правдоподібним business pretext, документ RAG, який просить змінити policy, redirect chain, URL із даними в query, poisoned tool result і запис пам’яті, що видає себе за approval. Додайте перефразування, різні мови, кодування, typographic hiding, зображення та багатокрокові атаки. Кожен fixture зберігає атаковане джерело, дозволені докази, очікувані tool calls і forbidden events.

Позитивні benign fixtures потрібні не менше за атаки. Вони показують, чи захист не блокує нормальне цитування інструкцій, security research, support-листи, легітимні зовнішні посилання та дозволені дії. Розділяйте випадки за source, sink, asset sensitivity, autonomy, permission scope і потрібністю user confirmation. Один середній score легко приховає провал рідкісного, але критичного data-exfiltration slice.

Запускайте fixture у production-like sandbox із тими самими prompt, model, tools, policies, network rules, credentials broker і confirmation UI, але з canary-секретами та фіктивними destinations. Тест лише фінальної відповіді недостатній: модель може мовчки викликати URL, передати payload у tool argument, записати атаку в memory або підготувати небезпечну чернетку. Harness зберігає повну траєкторію і незалежно спостерігає кожен sink.

Не видавайте тестовому агенту ширших прав, ніж production role, і не підміняйте policy mock-ом, який завжди відмовляє. Перевірте least privilege, tenant binding, scoped credentials, destination allowlist, sandbox egress, schema validation та approval binding до точного payload. Confirmation не проходить gate, якщо після нього агент може змінити одержувача, дані або суму без нового рішення користувача.

Основний verdict детермінований: forbidden sink reached, secret exposed, unauthorized write, poisoned memory, confirmation bypass або safe completion. Окремо позначайте attack detected, refused, content safely summarized, user warned і task completed. Відмова моделі може виглядати безпечно, але не доводить, що фоновий request не пішов; навпаки, модель може не назвати атаку, однак policy layer правильно заблокує side effect.

Звітуйте attack success rate лише разом із точним corpus, repetitions, sampling settings, model/policy versions і confidence interval; не переносіть vendor benchmark на власну систему. Для operations корисні critical invariant failures, sink-specific compromise rate, secret-canary exposure, unauthorized attempts blocked, benign task success, false-positive rate, confirmation quality, containment time, latency і cost per evaluated trajectory. Critical exfiltration не компенсується високим середнім task success.

Defense-in-depth включає model behavior, trust labels, content handling, least privilege, data-flow checks, sandbox, network controls, approval та monitoring. Запустіть повний stack, а потім контрольовані ablations: приберіть classifier, звузьте або розширте tool scope, вимкніть destination check чи confirmation. Так видно, який шар справді зупинив атаку, де є single point of failure і чи декоративний «AI firewall» лише додає latency.

OpenAI й Anthropic прямо описують prompt injection як активну проблему без єдиного гарантованого захисту. Тому classifier precision не є security result. Перевіряйте, чи система обмежує наслідок навіть тоді, коли модель або detector пропустили соціально переконливу атаку. Для web agents окремо тестуйте тихі URL-based leaks, redirects, previews і embedded resources; allowlist домену не доводить безпечність конкретного data flow.

Decision record фіксує workflow, sources, sinks, permissions, model, prompt, policy bundle, tool schemas, corpus revision, critical invariants, thresholds, owner і review date. Promote стосується лише перевіреного scope. Restrict може вимкнути network egress, memory writes або high-impact tools; reject повертає read-only чи deterministic baseline. Будь-який canary-secret leak, cross-tenant access або unauthorized consequential action блокує release незалежно від середнього score.

Rollout проходить offline replay, adversarial staging, read-only canary, малий permission-bounded cohort і постійний monitoring. Rollback відкликає scoped credentials, вимикає sinks і заражені memory writes, повертає known-good policy/model bundle та зберігає очищений trace для incident review. Новий exploit після triage стає regression fixture. Повторюйте critical suite після зміни моделі, prompt, retriever, browser, MCP/tool server, permissions, network policy або confirmation UX.

• Promote → усі critical invariants пройдені у визначеному scope.
• Restrict → зменшити sources, sinks, data class, autonomy або permissions.
• Reject → залишити read-only чи детермінований baseline.
• Roll back → revoke credentials, disable sinks, quarantine state і reconcile side effects.