FORTRESS-MCP

Zero-Trust Security Gateway for AI-Agent Tool Execution

FORTRESS-MCP is a provider-neutral, zero-trust security gateway designed to control how AI agents request and execute MCP tools.

The project demonstrates a production-style security boundary between agent intent and privileged tool execution.

An AI agent may request an action, but the agent does not independently authorize or execute privileged actions.

Related MCP server: mcp-guardian

1. Why FORTRESS-MCP?

Modern AI agents can call tools, APIs, filesystems, databases, and external services. The security problem is no longer only:

"Can the model generate the correct answer?"

It is also:

"Can the model be trusted to decide which actions it is allowed to execute?"

FORTRESS-MCP addresses this problem by separating:

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

The LLM is therefore not the security authority.

2. Project Goals

FORTRESS-MCP is designed to demonstrate:

• Zero-trust AI-agent tool execution.

• Least-privilege authorization.

• Default-deny security.

• Deterministic policy decisions.

• Risk classification.

• Human confirmation for sensitive actions.

• MCP-based tool execution.

• Prompt-injection containment.

• Tool and argument validation.

• Safe audit logging.

• API security testing.

• Agent-security evaluation.

• Static security analysis.

• Production-style engineering practices.

The project is intentionally designed to be:

• industry-oriented;

• interview-friendly;

• portfolio-impactful;

• provider-neutral;

• technically deep;

• simple enough to understand and maintain.

3. Core Security Principle

The central design rule is:

Agent Intent
    ≠
Security Decision
    ≠
Tool Execution

The agent can request an action.

FORTRESS decides whether the action is permitted.

Only after the security gate succeeds can the MCP tool execute.

4. High-Level Architecture

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

FORTRESS defines explicit trust boundaries.

Agent → FORTRESS

Agent requests are untrusted input.

The agent does not automatically receive permission simply because it generated the request.

FORTRESS → MCP

Only authorized, validated requests may cross the execution boundary.

MCP → External Tool

External execution is controlled and auditable.

External Data → Agent

External data is untrusted data.

External data never grants authorization.

Human Confirmation

Sensitive authorization must originate from the actual user interface.

The LLM cannot confirm its own request.

6. Security Decision Pipeline

Every protected operation follows this conceptual 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

The exact implementation is intentionally deterministic.

7. Identity

Identity represents the actor requesting an operation.

Conceptually:

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

Authentication answers:

Who are you?

Authorization answers:

Are you allowed to perform this action?

These are intentionally separate concepts.

8. Permissions

FORTRESS uses a deliberately small permission model:

READ
WRITE
SENSITIVE

This is sufficient to demonstrate least privilege without introducing unnecessary enterprise IAM complexity.

9. Policy Decisions

The policy layer produces one of three decisions:

ALLOW
DENY
REQUIRE_CONFIRMATION

Default behavior:

Unknown
    ↓
DENY

The policy engine is application logic.

It is not delegated to the LLM.

10. Risk Classification

FORTRESS uses three risk levels:

LOW
MEDIUM
HIGH

Initial conceptual mapping:

Risk classification is deterministic and explainable.

11. Human Confirmation

High-risk operations can require explicit human confirmation.

The security flow is:

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

A critical security rule is:

The LLM cannot generate or simulate the user's confirmation.

12. MCP

MCP provides the standardized tool interaction layer.

FORTRESS surrounds MCP with the security boundary.

Conceptually:

Agent
  ↓
FORTRESS Security Gateway
  ↓
MCP
  ↓
Tool

FORTRESS does not attempt to replace MCP.

Instead, it demonstrates how MCP tool execution can be placed behind a deterministic security gateway.

13. Initial Tool Set

The project intentionally limits the initial tool surface.

calculator_read

Purpose:

• deterministic local calculation;

• low-risk read-style operation;

• useful for baseline authorization testing.

weather_lookup

Purpose:

• retrieve live weather data;

• demonstrate controlled external API access;

• demonstrate external data as untrusted input.

update_record

Purpose:

• demonstrate a write operation;

• demonstrate higher-risk authorization;

• demonstrate policy enforcement.

sensitive_action

Purpose:

