FORTRESS-MCP

Zero-Trust шлюз безопасности для выполнения инструментов ИИ-агентов

FORTRESS-MCP — это провайдер-нейтральный шлюз безопасности с моделью zero-trust, предназначенный для контроля того, как ИИ-агенты запрашивают и выполняют MCP-инструменты.

Проект демонстрирует производственный стиль границы безопасности между намерением агента и привилегированным выполнением инструментов.

ИИ-агент может запросить действие, но агент не авторизует и не выполняет привилегированные действия самостоятельно.

Related MCP server: mcp-guardian

1. Зачем нужен FORTRESS-MCP?

Современные ИИ-агенты могут вызывать инструменты, API, файловые системы, базы данных и внешние сервисы. Проблема безопасности больше не сводится только к:

«Может ли модель сгенерировать правильный ответ?»

Она также включает:

«Можно ли доверять модели в принятии решения о том, какие действия ей разрешено выполнять?»

FORTRESS-MCP решает эту проблему, разделяя:

Agent Intent
     ↓
Identity
     ↓
Authentication
     ↓
Authorization
     ↓
Policy Decision
     ↓
Risk Classification
     ↓
Human Confirmation
     ↓
Argument Validation
     ↓
MCP Tool Execution
     ↓
Audit

Таким образом, LLM не является органом безопасности.

2. Цели проекта

FORTRESS-MCP предназначен для демонстрации:

• Выполнение инструментов ИИ-агента с моделью zero-trust.

• Авторизация с минимальными привилегиями.

• Безопасность по принципу «запрещено по умолчанию».

• Детерминированные политические решения.

• Классификация рисков.

• Подтверждение человеком чувствительных действий.

• Выполнение инструментов на основе MCP.

• Сдерживание prompt-инъекций.

• Валидация инструментов и аргументов.

• Безопасное ведение аудиторских журналов.

• Тестирование безопасности API.

• Оценка безопасности агентов.

• Статический анализ безопасности.

• Инженерные практики производственного стиля.

Проект намеренно спроектирован так, чтобы быть:

• ориентированным на индустрию;

• удобным для собеседований;

• впечатляющим для портфолио;

• провайдер-нейтральным;

• технически глубоким;

• достаточно простым для понимания и сопровождения.

3. Основной принцип безопасности

Центральное правило проектирования:

Agent Intent
    ≠
Security Decision
    ≠
Tool Execution

Агент может запросить действие.

FORTRESS решает, разрешено ли действие.

Только после успешного прохождения шлюза безопасности MCP-инструмент может выполниться.

4. Высокоуровневая архитектура

                         ┌──────────────────────┐
                         │      STREAMLIT       │
                         │   SECURITY CENTER    │
                         └──────────┬───────────┘
                                    │
                                    ▼
                         ┌──────────────────────┐
                         │      FORTRESS API    │
                         └──────────┬───────────┘
                                    │
                                    ▼
                 ┌──────────────────────────────────┐
                 │        FORTRESS SECURITY          │
                 │             GATEWAY               │
                 │                                  │
                 │ Identity                         │
                 │ Authentication                   │
                 │ Authorization                    │
                 │ Policy                           │
                 │ Risk                             │
                 │ Confirmation                     │
                 │ Validation                       │
                 │ Audit                            │
                 └───────────────┬──────────────────┘
                                 │
                                 ▼
                         ┌──────────────────┐
                         │   MCP GATEWAY    │
                         └────────┬─────────┘
                                  │
             ┌────────────────────┼────────────────────┐
             │                    │                    │
             ▼                    ▼                    ▼
      calculator_read      weather_lookup       update_record
             │                    │                    │
             │                    ▼                    │
             │              Open-Meteo                 │
             │              Live API                   │
             │                                         │
             └────────────────────┬────────────────────┘
                                  ▼
                              RESULT
                                  │
                                  ▼
                               AUDIT

5. Границы доверия

FORTRESS определяет явные границы доверия.

Агент → FORTRESS

Запросы агента — это недоверенный ввод.

Агент не получает разрешение автоматически только потому, что сгенерировал запрос.

FORTRESS → MCP

Только авторизованные и проверенные запросы могут пересечь границу выполнения.

MCP → Внешний инструмент

Внешнее выполнение контролируется и подлежит аудиту.

