Skip to main content
Glama

FORTRESS-MCP

AI 에이전트 도구 실행을 위한 제로 트러스트 보안 게이트웨이

FORTRESS-MCP는 AI 에이전트가 MCP 도구를 요청하고 실행하는 방식을 제어하도록 설계된, 공급자 중립적인 제로 트러스트 보안 게이트웨이입니다.

이 프로젝트는 에이전트 의도권한 있는 도구 실행 사이의 프로덕션 수준 보안 경계를 시연합니다.

AI 에이전트가 작업을 요청할 수는 있지만, 에이전트가 권한 있는 작업을 독립적으로 승인하거나 실행하지는 않습니다.


Related MCP server: mcp-guardian

1. 왜 FORTRESS-MCP인가?

현대 AI 에이전트는 도구, API, 파일시스템, 데이터베이스 및 외부 서비스를 호출할 수 있습니다. 보안 문제는 더 이상 다음과 같은 것만이 아닙니다:

"모델이 올바른 답변을 생성할 수 있는가?"

또한 다음과 같은 문제이기도 합니다:

"모델이 실행이 허용된 작업을 스스로 결정하도록 신뢰할 수 있는가?"

FORTRESS-MCP는 다음을 분리하여 이 문제를 해결합니다:

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

따라서 LLM은 보안 권한 주체가 아닙니다.


2. 프로젝트 목표

FORTRESS-MCP는 다음을 시연하도록 설계되었습니다:

  • 제로 트러스트 AI 에이전트 도구 실행.

  • 최소 권한 승인.

  • 기본 거부 보안.

  • 결정론적 정책 결정.

  • 위험 분류.

  • 민감한 작업에 대한 인간 확인.

  • MCP 기반 도구 실행.

  • 프롬프트 인젝션 차단.

  • 도구 및 인수 검증.

  • 안전한 감사 로깅.

  • 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. 신원

신원(Identity)은 작업을 요청하는 행위자를 나타냅니다.

개념적으로:

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

초기 개념적 매핑:

도구 / 작업

권한

위험

calculator_read

READ

LOW

weather_lookup

READ

MEDIUM

update_record

WRITE

HIGH

sensitive_action

SENSITIVE

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. 프롬프트 인젝션 경계

FORTRESS는 프롬프트 인젝션이 완벽하게 제거될 수 있다고 주장하지 않습니다.

대신 이 프로젝트는 더 강력한 보안 속성을 시연합니다:

프롬프트 인젝션은 독립적으로 승인을 부여할 수 없습니다.

개념적으로:

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은 대화형 UI를 제공합니다.

UI는 보안 동작을 시각적으로 보여주고 시연하기 쉽게 만드는 것을 목적으로 합니다.

대시보드는 다음과 같은 개념을 표시합니다:

  • 현재 에이전트 신원;

  • 요청된 작업;

  • 요청된 도구;

  • 권한;

  • 위험 수준;

  • 정책 결정;

  • 확인 요구 사항;

  • 실행 상태;

  • 도구 결과;

  • 감사 이벤트.

Streamlit 애플리케이션은 보안 권한 주체가 아닙니다.

보안 결정은 FORTRESS 코어에 속합니다.

이 분리를 통해 UI와 API를 통해 시스템을 테스트할 수 있습니다.


20. HTTP API

FORTRESS는 작은 HTTP API를 노출합니다.

API는 다음을 위한 공유 인터페이스를 제공합니다:

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

이를 통해 UI와 독립적으로 백엔드를 테스트할 수 있습니다.


21. Bruno API 테스트

Bruno는 API 수준 보안 테스트에 사용됩니다.

계획된 시나리오는 다음과 같습니다:

  1. 헬스 엔드포인트.

  2. 인증 실패.

  3. 인증 성공.

  4. 승인된 요청.

  5. 승인되지 않은 요청.

  6. 잘못된 도구 인수.

  7. 확인 필요.

  8. 민감한 작업 거부.

  9. 보안 정책 경계 사례.

  10. 오류 응답 동작.

Bruno는 API 클라이언트의 관점에서 HTTP 경계를 테스트하여 Pytest를 보완합니다.


22. DeepEval

DeepEval은 보안 관련 에이전트 동작 평가에 사용됩니다.

다음과 같은 시나리오를 평가하는 데 사용할 수 있습니다:

  • 프롬프트 인젝션 시도;

  • 승인되지 않은 도구 요청;

  • 정책 경계 동작;

  • 민감한 작업 처리;

  • 거부 동작;

  • 도구 사용 제약.

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 UI는 보안 제어 센터입니다.

