FORTRESS-MCP

Zero-Trust-Sicherheitsgateway für die Tool-Ausführung von KI-Agenten

FORTRESS-MCP ist ein anbieterneutrales Zero-Trust-Sicherheitsgateway, das dazu dient, zu kontrollieren, wie KI-Agenten MCP-Tools anfordern und ausführen.

Das Projekt demonstriert eine produktionsreife Sicherheitsgrenze zwischen Agentenabsicht und privilegierter Tool-Ausführung.

Ein KI-Agent darf eine Aktion anfordern, aber der Agent autorisiert oder führt privilegierte Aktionen nicht eigenständig aus.

Related MCP server: mcp-guardian

1. Warum FORTRESS-MCP?

Moderne KI-Agenten können Tools, APIs, Dateisysteme, Datenbanken und externe Dienste aufrufen. Das Sicherheitsproblem ist nicht mehr nur:

"Kann das Modell die richtige Antwort erzeugen?"

Es ist auch:

"Kann dem Modell vertraut werden, wenn es entscheidet, welche Aktionen es ausführen darf?"

FORTRESS-MCP adressiert dieses Problem, indem es Folgendes trennt:

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

Das LLM ist daher nicht die Sicherheitsinstanz.

2. Projektziele

FORTRESS-MCP soll Folgendes demonstrieren:

• Zero-Trust-Tool-Ausführung für KI-Agenten.

• Autorisierung nach dem Prinzip der geringsten Privilegien.

• Sicherheit nach dem Default-Deny-Prinzip.

• Deterministische Policy-Entscheidungen.

• Risikoklassifizierung.

• Menschliche Bestätigung für sensible Aktionen.

• MCP-basierte Tool-Ausführung.

• Eindämmung von Prompt-Injection.

• Tool- und Argumentvalidierung.

• Sicheres Audit-Logging.

• API-Sicherheitstests.

• Bewertung der Agentensicherheit.

• Statische Sicherheitsanalyse.

• Produktionsnahe Engineering-Praktiken.

Das Projekt ist bewusst so konzipiert, dass es:

• branchenorientiert ist;

• interviewtauglich ist;

• eine starke Portfolio-Wirkung hat;

• anbieterneutral ist;

• technisch tiefgehend ist;

• einfach genug ist, um es zu verstehen und zu warten.

3. Zentrales Sicherheitsprinzip

Die zentrale Designregel lautet:

Agent Intent
    ≠
Security Decision
    ≠
Tool Execution

Der Agent kann eine Aktion anfordern.

FORTRESS entscheidet, ob die Aktion erlaubt ist.

Erst nach erfolgreichem Sicherheitsgate kann das MCP-Tool ausgeführt werden.

4. High-Level-Architektur

                         ┌──────────────────────┐
                         │      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. Vertrauensgrenzen

FORTRESS definiert explizite Vertrauensgrenzen.

Agent → FORTRESS

Agentenanfragen sind nicht vertrauenswürdige Eingaben.

Der Agent erhält nicht automatisch eine Berechtigung, nur weil er die Anfrage erzeugt hat.

FORTRESS → MCP

Nur autorisierte, validierte Anfragen dürfen die Ausführungsgrenze überschreiten.

MCP → Externes Tool

Die externe Ausführung wird kontrolliert und protokolliert.

Externe Daten → Agent

Externe Daten sind nicht vertrauenswürdige Daten.

Externe Daten gewähren niemals eine Autorisierung.

Menschliche Bestätigung

Sensible Autorisierungen müssen von der tatsächlichen Benutzeroberfläche stammen.

Das LLM kann seine eigene Anfrage nicht bestätigen.

6. Sicherheits-Entscheidungspipeline

Jeder geschützte Vorgang durchläuft diese konzeptionelle Pipeline:

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

Die genaue Implementierung ist bewusst deterministisch.

7. Identität

Identität repräsentiert den Akteur, der einen Vorgang anfordert.

Konzeptionell:

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

Authentifizierung beantwortet:

Wer bist du?

Autorisierung beantwortet:

Darfst du diese Aktion ausführen?

Dies sind bewusst getrennte Konzepte.

8. Berechtigungen

FORTRESS verwendet ein bewusst kleines Berechtigungsmodell:

READ
WRITE
SENSITIVE

Dies reicht aus, um das Prinzip der geringsten Privilegien zu demonstrieren, ohne unnötige Enterprise-IAM-Komplexität einzuführen.

9. Policy-Entscheidungen

Die Policy-Ebene erzeugt eine von drei Entscheidungen:

ALLOW
DENY
REQUIRE_CONFIRMATION

Standardverhalten:

Unknown
    ↓
DENY

Die Policy-Engine ist Anwendungslogik.

Sie wird nicht an das LLM delegiert.

10. Risikoklassifizierung

FORTRESS verwendet drei Risikostufen:

LOW
MEDIUM
HIGH

Erste konzeptionelle Zuordnung:

Die Risikoklassifizierung ist deterministisch und erklärbar.

11. Menschliche Bestätigung

Hochriskante Vorgänge können eine explizite menschliche Bestätigung erfordern.

Der Sicherheitsablauf ist:

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

Eine kritische Sicherheitsregel lautet:

Das LLM kann die Bestätigung des Benutzers weder erzeugen noch simulieren.

12. MCP

MCP stellt die standardisierte Tool-Interaktionsebene bereit.

FORTRESS umgibt MCP mit der Sicherheitsgrenze.

Konzeptionell:

Agent
  ↓
FORTRESS Security Gateway
  ↓
MCP
  ↓
Tool

FORTRESS versucht nicht, MCP zu ersetzen.

Stattdessen demonstriert es, wie die MCP-Tool-Ausführung hinter ein deterministisches Sicherheitsgateway gestellt werden kann.

13. Erster Tool-Satz

Das Projekt begrenzt die anfängliche Tool-Oberfläche bewusst.

calculator_read

Zweck:

• deterministische lokale Berechnung;

• risikoarme Leseoperation;

• nützlich für Basis-Autorisierungstests.

weather_lookup

Zweck:

• Abruf von Live-Wetterdaten;

• Demonstration eines kontrollierten externen API-Zugriffs;

• Demonstration externer Daten als nicht vertrauenswürdige Eingabe.

update_record

Zweck:

• Demonstration einer Schreiboperation;

• Demonstration einer Autorisierung mit höherem Risiko;

• Demonstration der Policy-Durchsetzung.

sensitive_action

Zweck:

• Demonstration sensibler Vorgänge;

• Anforderung einer expliziten Bestätigung;

• Demonstration von Verweigerungs- und Bestätigungspfaden.

Der kleine Tool-Satz ist beabsichtigt.

Das Projekt priorisiert Sicherheitstiefe gegenüber der Anzahl der Tools.

14. Live-Daten-API

FORTRESS verwendet Open-Meteo als ersten kostenlosen Live-Datenanbieter für die Wetterabfrage.

Konzeptionell:

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

Der externe Anbieter bleibt austauschbar.

Die Sicherheitsgrenze hängt nicht vom Anbieter ab.

15. Externe Daten sind nicht vertrauenswürdig

Ein kritisches Designprinzip lautet:

External Data
      ≠
Authorization

Wetterantworten, API-Antworten, Dokumente und andere externe Inhalte können bösartigen oder befehlsähnlichen Text enthalten.

Solche Inhalte können keine Berechtigung erteilen.

Die Autorisierung wird durch die FORTRESS-Policy bestimmt.

16. Argumentvalidierung

Tool-Argumente werden vor der Ausführung validiert.

Beispielsweise müssen Wetterkoordinaten folgende Bedingungen erfüllen:

latitude:
    -90 ≤ latitude ≤ +90

longitude:
    -180 ≤ longitude ≤ +180

Ungültige Argumente müssen abgelehnt werden, bevor die externe Anfrage ausgeführt wird.

Dies schützt sowohl das Tool als auch die Grenze zum externen Dienst.

17. Prompt-Injection-Grenze

FORTRESS behauptet nicht, dass Prompt-Injection vollständig eliminiert werden kann.

Stattdessen demonstriert das Projekt eine stärkere Sicherheitseigenschaft:

Prompt-Injection kann nicht eigenständig eine Autorisierung erteilen.

Konzeptionell:

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

Nicht vertrauenswürdige Inhalte bleiben nicht vertrauenswürdig.