Внешние данные → Агент

Внешние данные — это недоверенные данные.

Внешние данные никогда не предоставляют авторизацию.

Подтверждение человеком

Чувствительная авторизация должна исходить от фактического пользовательского интерфейса.

LLM не может подтвердить собственный запрос.

6. Конвейер принятия решений по безопасности

Каждая защищённая операция следует этому концептуальному конвейеру:

1. Receive request
2. Identify requesting agent
3. Authenticate identity
4. Resolve permissions
5. Validate requested tool
6. Validate arguments
7. Evaluate security policy
8. Determine risk
9. Determine confirmation requirement
10. Request external human confirmation if required
11. Re-evaluate authorization
12. Execute MCP tool
13. Record audit event
14. Return result

Точная реализация намеренно детерминирована.

7. Идентичность

Идентичность представляет субъекта, запрашивающего операцию.

Концептуально:

AgentIdentity
├── agent_id
├── role
├── permissions
├── trust_level
└── session_id

Аутентификация отвечает на вопрос:

Кто ты?

Авторизация отвечает на вопрос:

Разрешено ли тебе выполнять это действие?

Это намеренно раздельные концепции.

8. Разрешения

FORTRESS использует намеренно небольшую модель разрешений:

READ
WRITE
SENSITIVE

Этого достаточно для демонстрации минимальных привилегий без внесения излишней сложности корпоративного IAM.

9. Политические решения

Политический слой выдаёт одно из трёх решений:

ALLOW
DENY
REQUIRE_CONFIRMATION

Поведение по умолчанию:

Unknown
    ↓
DENY

Механизм политик — это прикладная логика.

Он не делегируется LLM.

10. Классификация рисков

FORTRESS использует три уровня риска:

LOW
MEDIUM
HIGH

Первоначальное концептуальное сопоставление:

Классификация рисков детерминирована и объяснима.

11. Подтверждение человеком

Операции с высоким риском могут требовать явного подтверждения человеком.

Поток безопасности:

Agent Request
      ↓
FORTRESS
      ↓
HIGH RISK
      ↓
REQUIRE_CONFIRMATION
      ↓
Actual User
      ↓
Confirm / Reject
      ↓
FORTRESS Re-evaluation
      ↓
ALLOW / DENY
      ↓
MCP Execution

Критическое правило безопасности:

LLM не может сгенерировать или имитировать подтверждение пользователя.

12. MCP

MCP обеспечивает стандартизированный слой взаимодействия с инструментами.

FORTRESS окружает MCP границей безопасности.

Концептуально:

Agent
  ↓
FORTRESS Security Gateway
  ↓
MCP
  ↓
Tool

FORTRESS не пытается заменить MCP.

Вместо этого он демонстрирует, как выполнение MCP-инструментов может быть размещено за детерминированным шлюзом безопасности.

13. Первоначальный набор инструментов

Проект намеренно ограничивает первоначальную поверхность инструментов.

calculator_read

Назначение:

• детерминированный локальный расчёт;

• операция чтения с низким риском;

• полезна для базового тестирования авторизации.

weather_lookup

Назначение:

• получение актуальных данных о погоде;

• демонстрация контролируемого доступа к внешнему API;

• демонстрация внешних данных как недоверенного ввода.

update_record

Назначение:

• демонстрация операции записи;

• демонстрация авторизации с более высоким риском;

• демонстрация применения политик.

sensitive_action

Назначение:

• демонстрация чувствительных операций;

• требование явного подтверждения;

• демонстрация путей отказа и подтверждения.

Небольшой набор инструментов — это осознанный выбор.

Проект ставит глубину безопасности выше количества инструментов.

14. API живых данных

FORTRESS использует Open-Meteo в качестве первоначального бесплатного провайдера живых данных для поиска погоды.

Концептуально:

Agent
  ↓
FORTRESS
  ↓
Authorization
  ↓
Argument Validation
  ↓
MCP Weather Tool
  ↓
Open-Meteo
  ↓
Weather Result
  ↓
Audit

Внешний провайдер остаётся заменяемым.

Граница безопасности не зависит от провайдера.

15. Внешние данные недоверенны

Критический принцип проектирования:

External Data
      ≠
Authorization

Ответы о погоде, ответы API, документы и другой внешний контент могут содержать вредоносный текст или текст, похожий на инструкции.

