AI Security Gold Rush

Сейчас каждый делает решения для безопасности AI.

Последний год я анализировал разные решения и вот к какому выводу я пришёл:

Они все поразительно похожи:

  • Написаны на Python

  • ML-классификаторы для детекции

  • REST API обёртка

  • 50-200мс задержка

  • Десятки зависимостей

  • Облачный деплой

И вот неудобная правда:

Они сами становятся векторами атак.

Ирония Python-решений для безопасности

Когда ваш слой безопасности:

  • Имеет 50+ зависимостей (каждая — потенциальная CVE)

  • Добавляет 50-200мс к каждому запросу (приглашение для DDoS)

  • Работает на интерпретируемом языке (проблемы с памятью)

  • Требует облачного подключения (single point of failure)

...защита получается, но с компромиссами: больше latency, больше зависимостей, больше точек отказа.

Признаюсь честно: я начинал точно так же. SENTINEL — это 80K LOC, включая Python-движок Brain с 201 детектором, Strike для red team, Framework для интеграции. Всё это работает и продолжает развиваться.

Но в какой-то момент стало ясно: нужен ещё один слой. Не вместо существующих решений — а в дополнение. Быстрый, минимальный, без зависимостей. Слой, который можно поставить в любую точку цепочки: перед LLM, между RAG и моделью, между агентами, перед инструментами.

Так появился Shield.

Другая ментальная модель

Я задал простой вопрос:

Что если применить принципы сетевой безопасности к AI?

У сетей есть файрволы. DMZ. Зонированная архитектура. Cisco IOS команды. Hardware-ускоренная фильтрация.

У LLM есть... regex?

Разрыв был очевиден.

И я построил SENTINEL Shield — слой AI-безопасности, спроектированный как сетевая инфраструктура:

  • Чистый C — не Python, не Rust, не Go. C.

  • Ноль зависимостей — нечего сканировать на CVE

  • Субмиллисекундная задержка — быстрее вашей базы данных

  • CLI в стиле Cisco — знаком каждому сетевику

  • Зонирование — proper trust boundaries

  • Протоколы — enterprise-паттерны интеграции

Почему чистый C?

Выбор языка был осознанным. C требует больше внимания к деталям, но взамен даёт полный контроль над производительностью и минимальный footprint.

Сравнение:

Параметр

Shield (C)

Python-инструмент

Зависимости

0

50-200

Задержка

< 1мс

50-200мс

Память

50MB

500MB+

Пропускная способность

10K req/s/ядро

50 req/s

Поверхность атаки

Минимальная

Большая

Размер контейнера

20MB

500MB+

Для инфраструктурного security-компонента, через который проходит каждый запрос, эти различия критичны.

23,113 строк C. Статический анализ на каждом коммите. Все аллокации памяти отслеживаются. Bounds-checking на строковых операциях.

Результат — слой безопасности с предсказуемой производительностью и минимальной поверхностью атаки.

Архитектура: 8-уровневая модель

Shield реализует полноценный security-стек:

┌─────────────────────────────────────────────────────────┐
│  Layer 8: API (REST, gRPC, FFI)                         │
│  Layer 7: CLI (194 команды в стиле Cisco)               │
│  Layer 6: Guards (LLM, RAG, Agent, Tool, MCP, API)      │
│  Layer 5: Zone Management (Trust boundaries)            │
│  Layer 4: Rule Engine (ACL, Policies)                   │
│  Layer 3: Analysis (Pattern, Semantic, ML)              │
│  Layer 2: Protocols (20 enterprise-протоколов)          │
│  Layer 1: Core (Memory pools, Threading)                │
└─────────────────────────────────────────────────────────┘

Это не обёртка вокруг ML-модели. Это инфраструктура.

Шесть Guards

Вместо одного монолитного классификатора, Shield имеет специализированные guards:

1. LLM Guard

Защищает взаимодействие с языковыми моделями:

  • Детекция prompt injection

  • Паттерн-матчинг jailbreak

  • Предотвращение token abuse

  • Блокировка exfiltration

2. RAG Guard

Защищает retrieval-augmented generation:

  • Детекция poisoning документов

  • Верификация provenance

  • Проверка целостности контекста

3. Agent Guard