18. Auditierbarkeit

Jede wichtige Sicherheitsentscheidung sollte ein Audit-Ereignis erzeugen.

Konzeptionelle Audit-Felder umfassen:

timestamp
session_id
agent_id
tool
action
risk_level
policy_decision
reason
confirmation_required
execution_status
safe_argument_summary

Das Audit-System darf keine Geheimnisse offenlegen.

Die Audit-Spur sollte beantworten:

WHO
WHAT
WHEN
WHY
RISK
DECISION
EXECUTION

19. Streamlit-Sicherheitskontrollzentrum

Streamlit stellt die interaktive Benutzeroberfläche bereit.

Die Benutzeroberfläche soll das Sicherheitsverhalten sichtbar machen und leicht demonstrierbar sein.

Das Dashboard wird Konzepte wie folgende anzeigen:

• aktuelle Agentenidentität;

• angeforderte Aktion;

• angefordertes Tool;

• Berechtigungen;

• Risikostufe;

• Policy-Entscheidung;

• Bestätigungsanforderung;

• Ausführungsstatus;

• Tool-Ergebnis;

• Audit-Ereignisse.

Die Streamlit-Anwendung ist nicht die Sicherheitsinstanz.

Sicherheitsentscheidungen gehören zum FORTRESS-Kern.

Diese Trennung macht das System sowohl über die Benutzeroberfläche als auch über die API testbar.

20. HTTP-API

FORTRESS stellt eine kleine HTTP-API bereit.

Die API bietet eine gemeinsame Schnittstelle für:

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

Dadurch ist es möglich, das Backend unabhängig von der Benutzeroberfläche zu testen.

21. Bruno-API-Tests

Bruno wird für API-Sicherheitstests verwendet.

Die geplanten Szenarien umfassen:

1. Health-Endpunkt.

2. Authentifizierungsfehler.

3. Erfolgreiche Authentifizierung.

4. Autorisierte Anfrage.

5. Nicht autorisierte Anfrage.

6. Ungültige Tool-Argumente.

7. Bestätigung erforderlich.

8. Verweigerung sensibler Aktionen.

9. Grenzfälle der Sicherheits-Policy.

10. Fehlerantwortverhalten.

Bruno ergänzt Pytest, indem es die HTTP-Grenze aus der Perspektive eines API-Clients testet.

22. DeepEval

DeepEval wird zur Bewertung sicherheitsrelevanten Agentenverhaltens verwendet.

Es kann zur Bewertung von Szenarien wie folgenden verwendet werden:

• Prompt-Injection-Versuche;

• nicht autorisierte Tool-Anfragen;

• Policy-Grenzverhalten;

• Umgang mit sensiblen Aktionen;

• Verweigerungsverhalten;

• Tool-Nutzungseinschränkungen.

DeepEval ist ein Bewertungsframework.

Es ersetzt nicht die deterministische Autorisierungs-Engine.

Die Architektur bleibt:

Deterministic Security
        +
Behavioral Evaluation

23. SonarQube

Für die statische Codequalitäts- und Sicherheitsprüfung wird eine SonarQube Free/Community-kompatible Analyse verwendet.

Das Projekt wird damit Folgendes identifizieren:

• Fehler;

• Schwachstellen;

• Sicherheits-Hotspots;

• Code-Smells;

• Wartbarkeitsprobleme;

• Test-/Abdeckungssichtbarkeit, wo konfiguriert.

SonarQube ist eine Qualitäts-/Sicherheitsanalyseschicht.

Es ersetzt keine Laufzeit-Sicherheitstests.

24. Teststrategie

FORTRESS verwendet mehrere Testebenen.

Unit-Tests

Schnelle deterministische Tests für:

• Identität;

• Berechtigungen;

• Autorisierung;

• Policy;

• Risiko;

• Validierung;

• Audit;

• Tool-Verhalten.

Integrationstests

Tests für:

• API + Sicherheitsgateway;

• MCP-Grenze;

• externen API-Adapter;

• Bestätigungsworkflow.

API-Tests

Bruno validiert das HTTP-Verhalten.

Verhaltensbewertung

DeepEval bewertet sicherheitsrelevantes Agentenverhalten.

Statische Analyse