• demonstrate sensitive operations;

• require explicit confirmation;

• demonstrate denial and confirmation paths.

The small tool set is deliberate.

The project prioritizes security depth over tool quantity.

14. Live Data API

FORTRESS uses Open-Meteo as the initial free live-data provider for weather lookup.

Conceptually:

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

The external provider remains replaceable.

The security boundary does not depend on the provider.

15. External Data Is Untrusted

A critical design principle is:

External Data
      ≠
Authorization

Weather responses, API responses, documents, and other external content may contain malicious or instruction-like text.

Such content cannot grant permission.

Authorization is determined by FORTRESS policy.

16. Argument Validation

Tool arguments are validated before execution.

For example, weather coordinates must satisfy:

latitude:
    -90 ≤ latitude ≤ +90

longitude:
    -180 ≤ longitude ≤ +180

Invalid arguments must be rejected before the external request is executed.

This protects both the tool and the external service boundary.

17. Prompt Injection Boundary

FORTRESS does not claim that prompt injection can be eliminated perfectly.

Instead, the project demonstrates a stronger security property:

Prompt injection cannot independently grant authorization.

Conceptually:

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

Untrusted content remains untrusted.

18. Auditability

Every important security decision should produce an audit event.

Conceptual audit fields include:

timestamp
session_id
agent_id
tool
action
risk_level
policy_decision
reason
confirmation_required
execution_status
safe_argument_summary

The audit system must avoid exposing secrets.

The audit trail should answer:

WHO
WHAT
WHEN
WHY
RISK
DECISION
EXECUTION

19. Streamlit Security Control Center

Streamlit provides the interactive UI.

The UI is intended to make the security behavior visible and easy to demonstrate.

The dashboard will show concepts such as:

• current agent identity;

• requested action;

• requested tool;

• permissions;

• risk level;

• policy decision;

• confirmation requirement;

• execution status;

• tool result;

• audit events.

The Streamlit application is not the security authority.

Security decisions belong to the FORTRESS core.

This separation makes the system testable through both UI and API.

20. HTTP API

FORTRESS exposes a small HTTP API.

The API provides a shared interface for:

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

This makes it possible to test the backend independently from the UI.

21. Bruno API Testing

Bruno is used for API-level security testing.

The planned scenarios include:

1. Health endpoint.

2. Authentication failure.

3. Authentication success.

4. Authorized request.

5. Unauthorized request.

6. Invalid tool arguments.

7. Confirmation required.

8. Sensitive action denial.

9. Security-policy boundary cases.

10. Error response behavior.

Bruno complements Pytest by testing the HTTP boundary from the perspective of an API client.

22. DeepEval

DeepEval is used for evaluation of security-relevant agent behavior.

It can be used to evaluate scenarios such as:

• prompt-injection attempts;

• unauthorized tool requests;

• policy-boundary behavior;

• sensitive-action handling;

• refusal behavior;

• tool-use constraints.

DeepEval is an evaluation framework.

It does not replace the deterministic authorization engine.

The architecture remains:

Deterministic Security
        +
Behavioral Evaluation

23. SonarQube

SonarQube Free/Community-compatible analysis is used for static code-quality and security review.

The project will use it to identify:

• bugs;

• vulnerabilities;

• security hotspots;

• code smells;

• maintainability problems;

• test/coverage visibility where configured.

SonarQube is a quality/security analysis layer.

It does not replace runtime security testing.

24. Testing Strategy

FORTRESS uses multiple testing layers.

Unit Tests

Fast deterministic tests for:

• identity;

• permissions;

• authorization;

• policy;

• risk;

• validation;

• audit;

• tool behavior.

Integration Tests

Tests for:

• API + security gateway;

• MCP boundary;

• external API adapter;

• confirmation workflow.

API Tests

Bruno validates HTTP behavior.

Behavioral Evaluation

DeepEval evaluates security-relevant agent behavior.

Static Analysis

SonarQube analyzes code quality and security issues.

Linting

Ruff.

Type Checking

Mypy.

CI

GitHub Actions runs the automated quality gates.

25. Engineering Quality Stack

The project uses:

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

The stack is intentionally modern but controlled.