이후 단계가 구현됨에 따라 다음을 노출합니다:

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 시연에서 AI 보안 엔지니어링 프로젝트로 변화시킵니다.

포트폴리오 가치는 지원자가 다음을 이해하고 있음을 입증하는 데서 비롯됩니다:

  • AI 에이전트;

  • MCP;

  • 도구 호출;

  • API 설계;

  • 인증;

  • 권한 부여;

  • 정책 엔진;

  • 최소 권한;

  • 보안 경계;

  • 프롬프트 인젝션;

  • 인간 개입 보안;

  • 관찰 가능성;

  • 테스트;

  • DevSecOps.


39. 인터뷰 가치

FORTRESS는 강력한 인터뷰 토론을 지원하도록 설계되었습니다.

질문: LLM이 스스로 권한을 부여할 수 없는 이유는 무엇인가요?

답변:

LLM 출력은 신뢰할 수 없는 애플리케이션 입력입니다. 권한 부여는 보안 결정이므로 모델 외부에서 결정적으로 강제되어야 합니다.

질문: 프롬프트 인젝션은 어떻게 처리하나요?

답변:

프롬프트 인젝션은 신뢰할 수 없는 입력으로 취급됩니다. 에이전트 요청에 영향을 줄 수는 있지만 독립적으로 권한을 부여할 수는 없습니다. FORTRESS는 자체 정책 경계를 통해 결과 요청을 평가합니다.

질문: MCP를 사용하는 이유는 무엇인가요?

답변:

MCP는 표준화된 도구 상호작용 계층을 제공합니다. FORTRESS는 도구 프로토콜을 재구축하는 대신 도구 실행 주변의 보안 경계에 집중합니다.

질문: 인간 확인을 요구하는 이유는 무엇인가요?

답변:

고위험 작업은 모델이 스스로 승인해서는 안 됩니다. 명시적 확인은 실제 사용자가 통제하는 별도의 권한 부여 경계를 생성합니다.

질문: 기본 거부(default deny)를 사용하는 이유는 무엇인가요?

답변:

보안에 중요한 시스템은 도구나 요청이 명시적으로 차단되지 않았다는 이유만으로 권한을 부여해서는 안 됩니다. 알 수 없거나 충분히 권한이 부여되지 않은 작업은 실패 시 잠금(fail closed)되어야 합니다.

질문: 결정적 정책을 사용하는 이유는 무엇인가요?

답변:

결정적 정책은 설명 가능하고, 테스트 가능하며, 재현 가능하고, 감사 가능합니다. LLM은 의도 해석을 도울 수 있지만 최종 보안 권위자가 되어서는 안 됩니다.

질문: Pytest가 이미 있는데 DeepEval을 사용하는 이유는 무엇인가요?

답변:

Pytest는 결정적 애플리케이션 동작을 검증합니다. DeepEval은 모델/에이전트 동작과 보안 관련 시나리오를 평가합니다. 이들은 서로 다른 테스트 문제를 해결합니다.

질문: Bruno를 사용하는 이유는 무엇인가요?

답변:

Bruno는 외부 API 클라이언트가 하는 것처럼 HTTP 경계를 검증하여 내부 단위 및 통합 테스트를 보완합니다.

질문: SonarQube를 사용하는 이유는 무엇인가요?

답변:

SonarQube는 런타임 테스트와 보안 특화 평가를 보완하는 정적 코드 품질 및 보안 분석을 추가합니다.


40. 제한 사항

FORTRESS-MCP는 의도적으로 엔터프라이즈 IAM 플랫폼이 아닙니다.

다음은 초기 범위에 포함되지 않습니다:

  • 엔터프라이즈 OAuth/OIDC ID 제공자;

  • Kubernetes;

  • 멀티 클라우드 IAM;

  • 복잡한 분산 권한 부여;

  • 엔터프라이즈 비밀 관리;

  • 고급 RAG;

  • 대규모 멀티 에이전트 오케스트레이션;

  • 수십 개의 MCP 도구;

  • 복잡한 데이터베이스 인프라;

  • 대규모 프론트엔드 프레임워크;

  • 불필요한 마이크로서비스.

이들은 향후 확장이 될 수 있지만 핵심 프로젝트에는 필요하지 않습니다.


41. 보안 고지