SonarQube analysiert Codequalität und Sicherheitsprobleme.

Linting

Ruff.

Typprüfung

Mypy.

CI

GitHub Actions führt die automatisierten Qualitätsgates aus.

25. Engineering-Qualitätsstack

Das Projekt verwendet:

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

Der Stack ist bewusst modern, aber kontrolliert.

26. Projektstruktur

Aktuelle und geplante Struktur:

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

Die Struktur wird nur dann erweitert, wenn die entsprechende Sicherheitsfunktion implementiert ist.

27. Installation

Anforderungen

• Windows/Linux/macOS

• Python 3.12

• UV

• Git

• Docker (für Container-Validierung)

• Bruno (für API-Tests)

• SonarQube Community/Free-kompatibles Setup für statische Analyse

Optionale Modell-/API-Integrationen müssen sichere Umgebungsvariablen verwenden.

Keine Geheimnisse gehören in Git.

28. Installation mit UV

Aus dem Repository-Stammverzeichnis:

uv sync

Befehle über die UV-Umgebung ausführen:

uv run pytest

uv run ruff check .

uv run mypy src

29. API ausführen

Der API-Einstiegspunkt ist:

fortress_mcp.api.app:app

Ausführen:

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

Health-Endpunkt:

GET /health

Erwartete konzeptionelle Antwort:

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

30. Streamlit ausführen

Ausführen:

uv run streamlit run src/fortress_mcp/streamlit_app.py

Die Streamlit-Benutzeroberfläche ist das Sicherheitskontrollzentrum.

Wenn spätere Phasen implementiert sind, wird sie Folgendes bereitstellen:

Identity
Permissions
Request
Risk
Policy
Confirmation
Execution
Audit

31. Docker

Build:

docker build -t fortress-mcp .

Ausführen:

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

Der Container gibt Port frei:

8000

32. Entwicklungsworkflow

Der Entwicklungsworkflow ist:

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

Jeder bedeutende Meilenstein erhält einen Git-Checkpoint.

33. Wiederverwendungsstrategie

FORTRESS-MCP folgt einer Wiederverwendungs-zuerst-Engineering-Strategie.

Das Projekt klont nicht blind frühere Anwendungen.

Stattdessen:

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

TOOLFORGE

Wird als primäre Referenz verwendet für:

• MCP-Struktur;

• Tool-Verträge;

• MCP-Registry-Konzepte;

• Tool-Ausführungsgrenzen;

• Live-API-Adaptermuster;

• Pydantic-Verträge.

NEXUS-SHIELD

Wird als Referenz verwendet für:

• UV;

• Python 3.12;

• Abhängigkeitsverwaltung;

• Ruff;

• Mypy;

• Pytest;

• GitHub Actions;

• Docker;

• SonarQube-Muster.

WEBPULSE

Wird als unterstützende Referenz verwendet für:

• HTTP/API-Muster;

• Pydantic;

• Testansätze.

Projektspezifische Geschäftslogik und anbieterspezifische Logik werden nicht blind kopiert.

34. Sicherheitsinvarianten

FORTRESS sollte diese Invarianten aufrechterhalten:

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.

Diese Invarianten sind wichtiger als jedes einzelne Framework.

35. Fehlerbehandlung

FORTRESS sollte sicher ausfallen.

Beispiele:

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

Das System darf einen internen Fehler niemals als Autorisierung interpretieren.

36. Beobachtbarkeit

Sicherheitsereignisse sollten beobachtbar sein.

Nützliche Felder umfassen:

timestamp
agent_id
session_id
tool
action
permission
risk
decision
reason
confirmation
execution_status

Die Logs sollten:

• strukturiert;

• durchsuchbar;

• sicher;

• minimal;

• nützlich für die Incident-Analyse sein.

Sensible Werte sollten geschwärzt werden.

37. Sicherheitsmodell

FORTRESS verwendet ein mehrschichtiges Sicherheitsmodell:

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

38. Was macht dieses Projekt anders?

Viele GenAI-Projekte konzentrieren sich auf:

Prompt
  ↓
LLM
  ↓
Answer

FORTRESS konzentriert sich auf:

Intent
  ↓
Security Boundary
  ↓
Decision
  ↓
Controlled Execution

