---

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.

Сравнение:

Для инфраструктурного 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:

Это бинарные протоколы, не 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 спроектирован как универсальный фильтр:

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

---

SENTINEL Academy

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

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

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

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

---

Цифры

После 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.