Такой контент не может предоставить разрешение.

Авторизация определяется политикой FORTRESS.

16. Валидация аргументов

Аргументы инструментов проверяются перед выполнением.

Например, координаты погоды должны удовлетворять:

latitude:
    -90 ≤ latitude ≤ +90

longitude:
    -180 ≤ longitude ≤ +180

Недопустимые аргументы должны отклоняться до выполнения внешнего запроса.

Это защищает как инструмент, так и границу внешнего сервиса.

17. Граница prompt-инъекций

FORTRESS не утверждает, что prompt-инъекции можно полностью устранить.

Вместо этого проект демонстрирует более сильное свойство безопасности:

Prompt-инъекция не может самостоятельно предоставить авторизацию.

Концептуально:

Malicious Prompt / External Content
              ↓
          Agent Request
              ↓
        FORTRESS Policy
              ↓
        DENY / CONFIRM

Недоверенный контент остаётся недоверенным.

18. Аудируемость

Каждое важное решение по безопасности должно порождать событие аудита.

Концептуальные поля аудита включают:

timestamp
session_id
agent_id
tool
action
risk_level
policy_decision
reason
confirmation_required
execution_status
safe_argument_summary

Система аудита должна избегать раскрытия секретов.

Журнал аудита должен отвечать на вопросы:

WHO
WHAT
WHEN
WHY
RISK
DECISION
EXECUTION

19. Центр управления безопасностью Streamlit

Streamlit обеспечивает интерактивный пользовательский интерфейс.

Интерфейс предназначен для того, чтобы сделать поведение безопасности видимым и лёгким для демонстрации.

Панель управления будет показывать такие концепции, как:

• текущая идентичность агента;

• запрошенное действие;

• запрошенный инструмент;

• разрешения;

• уровень риска;

• политическое решение;

• требование подтверждения;

• статус выполнения;

• результат инструмента;

• события аудита.

Приложение Streamlit не является органом безопасности.

Решения по безопасности принадлежат ядру FORTRESS.

Такое разделение делает систему тестируемой как через UI, так и через API.

20. HTTP API

FORTRESS предоставляет небольшой HTTP API.

API обеспечивает общий интерфейс для:

Streamlit
    │
    ├──────────────┐
    │              │
    ▼              ▼
FORTRESS API ←── Bruno
    │
    ▼
Security Gateway

Это позволяет тестировать бэкенд независимо от UI.

21. Тестирование API с помощью Bruno

Bruno используется для тестирования безопасности на уровне API.

Запланированные сценарии включают:

1. Эндпоинт проверки состояния.

2. Ошибка аутентификации.

3. Успешная аутентификация.

4. Авторизованный запрос.

5. Неавторизованный запрос.

6. Недопустимые аргументы инструмента.

7. Требуется подтверждение.

8. Отказ в чувствительном действии.

9. Граничные случаи политики безопасности.

10. Поведение при ошибках ответа.

Bruno дополняет Pytest, тестируя HTTP-границу с точки зрения API-клиента.

22. DeepEval

DeepEval используется для оценки поведения агента, значимого с точки зрения безопасности.

Его можно использовать для оценки таких сценариев, как:

• попытки prompt-инъекций;

• неавторизованные запросы инструментов;

• поведение на границах политик;

• обработка чувствительных действий;

• поведение отказа;

• ограничения использования инструментов.

DeepEval — это фреймворк оценки.

Он не заменяет детерминированный механизм авторизации.

Архитектура остаётся:

Deterministic Security
        +
Behavioral Evaluation

23. SonarQube

Для статического анализа качества кода и безопасности используется анализ, совместимый с SonarQube Free/Community.

Проект будет использовать его для выявления:

• ошибок;

• уязвимостей;

• горячих точек безопасности;

• запахов кода;

• проблем сопровождаемости;

• видимости тестов/покрытия там, где это настроено.

SonarQube — это слой анализа качества/безопасности.

Он не заменяет тестирование безопасности во время выполнения.

24. Стратегия тестирования

FORTRESS использует несколько уровней тестирования.

Модульные тесты

Быстрые детерминированные тесты для:

• идентичности;

• разрешений;

• авторизации;

• политик;

• риска;

• валидации;

• аудита;

• поведения инструментов.

Интеграционные тесты