Dies verwandelt das Projekt von einer typischen GenAI-Demonstration in ein KI-Sicherheits-Engineering-Projekt.

Der Portfolio-Wert ergibt sich aus dem Nachweis, dass der Kandidat Folgendes versteht:

• KI-Agenten;

• MCP;

• Tool-Aufrufe;

• API-Design;

• Authentifizierung;

• Autorisierung;

• Policy-Engines;

• Least Privilege;

• Sicherheitsgrenzen;

• Prompt-Injection;

• Human-in-the-Loop-Sicherheit;

• Observability;

• Testen;

• DevSecOps.

39. Interview-Mehrwert

FORTRESS ist darauf ausgelegt, starke Interview-Gespräche zu unterstützen.

Frage: Warum darf sich das LLM nicht selbst autorisieren?

Antwort:

LLM-Ausgabe ist nicht vertrauenswürdige Anwendungseingabe. Autorisierung ist eine Sicherheitsentscheidung und muss daher deterministisch außerhalb des Modells durchgesetzt werden.

Frage: Wie gehst du mit Prompt-Injection um?

Antwort:

Prompt-Injection wird als nicht vertrauenswürdige Eingabe behandelt. Sie kann die Agent-Anfrage beeinflussen, aber keine Autorisierung unabhängig erteilen. FORTRESS bewertet die resultierende Anfrage über seine eigene Policy-Grenze.

Frage: Warum MCP verwenden?

Antwort:

MCP bietet eine standardisierte Tool-Interaktionsebene. FORTRESS konzentriert sich auf die Sicherheitsgrenze rund um die Tool-Ausführung, anstatt das Tool-Protokoll neu zu erstellen.

Frage: Warum eine menschliche Bestätigung verlangen?

Antwort:

Aktionen mit hohem Risiko sollten nicht vom Modell selbst autorisiert werden. Eine explizite Bestätigung schafft eine separate Autorisierungsgrenze, die vom tatsächlichen Benutzer kontrolliert wird.

Frage: Warum Default-Deny?

Antwort:

Sicherheitskritische Systeme sollten keine Berechtigungen erteilen, nur weil ein Tool oder eine Anfrage nicht explizit blockiert wurde. Unbekannte oder unzureichend autorisierte Aktionen sollten nach dem Fail-Closed-Prinzip abgelehnt werden.

Frage: Warum deterministische Policy?

Antwort:

Deterministische Policy ist erklärbar, testbar, reproduzierbar und auditierbar. Ein LLM kann bei der Absichtsinterpretation helfen, sollte aber nicht die letzte Sicherheitsinstanz sein.

Frage: Warum DeepEval verwenden, wenn Pytest bereits existiert?

Antwort:

Pytest validiert deterministisches Anwendungsverhalten. DeepEval bewertet Modell-/Agent-Verhalten und sicherheitsrelevante Szenarien. Sie lösen unterschiedliche Testprobleme.

Frage: Warum Bruno?

Antwort:

Bruno validiert die HTTP-Grenze wie ein externer API-Client und ergänzt damit interne Unit- und Integrationstests.

Frage: Warum SonarQube?

Antwort:

SonarQube ergänzt statische Code-Qualitäts- und Sicherheitsanalyse, die Laufzeittests und sicherheitsspezifische Bewertungen ergänzt.

40. Einschränkungen

FORTRESS-MCP ist bewusst keine Enterprise-IAM-Plattform.

Folgendes liegt außerhalb des anfänglichen Umfangs:

• Enterprise-OAuth/OIDC-Identity-Provider;

• Kubernetes;

• Multi-Cloud-IAM;

• komplexe verteilte Autorisierung;

• Enterprise-Secrets-Management;

• fortgeschrittenes RAG;

• große Multi-Agent-Orchestrierung;

• Dutzende von MCP-Tools;

• komplexe Datenbankinfrastruktur;

• großes Frontend-Framework;

• unnötige Microservices.

Diese Punkte können künftige Erweiterungen sein, sind aber für das Kernprojekt nicht erforderlich.

41. Sicherheitshinweis

FORTRESS-MCP ist ein sicherheitstechnisches Projekt im Portfolio-Stil.