FORTRESS-MCP는 포트폴리오 수준의 보안 엔지니어링 프로젝트입니다.

보안 아키텍처와 통제를 시연하지만 모든 AI 에이전트 위협에 대한 완전한 엔터프라이즈급 보호를 제공한다고 주장하지는 않습니다.

특히:

  • 프롬프트 인젝션이 완벽하게 해결되었다고 가정할 수 없음;

  • 외부 API가 실패할 수 있음;

  • 모델 동작은 여전히 확률적임;

  • 보안 통제는 적절한 배포 구성이 필요함;

  • 실제 프로덕션 시스템은 더 광범위한 ID, 인프라, 모니터링 및 규정 준수 통제가 필요함.

프로젝트의 보안 주장은 명시적으로 구현되고 테스트된 통제로 제한됩니다.


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단계 — ID + 인증

계획:

  • 에이전트 ID 모델;

  • 인증 경계;

  • 세션 ID;

  • 인증 실패 처리;

  • 결정적 ID 테스트.


4단계 — 권한 부여 + 정책

계획:

  • 권한 모델;

  • 정책 엔진;

  • 허용/거부 결정;

  • 기본 거부;

  • 도구 권한 부여;

  • 권한 부여 테스트.


5단계 — 위험 + 인간 확인

계획:

  • 위험 분류;

  • 확인 요구 사항;

  • 외부 사용자 확인;

  • 확인 거부;

  • 권한 부여 재평가.


6단계 — MCP 게이트웨이 + 도구

계획:

  • MCP 게이트웨이;

  • 도구 레지스트리;

  • 계산기;

  • 날씨;

  • 레코드 업데이트;

  • 민감 작업;

  • 인수 검증;

  • Open-Meteo 실시간 통합.


7단계 — 프롬프트 인젝션 + 감사

계획:

  • 프롬프트 인젝션 시나리오;

  • 신뢰할 수 없는 콘텐츠 경계;

  • 안전한 감사 이벤트;

  • 보안 이벤트 보고.


8단계 — Pytest + DeepEval

계획:

  • 결정적 보안 테스트;

  • 통합 테스트;

  • 적대적 시나리오;

  • DeepEval 평가;

  • 실패 분석.


9단계 — Streamlit + Bruno + SonarQube + CI

계획:

  • 완전한 보안 대시보드;

  • Bruno API 컬렉션;

  • SonarQube 분석;

  • CI 품질 게이트;

  • 보안 테스트 보고.


10단계 — 릴리스

계획:

  • 최종 README;

  • 아키텍처 문서;

  • 보안 보고서;

  • 제한 사항;

  • 테스트 증거;

  • 인터뷰 Q&A;

  • 최종 검증;

  • 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

프로젝트는 불필요하게 큰 엔터프라이즈 플랫폼이 아닌 집중적이고 가치가 높은 구현으로 의도적으로 범위를 유지합니다.


라이선스

최종 릴리스 전에 저장소의 선택된 라이선스를 추가하세요.

F
license - not found
Not graded
quality - not tested
B
maintenance

Maintenance

Maintainers
Response time
Release cycle
Releases (12mo)
Commit activity

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    A security gateway that enforces policies, tracks data taints, and sandboxes tool calls between AI agents and MCP servers. It provides a secure chokepoint to prevent prompt injection and ensure OWASP ASI compliance through audit logging and deterministic execution.
    1
    Apache 2.0
  • A
    license
    Not graded
    quality
    B
    maintenance
    A gateway that enforces permissions, sanitization, approval, and audit for AI agent MCP tool calls, with a policy engine and local proxy CLI.
    310
    1
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    A zero-trust security gateway for MCP tool calls, inspecting tool identity, arguments, execution decisions, and returned content before risk reaches your coding agent.
    Apache 2.0
  • A
    license
    B
    quality
    C
    maintenance
    MCP zero-trust gateway that sits in front of every internal MCP server, detects tool-poisoning/metadata drift in real time, and maintains a cryptographic provenance ledger of every agent tool call.
    20
    2
    ISC

View all related MCP servers

Related MCP Connectors

  • Security firewall for AI agents — scans MCP calls for injection, secrets, and risks.

  • Runtime permission, approval, and audit layer for AI agent tool execution.

  • Six-gate governance for AI agents: PROCEED/PAUSE/HALT decisions with hash-chained audit trails.

View all MCP Connectors

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mayank1532/FORTRESS-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server