Защищает автономных AI-агентов:

  • Детекция бесконечных циклов

  • Предотвращение privilege escalation

  • Лимиты глубины chain

  • Детекция misuse инструментов

4. Tool Guard

Защищает доступ к внешним инструментам:

  • Валидация scope

  • Rate limiting

  • Блокировка опасных операций

5. MCP Guard

Защищает Model Context Protocol:

  • Валидация схемы

  • Верификация capability

  • Предотвращение resource enumeration

6. API Guard

Защищает API endpoints:

  • Аутентификация

  • Rate limiting

  • Валидация входных данных

Каждый guard фокусируется на одной области. Вместе они покрывают всю поверхность атаки.

20 Enterprise-протоколов

Реальный enterprise-деплой требует больше чем HTTP:

Категория

Протоколы

Назначение

Discovery

ZDP, ZRP, ZHP

Управление зонами, health

Traffic

STP, SPP, SQP, SRP

Защищённый поток данных

Analytics

SAF, STT, SEM, SLA

Метрики, телеметрия

HA

SHSP, SSRP, SMRP

Кластеризация, failover

Integration

SBP, SGP, SIEM

Внешние системы

Security

STLS, SZAA, SSigP

TLS, auth, сигнатуры

Это бинарные протоколы, не JSON-over-HTTP. Они спроектированы для:

  • Низкой задержки

  • Высокой пропускной способности

  • Надёжности

  • Enterprise-фич (HA, SIEM и т.д.)

CLI в стиле Cisco

Сетевые инженеры не учат новый DSL для каждого инструмента. Security-операторы тоже не должны:

Shield# show zones
Zone        Type    Trust   State
--------    ----    -----   -----
external    api     1       active
internal    llm     10      active
dmz         rag     5       active

Shield# configure terminal
Shield(config)# class-map match-any THREATS
Shield(config-cmap)# match injection
Shield(config-cmap)# match jailbreak
Shield(config-cmap)# match exfiltration
Shield(config-cmap)# exit

Shield(config)# policy-map SECURITY-POLICY
Shield(config-pmap)# class THREATS
Shield(config-pmap-c)# block
Shield(config-pmap-c)# log
Shield(config-pmap-c)# alert
Shield(config-pmap-c)# exit
Shield(config-pmap)# exit

Shield(config)# zone external
Shield(config-zone)# service-policy input SECURITY-POLICY
Shield(config-zone)# exit

Shield(config)# end
Shield# write memory
Building configuration...
[OK]

194 команды. Знакомый синтаксис. Нулевая кривая обучения для сетевых команд.

Универсальная интеграция

Shield можно поместить в любую точку вашей AI-цепочки. Вот 6 примеров с реальным API:

1. Перед OpenAI/Anthropic API

Пользователь → [Shield] → OpenAI API → [Shield] → Ответ

C API — встраивание в приложение:

Основной паттерн работы с Shield на C состоит из трёх шагов:

  1. Инициализация контекста и загрузка конфигурации

  2. Вызов shield_evaluate() с указанием зоны и направления трафика

  3. Проверка результата и принятие решения (block/allow)

#include "sentinel_shield.h"

/* Шаг 1: Инициализация. Создаём контекст и загружаем правила */
shield_context_t ctx;
shield_init(&ctx);
shield_load_config(&ctx, "config.json");

/* Шаг 2: Проверка входящего запроса.
   Аргументы: контекст, текст, длина, зона, направление, результат */
evaluation_result_t result;
shield_evaluate(&ctx, user_prompt, strlen(user_prompt),
                "external", DIRECTION_INBOUND, &result);

/* Шаг 3: Принятие решения на основе результата */
if (result.action == ACTION_BLOCK) {
    printf("Blocked: %s\n", result.reason);
    return;
}

/* Если проверка пройдена — вызываем LLM */
char *llm_response = call_openai(user_prompt);

/* Шаг 4: Фильтрация ответа перед отправкой пользователю */
char filtered[MAX_RESPONSE];
size_t filtered_len;
shield_filter_output(&ctx, llm_response, strlen(llm_response),
                     filtered, &filtered_len);

return filtered;

Важные моменты:

  • shield_evaluate() возвращает структуру с полями action, reason, score

  • Зона "external" означает внешний трафик (от пользователей)

  • DIRECTION_INBOUND — входящий запрос, DIRECTION_OUTBOUND — исходящий ответ