26. Project Structure

Current and planned structure:

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

The structure will grow only when the corresponding security capability is implemented.

27. Installation

Requirements

• Windows/Linux/macOS

• Python 3.12

• UV

• Git

• Docker (for container validation)

• Bruno (for API testing)

• SonarQube Community/Free-compatible setup for static analysis

Optional model/API integrations must use secure environment variables.

No secrets belong in Git.

28. Install with UV

From the repository root:

uv sync

Run commands through the UV environment:

uv run pytest

uv run ruff check .

uv run mypy src

29. Run the API

The API entry point is:

fortress_mcp.api.app:app

Run:

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

Health endpoint:

GET /health

Expected conceptual response:

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

30. Run Streamlit

Run:

uv run streamlit run src/fortress_mcp/streamlit_app.py

The Streamlit UI is the Security Control Center.

As later phases are implemented, it will expose:

Identity
Permissions
Request
Risk
Policy
Confirmation
Execution
Audit

31. Docker

Build:

docker build -t fortress-mcp .

Run:

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

The container exposes port:

8000

32. Development Workflow

The development workflow is:

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

Each meaningful milestone receives a Git checkpoint.

33. Reuse Strategy

FORTRESS-MCP follows a reuse-first engineering strategy.

The project does not blindly clone previous applications.

Instead:

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

TOOLFORGE

Used as a primary reference for:

• MCP structure;

• tool contracts;

• MCP registry concepts;

• tool execution boundaries;

• live API adapter patterns;

• Pydantic contracts.

NEXUS-SHIELD

Used as a reference for:

• UV;

• Python 3.12;

• dependency management;

• Ruff;

• Mypy;

• Pytest;

• GitHub Actions;

• Docker;

• SonarQube patterns.

WEBPULSE

Used as a supporting reference for:

• HTTP/API patterns;

• Pydantic;

• testing approaches.

Project-specific business logic and provider-specific logic are not blindly copied.

34. Security Invariants

FORTRESS should maintain these invariants:

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.

These invariants are more important than any individual framework.

35. Failure Handling

FORTRESS should fail safely.

Examples:

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

The system must never interpret an internal failure as authorization.

36. Observability

Security events should be observable.

Useful fields include:

timestamp
agent_id
session_id
tool
action
permission
risk
decision
reason
confirmation
execution_status

The logs should be:

• structured;

• searchable;

• safe;

• minimal;

• useful for incident analysis.

Sensitive values should be redacted.

37. Security Model

FORTRESS uses a layered security model:

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

38. What Makes This Project Different?

Many GenAI projects focus on:

Prompt
  ↓
LLM
  ↓
Answer

FORTRESS focuses on:

Intent
  ↓
Security Boundary
  ↓
Decision
  ↓
Controlled Execution

This changes the project from a typical GenAI demonstration into an AI security engineering project.

The portfolio value comes from demonstrating that the candidate understands:

• AI agents;

• MCP;

• tool calling;

• API design;

• authentication;

• authorization;

• policy engines;

• least privilege;

• security boundaries;

• prompt injection;

• human-in-the-loop security;

• observability;

• testing;

• DevSecOps.

39. Interview Value

FORTRESS is designed to support strong interview discussions.

Question: Why isn't the LLM allowed to authorize itself?

Answer:

LLM output is untrusted application input. Authorization is a security decision, so it must be enforced deterministically outside the model.

Question: How do you handle prompt injection?

Answer:

Prompt injection is treated as untrusted input. It may influence the agent request, but it cannot independently grant authorization. FORTRESS evaluates the resulting request through its own policy boundary.

Question: Why use MCP?

Answer:

MCP provides a standardized tool interaction layer. FORTRESS focuses on the security boundary around tool execution rather than rebuilding the tool protocol.

Question: Why require human confirmation?

Answer:

High-risk actions should not be self-authorized by the model. Explicit confirmation creates a separate authorization boundary controlled by the actual user.

Question: Why default deny?

Answer:

Security-critical systems should not grant permissions merely because a tool or request was not explicitly blocked. Unknown or insufficiently authorized actions should fail closed.

Question: Why use deterministic policy?

Answer:

Deterministic policy is explainable, testable, reproducible, and auditable. An LLM can assist with intent interpretation, but it should not be the final security authority.

Question: Why use DeepEval if Pytest already exists?

Answer:

Pytest validates deterministic application behavior. DeepEval evaluates model/agent behavior and security-relevant scenarios. They solve different testing problems.

Question: Why use Bruno?

Answer:

Bruno validates the HTTP boundary as an external API client would, complementing internal unit and integration tests.

Question: Why SonarQube?

Answer:

SonarQube adds static code-quality and security analysis that complements runtime tests and security-specific evaluations.

40. Limitations

FORTRESS-MCP is intentionally not an enterprise IAM platform.

The following are outside the initial scope:

• enterprise OAuth/OIDC identity provider;

• Kubernetes;

• multi-cloud IAM;

• complex distributed authorization;

• enterprise secrets management;

• advanced RAG;

• large multi-agent orchestration;

• dozens of MCP tools;

• complex database infrastructure;

• large frontend framework;

• unnecessary microservices.

These may be future extensions but are not required for the core project.

41. Security Disclaimer

FORTRESS-MCP is a portfolio-grade security engineering project.

It demonstrates security architecture and controls but does not claim to provide complete enterprise-grade protection against every AI-agent threat.

In particular:

• prompt injection cannot be assumed to be perfectly solved;

• external APIs may fail;

• model behavior remains probabilistic;

• security controls require appropriate deployment configuration;

• real production systems require broader identity, infrastructure, monitoring, and compliance controls.

The project's security claims are limited to the controls that are explicitly implemented and tested.

42. Development Roadmap

Phase 1 — Threat Model + Security Architecture

Status:

COMPLETE

Delivered:

• threat model;

• security architecture;

• security invariants;

• scope lock;

• project decisions.

Git checkpoint:

92e3d81
docs: establish phase 1 security foundation

Phase 2 — Verified Infrastructure Reuse

Status:

IN PROGRESS

Delivered so far:

• UV project;

• Python 3.12;

• package structure;

• FastAPI foundation;

• MCP dependency;

• Streamlit shell;

• Pytest foundation;

• Ruff;

• Mypy;

• GitHub Actions foundation;

• Docker foundation;

• SonarQube configuration;

• Bruno structure;

• DeepEval dependency;

• reuse decision documentation.

Phase 3 — Identity + Authentication

Planned:

• agent identity model;

• authentication boundary;

• session identity;

• authentication failure handling;

• deterministic identity tests.

Phase 4 — Authorization + Policy

Planned:

• permission model;

• policy engine;

• allow/deny decisions;

• default deny;

• tool authorization;

• authorization tests.

Phase 5 — Risk + Human Confirmation

Planned:

• risk classification;

• confirmation requirement;

• external user confirmation;

• confirmation rejection;

• authorization re-evaluation.

Phase 6 — MCP Gateway + Tools

Planned:

• MCP gateway;

• tool registry;

• calculator;

• weather;

• update record;

• sensitive action;

• argument validation;

• Open-Meteo live integration.

Phase 7 — Prompt Injection + Audit

Planned:

• prompt-injection scenarios;

• untrusted-content boundary;

• safe audit events;

• security event reporting.

Phase 8 — Pytest + DeepEval

Planned:

• deterministic security tests;

• integration tests;

• adversarial scenarios;

• DeepEval evaluation;

• failure analysis.

Phase 9 — Streamlit + Bruno + SonarQube + CI

Planned:

• complete security dashboard;

• Bruno API collection;

• SonarQube analysis;

• CI quality gates;

• security test reporting.

Phase 10 — Release

Planned:

• final README;

• architecture documentation;

• security report;

• limitations;

• test evidence;

• interview Q&A;

• final validation;

• Git release checkpoint.

43. Definition of Done

FORTRESS-MCP is complete when:

[ ] 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. Final Architecture Principle

The most important concept in FORTRESS-MCP is:

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

That separation is the core of the project.

45. Project Status

Current project milestone:

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

The project remains intentionally scoped to a focused, high-value implementation rather than an unnecessarily large enterprise platform.

License

Add the repository's selected license before final release.