AI-агенты: security overlay

Версия: 1.0 · Обновлено: 2026-05-28 · Теги: AI-агенты, безопасность, инструменты, память, согласование, аудит, prompt injection · Tier: 1-4

TL;DR. Дополнение по безопасности поверх базового AI-стандарта: модель угроз для агентов, граница действий инструментов, модель согласования, требования к памяти, изоляция коннекторов, защита от prompt injection через недоверенный контент и список блокирующих условий перед промом.

1. Модель угроз агентного сценария

Базовая модель угроз AI остаётся (OWASP LLM Top 10, MITRE ATLAS, STRIDE-AI). Агентные сценарии добавляют поверхности атак: инструменты, коннекторы, память, передача управления.

flowchart TB
    subgraph CORE[Базовый AI-сценарий]
      C1[Prompt injection]
      C2[Data exfiltration]
      C3[Jailbreak]
    end
    subgraph TOOLS[Tool surface]
      T1[Tool poisoning]
      T2[Unauthorized action]
      T3[Scope escalation]
    end
    subgraph CONN[Connector surface]
      K1[Stale credentials]
      K2[Cross-tenant leak]
      K3[Quota abuse]
    end
    subgraph MEM[Memory surface]
      M1[Memory poisoning]
      M2[Cross-session leak]
      M3[Retention violation]
    end
    subgraph HANDOFF[Handoff surface]
      H1[Approval bypass]
      H2[Trust boundary<br/>break]
    end

    AGENT((AI-агент)):::core --> CORE & TOOLS & CONN & MEM & HANDOFF

    classDef core fill:#f59e0b,stroke:#d97706,color:#1b1d22
    classDef threat fill:#7f1d1d,stroke:#ef4444,color:#fecaca
    class C1,C2,C3,T1,T2,T3,K1,K2,K3,M1,M2,M3,H1,H2 threat

[!danger] Самая опасная связка: prompt injection в недоверенном контенте → tool-call от имени агента → действие через коннектор с устаревшими полномочиями. Каждое звено защищается отдельно; защита только на входе не работает.

2. Граница действий инструмента

Для каждого инструмента в реестре сценария фиксируется:

Атрибут	Назначение
`name` / `version`	Инструмент и его версия
`purpose`	Для чего используется в этом сценарии
`scope`	Конкретный объект / namespace / repo / database
`read_or_write`	Только чтение или есть запись
`rate_limit`	Лимит вызовов в окне времени
`cost_limit`	Лимит токенов / API-расходов
`idempotency`	Идемпотентность вызова и обработка повторов
`approval_required`	Список действий, требующих явного согласования

[!warn] Если у инструмента нет идемпотентности — он не должен запускаться без согласования. Иначе модель ловит ошибку, повторяет вызов и удваивает действие.

3. Модель согласования

Действия делятся на три уровня:

Уровень	Когда применяется	Подтверждение
Auto	Утверждённые read-only / низкорисковые write с идемпотентностью	Журнал аудита, без подтверждения
Approve	Запись, отправка, изменение в чувствительных системах	Подтверждение оператора с записью времени и идентичности
Dual-approve	Финансовые операции, рассылки клиентам, изменения compliance-данных	Подтверждение двумя независимыми операторами

Записи согласования следуют схеме agent-approval-record.schema.json (пример).

[!info] Подтверждение действия должно связываться с конкретным runtime-событием (по action_id), а не быть общим разрешением «запускать агент». Иначе устаревшие подтверждения переиспользуются.

4. Память и состояние

Тип памяти	Когда допустима	Требования
Краткосрочная (в рамках одного запроса)	По умолчанию	Без особых требований
Сессионная (несколько шагов одного диалога)	Если нужно для UX	Срок жизни, явное очищение, без записи PII
Долгосрочная (между сессиями / пользователями)	Только по обоснованию	Назначение, срок хранения, политика удаления, выявление отравления, аудит
Cross-user общая	Запрещено по умолчанию	Требует исключения, изоляция по тенанту, журнал доступа

Шаблон управления памятью — agent-memory-governance-template.md.