REST API — интеграция без изменения кода:

Если встраивание C-библиотеки невозможно, Shield предоставляет HTTP API. Запрос на эндпоинт /v1/evaluate возвращает JSON с решением. Это позволяет интегрировать Shield в любой язык программирования.

# Отправляем POST-запрос с промптом для анализа
curl -X POST http://localhost:8080/v1/evaluate \
  -H "Content-Type: application/json" \
  -d '{
    "input": "Ignore previous instructions...",
    "zone": "external",
    "direction": "inbound"
  }'

# Пример ответа от Shield:
{
  "action": "block",       # Решение: block, warn, или allow
  "reason": "Prompt injection detected",  # Причина блокировки
  "score": 0.92,           # Уровень угрозы 0.0-1.0
  "latency_us": 450        # Время обработки в микросекундах
}

HTTP код ответа: 200 для allow, 403 для block. Поле latency_us позволяет мониторить производительность.

2. Между RAG и LLM

Query → Vector DB → Retrieved Docs → [Shield] → LLM → Response

Проблема: Документы из векторной базы могут содержать вредоносные инструкции (RAG poisoning). Атакующий может добавить в базу документ с prompt injection, который попадёт в контекст LLM.

Решение: Каждый retrieved документ проходит через Shield перед добавлением в контекст.

/* Проверяем каждый документ из RAG на наличие вредоносного содержимого */
for (int i = 0; i < doc_count; i++) {
    shield_evaluate(&ctx, docs[i].content, docs[i].len,
                    "rag", DIRECTION_INBOUND, &result);

    if (result.action == ACTION_BLOCK) {
        /* Документ содержит подозрительный контент — исключаем из контекста */
        remove_doc(&docs, i);
        log_warn("RAG document %d filtered: %s", i, result.reason);
    }
}

Зона "rag" активирует специализированные правила для детекции poisoning в документах.

3. Между агентом и инструментами

Agent → Tool Request → [Shield] → Tool Execution → [Shield] → Agent

Проблема: AI-агент может попытаться вызвать опасный инструмент (удаление файлов, выполнение команд) под влиянием prompt injection. Это называется tool hijacking.

Решение: Каждый вызов инструмента проходит через Shield. Проверяется как имя инструмента, так и аргументы.

/*
 * Функция-обёртка для проверки tool call перед выполнением.
 * Возвращает SHIELD_OK если вызов безопасен, SHIELD_ERR_BLOCKED если заблокирован.
 */
shield_err_t check_tool_call(const char *tool_name, const char *args) {
    /* Формируем JSON с информацией о вызове */
    char payload[4096];
    snprintf(payload, sizeof(payload),
             "{\"tool\": \"%s\", \"args\": \"%s\"}", tool_name, args);

    /* Проверяем через Shield с зоной "tool" */
    evaluation_result_t result;
    shield_evaluate(&ctx, payload, strlen(payload),
                    "tool", DIRECTION_INBOUND, &result);

    if (result.action == ACTION_BLOCK) {
        return SHIELD_ERR_BLOCKED;  /* Вызов заблокирован */
    }
    return SHIELD_OK;  /* Вызов разрешён */
}

4. В MCP Server/Client

MCP Client → [Shield] → MCP Server → [Shield] → Response

Что такое MCP: Model Context Protocol — стандарт для взаимодействия AI-агентов с внешними инструментами и данными. Всё больше AI-систем его поддерживают.

Проблема: MCP-запросы могут содержать попытки доступа к чувствительным ресурсам (системные файлы, credentials, внутренние API).

Решение: Shield имеет специализированный MCP Guard, который понимает структуру MCP-запросов.

# Пример: агент пытается прочитать /etc/passwd через MCP
curl -X POST http://localhost:8080/v1/mcp/evaluate \
  -H "Content-Type: application/json" \
  -d '{
    "method": "tools/call",
    "params": {"name": "read_file", "arguments": {"path": "/etc/passwd"}}
  }'

# Shield блокирует запрос:
{
  "action": "block",
  "reason": "MCP: Sensitive path access blocked",
  "guard": "mcp"  // Указывает какой Guard сработал
}

MCP Guard проверяет: пути к файлам, URL-адреса, SQL-запросы, shell-команды внутри MCP payload.

