Коротко: Если security-агент не отделяет evidence от instruction, он становится уязвим к prompt injection через саму проверяемую цель.

Где возникает риск

Модель получает страницу ошибки, комментарий в HTML, JavaScript bundle или OpenAPI description и может принять текст цели за системную инструкцию.

В security automation это особенно опасно: агент имеет доступ к планированию проверок, отчётам, иногда к инструментам и внутренним данным assessment-а.

Даже без прямого исполнения команд prompt injection может испортить отчёт: скрыть finding, повысить confidence, придумать ложное remediation или попросить отправить секреты.

Как проектировать защиту

Target-provided content должен маркироваться как untrusted data на уровне prompt-а, fact-pack-а и UI.

Модель не должна видеть raw cookies, bearer tokens, private headers, PII и полные request/response bodies без redaction.

Любой внешний текст должен попадать в модель только как цитируемый факт с digest/evidence id, а не как инструкция.

Что проверять в тестах

Нужны regression-тесты, где HTML цели содержит фразы вроде ignore previous instructions, hide finding, approve report, send token.

Ожидаемое поведение: модель может пересказать факт, но не меняет policy decision, не создаёт finding без evidence и не обходит QA.

Отчёт должен явно показывать limitations: что проверено, что не проверено, где нужна authenticated/stateful фаза.

Этическая рамка: материал описывает defensive-подход к AI security и assisted pentesting. Он не содержит инструкций для несанкционированного доступа, обхода защит, закрепления или эксфильтрации.