Тесты для:

• API + шлюз безопасности;

• граница MCP;

• адаптер внешнего API;

• рабочий процесс подтверждения.

API-тесты

Bruno проверяет HTTP-поведение.

Поведенческая оценка

DeepEval оценивает поведение агента, значимое с точки зрения безопасности.

Статический анализ

SonarQube анализирует качество кода и проблемы безопасности.

Линтинг

Ruff.

Проверка типов

Mypy.

CI

GitHub Actions запускает автоматизированные шлюзы качества.

25. Стек инженерного качества

Проект использует:

Python 3.12
      ↓
UV
      ↓
Pydantic
      ↓
FastAPI
      ↓
MCP
      ↓
Streamlit
      ↓
Pytest
      ↓
Ruff
      ↓
Mypy
      ↓
Bruno
      ↓
DeepEval
      ↓
SonarQube
      ↓
GitHub Actions
      ↓
Docker

Стек намеренно современный, но контролируемый.

26. Структура проекта

Текущая и планируемая структура:

FORTRESS-MCP/
│
├── .github/
│   └── workflows/
│       └── ci.yml
│
├── bruno/
│   ├── collections/
│   └── README.md
│
├── docs/
│   ├── threat-model.md
│   ├── security-architecture.md
│   ├── phase-1-decision-log.md
│   └── phase-2-reuse-decision.md
│
├── src/
│   └── fortress_mcp/
│       ├── __init__.py
│       │
│       ├── api/
│       │   ├── __init__.py
│       │   └── app.py
│       │
│       ├── core/
│       │   ├── __init__.py
│       │   └── health.py
│       │
│       ├── identity/
│       │   └── __init__.py
│       │
│       ├── policy/
│       │   └── __init__.py
│       │
│       ├── risk/
│       │   └── __init__.py
│       │
│       ├── audit/
│       │   └── __init__.py
│       │
│       ├── mcp/
│       │   └── __init__.py
│       │
│       ├── tools/
│       │   └── __init__.py
│       │
│       └── streamlit_app.py
│
├── tests/
│   ├── unit/
│   │   └── test_health.py
│   └── integration/
│
├── .gitignore
├── .pre-commit-config.yaml
├── Dockerfile
├── pyproject.toml
├── sonar-project.properties
├── uv.lock
└── README.md

Структура будет расти только тогда, когда будет реализована соответствующая возможность безопасности.

27. Установка

Требования

• Windows/Linux/macOS

• Python 3.12

• UV

• Git

• Docker (для проверки контейнеров)

• Bruno (для тестирования API)

• Настройка, совместимая с SonarQube Community/Free, для статического анализа

Необязательные интеграции моделей/API должны использовать безопасные переменные окружения.

Никакие секреты не должны попадать в Git.

28. Установка с помощью UV

Из корня репозитория:

uv sync

Запускайте команды через окружение UV:

uv run pytest

uv run ruff check .

uv run mypy src

29. Запуск API

Точка входа API:

fortress_mcp.api.app:app

Запуск:

uv run uvicorn fortress_mcp.api.app:app --reload

Эндпоинт проверки состояния:

GET /health

Ожидаемый концептуальный ответ:

{
  "service": "fortress-mcp",
  "status": "ok"
}

30. Запуск Streamlit

Запуск:

uv run streamlit run src/fortress_mcp/streamlit_app.py

Интерфейс Streamlit — это Центр управления безопасностью.

По мере реализации последующих фаз он будет предоставлять:

Identity
Permissions
Request
Risk
Policy
Confirmation
Execution
Audit

31. Docker

Сборка:

docker build -t fortress-mcp .

Запуск:

docker run --rm -p 8000:8000 fortress-mcp

Контейнер открывает порт:

8000

32. Рабочий процесс разработки

Рабочий процесс разработки:

Understand
   ↓
Design
   ↓
Implement
   ↓
Test
   ↓
Lint
   ↓
Type Check
   ↓
Security Analysis
   ↓
API Evaluation
   ↓
Commit

Каждая значимая веха получает контрольную точку в Git.

33. Стратегия повторного использования

FORTRESS-MCP следует инженерной стратегии повторного использования в первую очередь.

Проект не слепо клонирует предыдущие приложения.

Вместо этого:

Existing Proven Infrastructure
          ↓
       Verify
          ↓
       Select
          ↓
       Adapt
          ↓
    Remove Unused
          ↓
Implement FORTRESS Security Logic

TOOLFORGE

Используется как основной справочник для:

• структуры MCP;

• контрактов инструментов;

• концепций реестра MCP;

• границ выполнения инструментов;

• шаблонов адаптеров живых API;

• контрактов Pydantic.

NEXUS-SHIELD

Используется как справочник для:

• UV;

• Python 3.12;

• управления зависимостями;

• Ruff;

• Mypy;

• Pytest;

• GitHub Actions;

• Docker;

• шаблонов SonarQube.

WEBPULSE

Используется как вспомогательный справочник для:

• шаблонов HTTP/API;

• Pydantic;

• подходов к тестированию.

Специфичная для проекта бизнес-логика и логика, специфичная для провайдера, не копируются слепо.

34. Инварианты безопасности

FORTRESS должен поддерживать следующие инварианты:

1. Default deny.
2. Agent intent never equals authorization.
3. Untrusted content never grants permission.
4. Unknown tools never execute.
5. Invalid arguments never reach execution.
6. Sensitive actions require explicit confirmation.
7. The LLM cannot self-confirm.
8. Every security decision is auditable.
9. Audit records do not expose secrets.
10. Tool execution occurs only after the security gate.

Эти инварианты важнее любого отдельного фреймворка.

35. Обработка сбоев

FORTRESS должен безопасно завершать работу при сбоях.

Примеры:

Unknown Agent
    → DENY

Unknown Tool
    → DENY

Missing Permission
    → DENY

Invalid Arguments
    → DENY / VALIDATION ERROR

High-Risk Action
    → REQUIRE_CONFIRMATION

Confirmation Rejected
    → DENY

External API Failure
    → Safe Error

Unexpected Security Error
    → Fail Closed

Система никогда не должна интерпретировать внутренний сбой как авторизацию.

36. Наблюдаемость

События безопасности должны быть наблюдаемыми.

Полезные поля включают:

timestamp
agent_id
session_id
tool
action
permission
risk
decision
reason
confirmation
execution_status

Журналы должны быть:

• структурированными;

• доступными для поиска;

• безопасными;

• минимальными;

• полезными для анализа инцидентов.

Чувствительные значения должны быть замаскированы.

37. Модель безопасности

FORTRESS использует многоуровневую модель безопасности:

                 ┌───────────────────────┐
                 │     Agent / LLM       │
                 └───────────┬───────────┘
                             │
                             ▼
                 ┌───────────────────────┐
                 │       Identity        │
                 └───────────┬───────────┘
                             ▼
                 ┌───────────────────────┐
                 │    Authentication     │
                 └───────────┬───────────┘
                             ▼
                 ┌───────────────────────┐
                 │    Authorization      │
                 └───────────┬───────────┘
                             ▼
                 ┌───────────────────────┐
                 │       Policy          │
                 └───────────┬───────────┘
                             ▼
                 ┌───────────────────────┐
                 │        Risk           │
                 └───────────┬───────────┘
                             ▼
                 ┌───────────────────────┐
                 │     Confirmation      │
                 └───────────┬───────────┘
                             ▼
                 ┌───────────────────────┐
                 │     Validation        │
                 └───────────┬───────────┘
                             ▼
                 ┌───────────────────────┐
                 │        MCP            │
                 └───────────┬───────────┘
                             ▼
                 ┌───────────────────────┐
                 │        Tool           │
                 └───────────┬───────────┘
                             ▼
                 ┌───────────────────────┐
                 │        Audit          │
                 └───────────────────────┘

38. Что делает этот проект особенным?

Многие проекты GenAI сосредоточены на:

Prompt
  ↓
LLM
  ↓
Answer

FORTRESS сосредоточен на:

Intent
  ↓
Security Boundary
  ↓
Decision
  ↓
Controlled Execution

Это превращает проект из типичной демонстрации GenAI в инженерный проект по безопасности ИИ.

Ценность для портфолио заключается в демонстрации того, что кандидат понимает:

• ИИ-агенты;

• MCP;

• вызов инструментов;

• проектирование API;

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

• авторизация;

• механизмы политик;

• минимальные привилегии;

• границы безопасности;

• инъекция промптов;

• безопасность с участием человека в цикле;

