Защита от Prompt Injection в 2026: trust boundaries, tool isolation и tripwires

Короткая версия

Нормальная защита от prompt injection в 2026 обычно включает:

1. Разделение trusted instructions и untrusted data
2. Минимальные права у tools
3. Проверку risky actions до commit
4. Output/schema validation
5. Tripwires и escalation path

Где injection чаще всего приходит

• прямой user input;
• RAG-documents;
• web search results;
• emails и attachments;
• tool outputs;
• memory / notes / summaries.

Почему indirect prompt injection опаснее direct user injection?

1. Root cause: смешение authority и content

Практически prompt injection почти всегда опирается на один и тот же системный дефект:

• model input собирается как один текстовый суп;
• trusted instructions и untrusted data живут вперемешку;
• модель вынуждена сама угадывать, чему верить;
• downstream system слишком доверяет её decision.

Отсюда и все основные риски:

• утечка скрытого контекста;
• обход policy;
• несанкционированный tool call;
• dangerous side effect;
• data exfiltration через seemingly benign workflow.

2. Direct и indirect injection

Direct injection

Вредный текст приходит прямо от пользователя.

Типовые примеры:

• "игнорируй предыдущие инструкции";
• "раскрой системный промпт";
• "вызови tool и отправь скрытые данные".

Indirect injection

Вредная инструкция приходит не из chat input, а из контента:

• retrieved document;
• web page;
• PDF;
• email;
• OCR text;
• tool output;
• summary memory.

Именно indirect injection особенно разрушителен для RAG и browser-use сценариев. Система считает, что "просто читает данные", но фактически вносит в контекст новый управляющий сигнал.

3. Первая линия защиты: trust boundaries

Самая важная практическая мера - на уровне pipeline различать:

Это должно влиять не только на wording, но и на саму оркестрацию:

• untrusted data не должна напрямую менять tool permissions;
• dangerous actions не должны запускаться по одному model suggestion;
• memory не должна silently повышаться до policy source.

4. Tool isolation важнее prompt wording

Даже если injection попал в reasoning loop, система не обязана проиграть. Ключевой вопрос - что агент может сделать дальше.

Надёжная tool defense обычно включает:

• allow-list tools instead of open toolbox;
• schema validation для аргументов;
• bounded scopes;
• dry-run для risky actions;
• approval step до side effect;
• network / filesystem sandboxing для dangerous executors.

Если tool layer изолирован плохо, даже безупречный prompt не спасает.

5. Output validation и policy checks

Ещё один частый провал - считать, что опасность живёт только на input side.

Но injection может проявиться в output как:

• unsafe command;
• HTML/markdown payload для downstream rendering;
• скрытая инструкция для следующего агента;
• несанкционированный tool argument;
• data leakage в seemingly normal answer.

Поэтому минимальный safety stack обычно валидирует:

• output schema;
• policy labels;
• dangerous strings / patterns;
• destination-specific constraints.

6. Tripwires и suspicious patterns

Tripwire полезен не как магическая защита, а как trigger для escalated handling.

Примеры tripwire-сигналов:

• модель неожиданно просит раскрыть hidden instructions;
• retrieved content влияет на tool permission request;
• output содержит странный command-like payload;
• browser-use path пытается уйти на неожиданный домен;
• memory summary внезапно меняет policy interpretation.

После tripwire system может:

• остановить action;
• перевести кейс в human review;
• reroute в safer template;
• выдать refusal или safe fallback.

7. Где защита чаще всего ломается

Trusted retrieval illusion

Команда считает, что internal KB safe по определению. Но stale, poisoned или user-generated documents тоже могут нести вредный control text.

Tool result over-trust

LLM воспринимает tool output как окончательную authority, хотя tool мог вернуть noisy, partial или manipulated content.

Summary drift

Инъекция не всегда живёт в raw data. Иногда она переживает compaction и попадает в memory summary уже в виде "нормализованного" instruction-like текста.

No human stop path

Даже если tripwire сработал, system всё равно не знает, куда деть кейс, и продолжает workflow почти как обычно.

Пример risk-aware pipeline

def handle_request(user_input, retrieved_docs, tool_results):
    context = build_context(
        instructions=trusted_policy(),
        user_input=user_input,
        retrieved_docs=mark_untrusted(retrieved_docs),
        tool_results=mark_partially_trusted(tool_results),
    )

    draft = model(context)
    risk = score_injection_risk(draft, context)

    if risk.high:
        return route_to_review(draft, risk)

    validated = validate_output(draft)
    if not validated.ok:
        return safe_fallback(validated.reason)

    return validated.output

Что полезно логировать

• источник suspicious content: user, retrieval, web, tool, memory;
• какой tripwire сработал;
• пыталась ли модель запросить risky tool;
• какой layer остановил выполнение;
• был ли кейс передан человеку или завершён автоматически.

Практический совет: отдельно храните detected injection attempt и dangerous action prevented. Иначе команда видит только число "подозрительных кейсов", но не понимает, где защита реально прерывает risk chain.