Control & Trust·production

IAM.Secure

Инспекция AI-трафика, DLP-политики, prompt-injection guard и аудит.

Landing Приложение API endpoint ↗

Ключевые возможности

  • Inline inspection запросов и ответов
  • DLP, masking, block и route policy actions
  • Аудит решений и security evidence

Пошаговые инструкции

Сценарии

Начинайте с результата: откройте сценарий, подготовьте prerequisites, выполните шаги и проверьте признаки успеха.

01 Создать DLP-политику для AI-трафикаЧувствительные данные маскируются или блокируются до передачи модели.
Для кого
Специалист ИБ
Результат
Чувствительные данные маскируются или блокируются до передачи модели.

Перед началом

  • Tenant и traffic source
  • Список типов данных
  • Согласованное действие mask или block

Шаги

  1. Создайте policy setВ Policies выберите tenant, channels и направление request/response.
  2. Добавьте детекторыВключите нужные PII/credential classifiers и настройте исключения на тестовых данных.
  3. Назначьте действиеДля каждого severity задайте allow, mask, block или route-to-local.
  4. Запустите simulationПроверьте безопасные и опасные примеры до включения inline enforcement.
Как проверить результат

Simulation и live audit показывают один rule id, ожидаемое действие и redacted evidence.

Если не работает

При ложных срабатываниях сначала уточняйте scope и exceptions, а не отключайте policy целиком.

02 Расследовать блокировку или prompt-injection событиеАналитик понимает источник, правило, решение и связанные события без раскрытия секретов.
Для кого
SOC analyst
Результат
Аналитик понимает источник, правило, решение и связанные события без раскрытия секретов.

Перед началом

  • Correlation id или временной интервал
  • Доступ к Incident и Audit
  • Tenant scope

Шаги

  1. Найдите событиеОтфильтруйте Incident по tenant, action, severity и correlation id.
  2. Откройте evidenceСверьте classifier, matched fragment hash, policy version и redaction state.
  3. Проследите цепочкуПерейдите к Router decision и исходному product event по correlation id.
  4. Зафиксируйте выводДобавьте disposition, owner и remediation; не копируйте исходный секрет в комментарий.
Как проверить результат

Incident закрыт с owner, disposition и ссылками на связанные audit records.

Если не работает

Если цепочка обрывается, проверьте передачу correlation id на входе Router и в source product.

Разделы приложения

Открыть подробное руководство

Для каждого экрана приложения подготовлена отдельная страница с кнопками, безопасными примерами значений, CLI/API и восстановлением по кодам ошибок.

Открыть подробное руководство →

Роль в экосистеме

IAM.Secure проверяет входящий и исходящий AI-трафик до того, как данные попадут в модель или downstream tool. Результат инспекции — структурированное решение: allow, mask, route или block с объяснимым policy reason.

Основной сценарий

  1. Клиент передаёт текст или URL в dry-run/inline inspection.
  2. T0-правила выполняют быстрые детерминированные проверки.
  3. Классификаторы оценивают DLP, injection, abuse и topic policy.
  4. Policy engine объединяет сигналы и выбирает action.
  5. Клиент получает verdict и безопасный audit reference.

Inline-режим используется в реальном трафике, dry-run — для предварительной проверки политики и демонстрации без обращения к LLM.

Policy actions

ActionНазначение
allowпродолжить обработку без преобразования
maskудалить или заменить чувствительные фрагменты
routeперенаправить запрос в согласованный периметр
blockзавершить запрос до downstream-вызова

Интеграции

Secure работает перед IAM.Router или конкретным tool API. Identity context приходит из IAM.Identity, а IAM.Core может требовать security verdict перед capability invocation.

Данные и аудит

Сырые секреты и PII не должны попадать в публичные логи. Audit хранит verdict, policy/version, request reference и применённые действия. Маскирование должно быть воспроизводимым, а блокировка — различимой от provider failure.

Эксплуатация

Контролируйте latency каждого слоя, долю false positive/negative, версию policy, готовность классификаторов и fallback posture. При недоступности обязательного security-компонента защищённый маршрут должен завершаться fail-closed.

Граница ответственности

Secure не является заменой tenant authorization, сетевой изоляции или шифрования хранения. Он защищает AI/content flow и дополняет, а не отменяет обычные security controls.