• наблюдаемость;

• тестирование;

• DevSecOps.

39. Ценность для собеседования

FORTRESS спроектирован так, чтобы поддерживать содержательные обсуждения на собеседованиях.

Вопрос: Почему LLM не может авторизовать себя сам?

Ответ:

Вывод LLM — это ненадёжный пользовательский ввод. Авторизация — это решение в сфере безопасности, поэтому оно должно приниматься детерминированно, вне модели.

Вопрос: Как вы обрабатываете инъекцию промптов?

Ответ:

Инъекция промптов рассматривается как ненадёжный ввод. Она может повлиять на запрос агента, но не может самостоятельно предоставить авторизацию. FORTRESS оценивает итоговый запрос через собственную границу политик.

Вопрос: Зачем использовать MCP?

Ответ:

MCP предоставляет стандартизированный уровень взаимодействия с инструментами. FORTRESS сосредоточен на границе безопасности вокруг выполнения инструментов, а не на пересоздании протокола инструментов.

Вопрос: Зачем требовать подтверждение человека?

Ответ:

Действия с высоким риском не должны авторизоваться моделью самостоятельно. Явное подтверждение создаёт отдельную границу авторизации, контролируемую реальным пользователем.

Вопрос: Почему отказ по умолчанию?

Ответ:

Критичные для безопасности системы не должны предоставлять разрешения лишь потому, что инструмент или запрос не был явно заблокирован. Неизвестные или недостаточно авторизованные действия должны завершаться отказом (fail closed).

Вопрос: Почему детерминированные политики?

Ответ:

Детерминированная политика объяснима, тестируема, воспроизводима и аудируема. LLM может помогать с интерпретацией намерений, но не должен быть финальным органом безопасности.

Вопрос: Зачем DeepEval, если уже есть Pytest?

Ответ:

Pytest проверяет детерминированное поведение приложения. DeepEval оценивает поведение модели/агента и сценарии, значимые для безопасности. Они решают разные задачи тестирования.

Вопрос: Зачем Bruno?

Ответ:

Bruno проверяет HTTP-границу так, как это делал бы внешний API-клиент, дополняя внутренние модульные и интеграционные тесты.

Вопрос: Зачем SonarQube?

Ответ:

SonarQube добавляет статический анализ качества кода и безопасности, дополняя тесты времени выполнения и специализированные оценки безопасности.

40. Ограничения

FORTRESS-MCP намеренно не является корпоративной IAM-платформой.

Следующее выходит за рамки первоначального объёма:

• корпоративный OAuth/OIDC-провайдер идентификации;

• Kubernetes;

• мультиоблачный IAM;

• сложная распределённая авторизация;

• корпоративное управление секретами;

• продвинутый RAG;

• крупная оркестрация мультиагентов;

• десятки MCP-инструментов;

• сложная инфраструктура баз данных;

• крупный фронтенд-фреймворк;

• ненужные микросервисы.

Всё это может стать будущими расширениями, но не требуется для базового проекта.

41. Дисклеймер о безопасности

FORTRESS-MCP — это портфолио-проект уровня инженера по безопасности.

Он демонстрирует архитектуру безопасности и средства контроля, но не претендует на полную защиту enterprise-уровня от всех угроз ИИ-агентов.

В частности:

• нельзя считать, что инъекции промптов полностью решены;

• внешние API могут отказывать;

• поведение модели остаётся вероятностным;

• средства контроля безопасности требуют соответствующей конфигурации развёртывания;

• реальные производственные системы требуют более широкого контроля идентификации, инфраструктуры, мониторинга и соответствия требованиям.

Заявления проекта о безопасности ограничены теми средствами контроля, которые явно реализованы и протестированы.

42. Дорожная карта разработки

Фаза 1 — Модель угроз + Архитектура безопасности

Статус:

COMPLETE

Сделано:

• модель угроз;

• архитектура безопасности;

• инварианты безопасности;

• фиксация объёма;

• решения по проекту.

Контрольная точка Git:

92e3d81
docs: establish phase 1 security foundation

Фаза 2 — Проверенное повторное использование инфраструктуры

Статус:

IN PROGRESS

Сделано на данный момент:

• проект UV;

• Python 3.12;

• структура пакета;

• основа FastAPI;

• зависимость MCP;