Es demonstriert Sicherheitsarchitektur und -kontrollen, erhebt aber nicht den Anspruch, vollständigen Enterprise-Schutz gegen jede KI-Agenten-Bedrohung zu bieten.

Insbesondere gilt:

• Prompt-Injection kann nicht als perfekt gelöst vorausgesetzt werden;

• externe APIs können ausfallen;

• Modellverhalten bleibt probabilistisch;

• Sicherheitskontrollen erfordern eine angemessene Bereitstellungskonfiguration;

• reale Produktionssysteme erfordern breitere Identitäts-, Infrastruktur-, Überwachungs- und Compliance-Kontrollen.

Die Sicherheitsaussagen des Projekts beschränken sich auf die Kontrollen, die explizit implementiert und getestet sind.

42. Entwicklungsfahrplan

Phase 1 – Bedrohungsmodell + Sicherheitsarchitektur

Status:

COMPLETE

Geliefert:

• Bedrohungsmodell;

• Sicherheitsarchitektur;

• Sicherheitsinvarianten;

• Scope-Festlegung;

• Projektentscheidungen.

Git-Checkpoint:

92e3d81
docs: establish phase 1 security foundation

Phase 2 – Verifizierte Infrastruktur-Wiederverwendung

Status:

IN PROGRESS

Bisher geliefert:

• UV-Projekt;

• Python 3.12;

• Paketstruktur;

• FastAPI-Grundlage;

• MCP-Abhängigkeit;

• Streamlit-Shell;

• Pytest-Grundlage;

• Ruff;

• Mypy;

• GitHub-Actions-Grundlage;

• Docker-Grundlage;

• SonarQube-Konfiguration;

• Bruno-Struktur;

• DeepEval-Abhängigkeit;

• Dokumentation der Wiederverwendungsentscheidung.

Phase 3 – Identität + Authentifizierung

Geplant:

• Agent-Identitätsmodell;

• Authentifizierungsgrenze;

• Sitzungsidentität;

• Behandlung von Authentifizierungsfehlern;

• deterministische Identitätstests.

Phase 4 – Autorisierung + Policy

Geplant:

• Berechtigungsmodell;

• Policy-Engine;

• Allow/Deny-Entscheidungen;

• Default-Deny;

• Tool-Autorisierung;

• Autorisierungstests.

Phase 5 – Risiko + menschliche Bestätigung

Geplant:

• Risikoklassifizierung;

• Bestätigungsanforderung;

• externe Benutzerbestätigung;

• Ablehnung der Bestätigung;

• erneute Autorisierungsbewertung.

Phase 6 – MCP-Gateway + Tools

Geplant:

• MCP-Gateway;

• Tool-Registry;

• Taschenrechner;

• Wetter;

• Datensatz aktualisieren;

• sensible Aktion;

• Argumentvalidierung;

• Open-Meteo-Integration.

Phase 7 – Prompt-Injection + Audit

Geplant:

• Prompt-Injection;

• Grenze für nicht vertrauenswürdige Inhalte;

• sichere Audit-Ereignisse;

• Auditing.

Phase 8 – Pytest + DeepEval

Geplant:

• deterministische Sicherheitstests;

• Integrationstests;

• Adversarial-Szenarien;

• Fehleranalyse.

Phase 9 – CI + Infrastruktur

Geplant:

• GitHub Actions;

• Docker;

• Container-Image;

• Sicherheits-Scans.

Phase 10 – Abschluss

Geplant:

• finale README;

• Architekturdokumentation;

• Sicherheitsbericht;

• Interview-Handreichung;

• Git-Release-Checkpoint.

43. Definition of Done

FORTRESS-MCP ist vollständig, wenn:

[ ] 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

Diese Trennung ist das Kernprinzip des Projekts.

44. Abschließendes Architekturprinzip

Das wichtigste Konzept in FORTRESS-MCP:

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

Diese Trennung ist das zentrale Prinzip des Projekts.

45. Projektstatus

Aktueller Meilenstein des Projekts:

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

Der Umfang bleibt bewusst auf eine fokussierte, wertvolle Implementierung beschränkt und nicht auf eine unnötig große Enterprise-Plattform.

Lizenz

Vor der endgültigen Veröffentlichung die ausgewählte Lizenz des Repositories hinzufügen.