[!ru] Память агента, содержащая ПДн, попадает под действие 152-ФЗ: требуются основания обработки, срок хранения, политика удаления, журнал доступа. Назначьте оператора ПДн и зафиксируйте политику в реестре.

5. Изоляция коннекторов

flowchart LR
    A[Агент<br/>runtime identity] -->|service account| B[Connector<br/>card]
    B --> C{Изоляция}
    C -->|namespace| N[K8s namespace<br/>+ NetworkPolicy]
    C -->|tenant| T[Отдельный tenant<br/>в SaaS]
    C -->|account| AC[Отдельный субаккаунт<br/>cloud / DB]
    B --> Q[Quota /<br/>rate-limit]
    B --> AUD[Audit log<br/>каждый вызов]

    classDef sec fill:#10b981,stroke:#059669,color:#fff
    classDef sep fill:#a78bfa,stroke:#7c3aed,color:#fff
    class A,B sec
    class N,T,AC,Q,AUD sep

Каждый коннектор оформляется карточкой (agent-connector-card-template.md) с разделами: владелец, тип доступа, сервисная учётная запись, область, лимиты, условия изоляции, план карантина.

6. Защита от недоверенного контента

Когда агент потребляет внешний контент (веб-страница, файл от пользователя, чужой документ через коннектор), этот контент никогда не доверяется как инструкция.

Меры:

разделение каналов: system / user / tool_output имеют разные уровни доверия;
санитизация: вырезание prompt-маркеров (### system, <instructions>, blockquote с командами);
ограничение действий: read-only режим на ответы из недоверенных источников;
защита от exfiltration через URL: проверка outgoing URL по allow-list;
detection: проверка ответа на наличие токенов инъекции, экспортов секретов, попыток обхода согласования.

[!warn] «Игнорируй предыдущие инструкции» — это самая известная инъекция. Реальные атаки выглядят сложнее: спрятаны в комментариях HTML, в alt-тексте, в metadata PDF, в Unicode-zero-width-символах.

7. Аудит исполнения

Все события агента сериализуются по схеме agent-runtime-events.schema.json и поступают в SIEM. Минимум:

Событие	Что фиксируется
`agent.start` / `agent.stop`	id, версия, identity, причина
`tool.call`	id действия, инструмент, область, аргументы (без секретов), результат
`tool.deny`	причина отказа: политика, согласование, лимит
`approval.granted` / `approval.denied`	ссылка на действие, кто, когда, основание
`memory.write` / `memory.delete`	назначение, срок хранения, фрагмент (с PII-маркировкой)
`handoff`	from, to, причина, контекст передачи
`policy.violation`	какая мера нарушена, дальнейшее действие (suspend / quarantine)

Иллюстративные правила Prometheus — prometheus-agent-alerts.yaml. SIEM-запросы — siem-agent-queries.txt.

8. Блокирующие условия перед промом

Промышленная эксплуатация запрещена, если хотя бы одно условие выполнено:

Нет реестра инструментов с областью действия;
Нет записи делегированных полномочий со сроком действия;
Нет модели согласования для write-действий;
Нет журнала аудита, попадающего в SIEM в течение 5 минут;
Нет пути аварийного отключения с замером времени;
Нет защитных проверок на prompt injection / tool misuse / approval bypass;
Нет владельца агента и владельца коннекторов;
Нет плана карантина коннектора;
Класс D без явно утверждённого исключения.

[!ok] Эти девять пунктов — минимальный «hard gate». Если по любому из них статус «нет» — релиз останавливается, без обсуждений.

9. Связь с другими документами

Поверх базового стандарта безопасности (DLP, IAM, OWASP LLM Top 10) — не подменяет его.
Опирается на класс агента из Operating Overlay.
Минимальный набор защитных проверок — agent-security-evals-minimal.md.
При нарушении — путь действий описан в Incident Playbook.
Финальный rubeж — Production Readiness Checklist.

#AI-агенты: security overlay

#1. Модель угроз агентного сценария

#2. Граница действий инструмента

#3. Модель согласования

#4. Память и состояние

#5. Изоляция коннекторов

#6. Защита от недоверенного контента

#7. Аудит исполнения

#8. Блокирующие условия перед промом

#9. Связь с другими документами

Упоминается в (1)