• оболочка Streamlit;

• основа Pytest;

• Ruff;

• Mypy;

• основа GitHub Actions;

• основа Docker;

• конфигурация SonarQube;

• структура Bruno;

• зависимость DeepEval;

• документация по решению о повторном использовании.

Фаза 3 — Идентичность + Аутентификация

Планируется:

• модель идентичности агента;

• граница аутентификации;

• идентичность сессии;

• обработка сбоев аутентификации;

• детерминированные тесты идентичности.

Фаза 4 — Авторизация + Политика

Планируется:

• модель разрешений;

• механизм политик;

• решения allow/deny;

• отказ по умолчанию;

• авторизация инструментов;

• тесты авторизации.

Фаза 5 — Риск + Подтверждение человеком

Планируется:

• классификация рисков;

• требование подтверждения;

• внешнее подтверждение пользователем;

• отклонение подтверждения;

• повторная оценка авторизации.

Фаза 6 — MCP-шлюз + Инструменты

Планируется:

• MCP-шлюз;

• реестр инструментов;

• калькулятор;

• погода;

• обновление записи;

• чувствительное действие;

• проверка аргументов;

• живая интеграция с Open-Meteo.

Фаза 7 — Инъекция промптов + Аудит

Планируется:

• сценарии инъекции промптов;

• граница ненадёжного контента;

• безопасные события аудита;

• отчётность о событиях безопасности.

Фаза 8 — Pytest + DeepEval

Планируется:

• детерминированные тесты безопасности;

• интеграционные тесты;

• состязательные сценарии;

• оценка DeepEval;

• анализ отказов.

Фаза 9 — Streamlit + Bruno + SonarQube + CI

Планируется:

• полная панель безопасности;

• коллекция API Bruno;

• анализ SonarQube;

• качественные шлюзы CI;

• отчётность о тестах безопасности.

Фаза 10 — Релиз

Планируется:

• README;

• документация по архитектуре;

• отчёт о безопасности;

• ограничения;

• доказательства тестирования;

• вопросы и ответы для собеседования;

• контрольная точка релиза в Git.

43. Критерий завершённости

FORTRESS-MCP считается завершённым, когда:

[ ] Identity implemented
[ ] Authentication implemented
[ ] Authorization implemented
[ ] Default deny enforced
[ ] Policy engine implemented
[ ] Risk classification implemented
[ ] Human confirmation implemented
[ ] MCP gateway implemented
[ ] Four core tools implemented
[ ] Tool arguments validated
[ ] Open-Meteo live API integrated
[ ] Prompt-injection boundary demonstrated
[ ] Audit trail implemented
[ ] Streamlit dashboard complete
[ ] Bruno collection complete
[ ] DeepEval evaluation complete
[ ] Pytest suite complete
[ ] Ruff passes
[ ] Mypy passes
[ ] SonarQube analysis reviewed
[ ] CI passes
[ ] Docker validation passes
[ ] No secrets committed
[ ] Documentation complete
[ ] Interview Q&A complete
[ ] Final release validation complete

44. Финальный архитектурный принцип

Ключевой принцип FORTRESS-MCP:

The model proposes.
The security gateway decides.
The MCP layer executes.
The audit layer records.

Именно это разделение является ядром проекта.

45. Статус проекта

Текущая веха проекта:

FORTRESS-MCP
│
├── Phase 1  ████████████████████ COMPLETE
├── Phase 2  ████████████░░░░░░░░ IN PROGRESS
├── Phase 3  ░░░░░░░░░░░░░░░░░░░░ PENDING
├── Phase 4  ░░░░░░░░░░░░░░░░░░░░ PENDING
├── Phase 5  ░░░░░░░░░░░░░░░░░░░░ PENDING
├── Phase 6  ░░░░░░░░░░░░░░░░░░░░ PENDING
├── Phase 7  ░░░░░░░░░░░░░░░░░░░░ PENDING
├── Phase 8  ░░░░░░░░░░░░░░░░░░░░ PENDING
├── Phase 9  ░░░░░░░░░░░░░░░░░░░░ PENDING
└── Phase 10 ░░░░░░░░░░░░░░░░░░░░ PENDING

Проект намеренно ограничен сфокусированной, высокоценной реализацией, а не разрастанием в корпоративную платформу.

Лицензия

GXP49