5. Multi-Agent Chain

User → Agent1 → [Shield] → Agent2 → [Shield] → Agent3 → Response

C API для проверки между агентами:

// После каждого агента
shield_err_t validate_agent_output(const char *agent_name,
                                    const char *output, size_t len) {
    evaluation_result_t result;
    shield_evaluate(&ctx, output, len, "agent", DIRECTION_INBOUND, &result);

    if (result.action == ACTION_BLOCK) {
        log_warn("Agent %s output blocked: %s", agent_name, result.reason);
        return SHIELD_ERR_CHAIN_INTERRUPTED;
    }

    // Проверка глубины цепочки
    if (ctx->chain_depth > MAX_CHAIN_DEPTH) {
        return SHIELD_ERR_LOOP_DETECTED;
    }

    return SHIELD_OK;
}

6. API Gateway (Kong/NGINX)

Internet → NGINX → [Shield] → Your AI Service

NGINX конфигурация:

location /api/chat {
    # Сначала через Shield
    proxy_pass http://shield:8080/v1/evaluate;

    # Если Shield вернул allow — идём дальше
    error_page 200 = @ai_service;
}

location @ai_service {
    proxy_pass http://ai-service:3000;
}

Docker Compose:

services:
  nginx:
    image: nginx:alpine
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - shield
      - ai-service

  shield:
    image: sentinel/shield:1.2.0
    ports:
      - "8080:8080"
    volumes:
      - ./config.json:/etc/shield/config.json

  ai-service:
    image: your-ai-service

Почему это работает везде

Shield спроектирован как универсальный фильтр:

Свойство

Преимущество

Zero dependencies

Работает в любом окружении

< 1ms latency

Не добавляет заметной задержки

REST API

Интеграция из любого языка

C API (FFI)

Максимальная производительность

CLI

Scripting и automation

Stateless

Горизонтальное масштабирование

Не важно где в цепочке — Shield всегда один и тот же binary с конфигом.

SENTINEL Academy

Я не просто построил инструмент. Я построил учебную программу.

24 модуля обучения:

Уровень

Длительность

Темы

SSA (Associate)

23 часа

Концепции, установка, базовая настройка

SSP (Professional)

90 часов

Guards, протоколы, HA, мониторинг

SSE (Expert)

180 часов

Internals, custom guards, eBPF, плагины

Доступно на русском и английском.

Потому что инструменты безопасности без обучения — это просто ложная уверенность.

Цифры

После 11 спринтов:

  • 23,113 строк C-кода

  • 99 исходных файлов

  • 64 заголовочных файла

  • 20 протоколов

  • 194 CLI-команды

  • 6 специализированных guards

  • 24 модуля Academy

  • 100% покрытие OWASP LLM Top 10

  • 100% покрытие OWASP Agentic AI Top 10

Что дальше

Shield — это фундамент. В roadmap:

  1. Больше guards — Multimodal, vector DB, fine-tuning

  2. Больше протоколов — A2A, расширенный MCP

  3. Hardware-ускорение — DPDK, SmartNIC offload

  4. SENTINEL Guard LLM — AI-модель, натренированная на наших 201 детекторах

Быстрый старт

git clone https://github.com/DmitrL-dev/AISecurity.git
cd AISecurity/sentinel-community/shield
mkdir build && cd build
cmake ..
make -j$(nproc)

./shield-cli
Shield> show version
SENTINEL Shield v1.2.0
Shield>

GitHub: github.com/DmitrL-dev/AISecurity

Заключение

Пространство AI-безопасности переполнено похожими решениями — Python-обёртками вокруг ML-классификаторов, добавляющими задержку и поверхность атаки.

Я выбрал другой путь: относиться к AI-безопасности как к сетевой безопасности. Написать на C. Сделать быстрым. Сделать знакомым. Сделать инфраструктурой.

Результат — SENTINEL Shield. 23К строк C, субмиллисекундная задержка, CLI в стиле Cisco, 20 протоколов, 6 guards.

Поставьте ⭐ на GitHub, если считаете проект полезным.

Буду рад конструктивной критике, предложениям и вопросам — пишите в комментариях или в Telegram. Всегда открыт к диалогу.

Написано соло. Open source. Apache 2.0.