FORTRESS-MCP es una puerta de enlace de seguridad zero-trust independiente del proveedor, diseñada para controlar cómo los agentes de IA solicitan y ejecutan herramientas MCP.
El proyecto demuestra un límite de seguridad de estilo productivo entre la intención del agente y la ejecución privilegiada de herramientas.
Un agente de IA puede solicitar una acción, pero el agente no autoriza ni ejecuta de forma independiente acciones privilegiadas.
Related MCP server: mcp-guardian
Los agentes de IA modernos pueden llamar a herramientas, APIs, sistemas de archivos, bases de datos y servicios externos. El problema de seguridad ya no es solo:
"¿Puede el modelo generar la respuesta correcta?"
También es:
"¿Se puede confiar en que el modelo decida qué acciones está autorizado a ejecutar?"
FORTRESS-MCP aborda este problema separando:
Agent Intent
↓
Identity
↓
Authentication
↓
Authorization
↓
Policy Decision
↓
Risk Classification
↓
Human Confirmation
↓
Argument Validation
↓
MCP Tool Execution
↓
AuditPor lo tanto, el LLM no es la autoridad de seguridad.
FORTRESS-MCP está diseñado para demostrar:
Ejecución de herramientas de agentes de IA con zero-trust.
Autorización con privilegio mínimo.
Seguridad de denegación por defecto.
Decisiones de política deterministas.
Clasificación de riesgo.
Confirmación humana para acciones sensibles.
Ejecución de herramientas basada en MCP.
Contención de inyección de prompts.
Validación de herramientas y argumentos.
Registro de auditoría seguro.
Pruebas de seguridad de API.
Evaluación de seguridad de agentes.
Análisis estático de seguridad.
Prácticas de ingeniería de estilo productivo.
El proyecto está diseñado intencionalmente para ser:
orientado a la industria;
apto para entrevistas;
impactante para el portafolio;
independiente del proveedor;
técnicamente profundo;
lo suficientemente simple para entenderlo y mantenerlo.
La regla de diseño central es:
Agent Intent
≠
Security Decision
≠
Tool ExecutionEl agente puede solicitar una acción.
FORTRESS decide si la acción está permitida.
Solo después de que la puerta de seguridad tenga éxito puede ejecutarse la herramienta MCP.
┌──────────────────────┐
│ 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
│
▼
AUDITFORTRESS define límites de confianza explícitos.
Las solicitudes del agente son entrada no confiable.
El agente no recibe permiso automáticamente solo porque generó la solicitud.
Solo las solicitudes autorizadas y validadas pueden cruzar el límite de ejecución.
La ejecución externa está controlada y es auditable.
Los datos externos son datos no confiables.
Los datos externos nunca otorgan autorización.
La autorización sensible debe originarse en la interfaz de usuario real.
El LLM no puede confirmar su propia solicitud.
Cada operación protegida sigue esta canalización conceptual:
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 resultLa implementación exacta es intencionalmente determinista.
La identidad representa al actor que solicita una operación.
Conceptualmente:
AgentIdentity
├── agent_id
├── role
├── permissions
├── trust_level
└── session_idLa autenticación responde:
¿Quién eres?
La autorización responde:
¿Tienes permitido realizar esta acción?
Estos son conceptos intencionalmente separados.
FORTRESS utiliza un modelo de permisos deliberadamente pequeño:
READ
WRITE
SENSITIVEEsto es suficiente para demostrar el privilegio mínimo sin introducir complejidad innecesaria de IAM empresarial.
La capa de política produce una de tres decisiones:
ALLOW
DENY
REQUIRE_CONFIRMATIONComportamiento por defecto:
Unknown
↓
DENYEl motor de políticas es lógica de aplicación.
No se delega en el LLM.
FORTRESS utiliza tres niveles de riesgo:
LOW
MEDIUM
HIGHMapeo conceptual inicial:
Herramienta / Acción | Permiso | Riesgo |
| READ | LOW |
| READ | MEDIUM |
| WRITE | HIGH |
| SENSITIVE | HIGH |
La clasificación de riesgo es determinista y explicable.
Las operaciones de alto riesgo pueden requerir confirmación humana explícita.
El flujo de seguridad es:
Agent Request
↓
FORTRESS
↓
HIGH RISK
↓
REQUIRE_CONFIRMATION
↓
Actual User
↓
Confirm / Reject
↓
FORTRESS Re-evaluation
↓
ALLOW / DENY
↓
MCP ExecutionUna regla de seguridad crítica es:
El LLM no puede generar ni simular la confirmación del usuario.
MCP proporciona la capa de interacción de herramientas estandarizada.
FORTRESS rodea a MCP con el límite de seguridad.
Conceptualmente:
Agent
↓
FORTRESS Security Gateway
↓
MCP
↓
ToolFORTRESS no intenta reemplazar a MCP.
En su lugar, demuestra cómo la ejecución de herramientas MCP puede colocarse detrás de una puerta de enlace de seguridad determinista.
El proyecto limita intencionalmente la superficie inicial de herramientas.
calculator_readPropósito:
cálculo local determinista;
operación de estilo lectura de bajo riesgo;
útil para pruebas de autorización de referencia.
weather_lookupPropósito:
recuperar datos meteorológicos en vivo;
demostrar acceso controlado a una API externa;
demostrar que los datos externos son entrada no confiable.
update_recordPropósito:
demostrar una operación de escritura;
demostrar autorización de mayor riesgo;
demostrar la aplicación de políticas.
sensitive_actionPropósito:
demostrar operaciones sensibles;
requerir confirmación explícita;
demostrar las rutas de denegación y confirmación.
El conjunto reducido de herramientas es deliberado.
El proyecto prioriza la profundidad de seguridad sobre la cantidad de herramientas.
FORTRESS utiliza Open-Meteo como el proveedor inicial gratuito de datos en vivo para la consulta meteorológica.
Conceptualmente:
Agent
↓
FORTRESS
↓
Authorization
↓
Argument Validation
↓
MCP Weather Tool
↓
Open-Meteo
↓
Weather Result
↓
AuditEl proveedor externo sigue siendo reemplazable.
El límite de seguridad no depende del proveedor.
Un principio de diseño crítico es:
External Data
≠
AuthorizationLas respuestas meteorológicas, las respuestas de API, los documentos y otros contenidos externos pueden contener texto malicioso o similar a instrucciones.
Dicho contenido no puede otorgar permiso.
La autorización la determina la política de FORTRESS.
Los argumentos de las herramientas se validan antes de la ejecución.
Por ejemplo, las coordenadas meteorológicas deben cumplir:
latitude:
-90 ≤ latitude ≤ +90
longitude:
-180 ≤ longitude ≤ +180Los argumentos no válidos deben rechazarse antes de que se ejecute la solicitud externa.
Esto protege tanto a la herramienta como al límite del servicio externo.
FORTRESS no afirma que la inyección de prompts pueda eliminarse perfectamente.
En su lugar, el proyecto demuestra una propiedad de seguridad más sólida:
La inyección de prompts no puede otorgar autorización de forma independiente.
Conceptualmente:
Malicious Prompt / External Content
↓
Agent Request
↓
FORTRESS Policy
↓
DENY / CONFIRMEl contenido no confiable sigue siendo no confiable.
Cada decisión de seguridad importante debe producir un evento de auditoría.
Los campos de auditoría conceptuales incluyen:
timestamp
session_id
agent_id
tool
action
risk_level
policy_decision
reason
confirmation_required
execution_status
safe_argument_summaryEl sistema de auditoría debe evitar exponer secretos.
El rastro de auditoría debe responder:
WHO
WHAT
WHEN
WHY
RISK
DECISION
EXECUTIONStreamlit proporciona la interfaz de usuario interactiva.
La interfaz está pensada para hacer visible el comportamiento de seguridad y facilitar su demostración.
El panel mostrará conceptos como:
identidad actual del agente;
acción solicitada;
herramienta solicitada;
permisos;
nivel de riesgo;
decisión de política;
requisito de confirmación;
estado de ejecución;
resultado de la herramienta;
eventos de auditoría.
La aplicación Streamlit no es la autoridad de seguridad.
Las decisiones de seguridad pertenecen al núcleo de FORTRESS.
Esta separación hace que el sistema sea comprobable tanto a través de la interfaz de usuario como de la API.
FORTRESS expone una API HTTP pequeña.
La API proporciona una interfaz compartida para:
Streamlit
│
├──────────────┐
│ │
▼ ▼
FORTRESS API ←── Bruno
│
▼
Security GatewayEsto permite probar el backend de forma independiente de la interfaz de usuario.
Bruno se utiliza para pruebas de seguridad a nivel de API.
Los escenarios planificados incluyen:
Endpoint de salud.
Fallo de autenticación.
Éxito de autenticación.
Solicitud autorizada.
Solicitud no autorizada.
Argumentos de herramienta no válidos.
Confirmación requerida.
Denegación de acción sensible.
Casos límite de la política de seguridad.
Comportamiento de respuesta de error.
Bruno complementa a Pytest probando el límite HTTP desde la perspectiva de un cliente de API.
DeepEval se utiliza para la evaluación del comportamiento de agentes relevante para la seguridad.
Puede utilizarse para evaluar escenarios como:
intentos de inyección de prompts;
solicitudes de herramientas no autorizadas;
comportamiento en los límites de la política;
manejo de acciones sensibles;
comportamiento de rechazo;
restricciones de uso de herramientas.
DeepEval es un marco de evaluación.
No reemplaza al motor de autorización determinista.
La arquitectura sigue siendo:
Deterministic Security
+
Behavioral EvaluationSe utiliza un análisis compatible con SonarQube Free/Community para la revisión estática de calidad de código y seguridad.
El proyecto lo utilizará para identificar:
errores;
vulnerabilidades;
puntos críticos de seguridad;
olores de código;
problemas de mantenibilidad;
visibilidad de pruebas/cobertura donde esté configurado.
SonarQube es una capa de análisis de calidad/seguridad.
No reemplaza las pruebas de seguridad en tiempo de ejecución.
FORTRESS utiliza múltiples capas de pruebas.
Pruebas rápidas y deterministas para:
identidad;
permisos;
autorización;
política;
riesgo;
validación;
auditoría;
comportamiento de las herramientas.
Pruebas para:
API + puerta de enlace de seguridad;
límite de MCP;
adaptador de API externa;
flujo de confirmación.
Bruno valida el comportamiento HTTP.
DeepEval evalúa el comportamiento de los agentes relevante para la seguridad.
SonarQube analiza la calidad del código y los problemas de seguridad.
Ruff.
Mypy.
GitHub Actions ejecuta las compuertas de calidad automatizadas.
El proyecto utiliza:
Python 3.12
↓
UV
↓
Pydantic
↓
FastAPI
↓
MCP
↓
Streamlit
↓
Pytest
↓
Ruff
↓
Mypy
↓
Bruno
↓
DeepEval
↓
SonarQube
↓
GitHub Actions
↓
DockerLa pila es intencionalmente moderna pero controlada.
Estructura actual y planificada:
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.mdLa estructura solo crecerá cuando se implemente la capacidad de seguridad correspondiente.
Windows/Linux/macOS
Python 3.12
UV
Git
Docker (para validación de contenedores)
Bruno (para pruebas de API)
Configuración compatible con SonarQube Community/Free para análisis estático
Las integraciones opcionales de modelos/APIs deben utilizar variables de entorno seguras.
Ningún secreto debe estar en Git.
Desde la raíz del repositorio:
uv syncEjecutar comandos a través del entorno UV:
uv run pytestuv run ruff check .uv run mypy srcEl punto de entrada de la API es:
fortress_mcp.api.app:appEjecutar:
uv run uvicorn fortress_mcp.api.app:app --reloadEndpoint de salud:
GET /healthRespuesta conceptual esperada:
{
"service": "fortress-mcp",
"status": "ok"
}Ejecutar:
uv run streamlit run src/fortress_mcp/streamlit_app.pyLa interfaz de Streamlit es el Centro de control de seguridad.
A medida que se implementen las fases posteriores, expondrá:
Identity
Permissions
Request
Risk
Policy
Confirmation
Execution
AuditConstruir:
docker build -t fortress-mcp .Ejecutar:
docker run --rm -p 8000:8000 fortress-mcpEl contenedor expone el puerto:
8000El flujo de trabajo de desarrollo es:
Understand
↓
Design
↓
Implement
↓
Test
↓
Lint
↓
Type Check
↓
Security Analysis
↓
API Evaluation
↓
CommitCada hito significativo recibe un punto de control en Git.
FORTRESS-MCP sigue una estrategia de ingeniería de reutilización primero.
El proyecto no clona ciegamente aplicaciones anteriores.
En su lugar:
Existing Proven Infrastructure
↓
Verify
↓
Select
↓
Adapt
↓
Remove Unused
↓
Implement FORTRESS Security LogicUtilizado como referencia principal para:
estructura de MCP;
contratos de herramientas;
conceptos de registro de MCP;
límites de ejecución de herramientas;
patrones de adaptadores de API en vivo;
contratos de Pydantic.
Utilizado como referencia para:
UV;
Python 3.12;
gestión de dependencias;
Ruff;
Mypy;
Pytest;
GitHub Actions;
Docker;
patrones de SonarQube.
Utilizado como referencia de apoyo para:
patrones HTTP/API;
Pydantic;
enfoques de pruebas.
La lógica de negocio específica del proyecto y la lógica específica del proveedor no se copian ciegamente.
FORTRESS debe mantener estos invariantes:
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.Estos invariantes son más importantes que cualquier marco individual.
FORTRESS debe fallar de forma segura.
Ejemplos:
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 ClosedEl sistema nunca debe interpretar un fallo interno como autorización.
Los eventos de seguridad deben ser observables.
Los campos útiles incluyen:
timestamp
agent_id
session_id
tool
action
permission
risk
decision
reason
confirmation
execution_statusLos registros deben ser:
estructurados;
buscables;
seguros;
mínimos;
útiles para el análisis de incidentes.
Los valores sensibles deben redactarse.
FORTRESS utiliza un modelo de seguridad por capas:
┌───────────────────────┐
│ Agent / LLM │
└───────────┬───────────┘
│
▼
┌───────────────────────┐
│ Identity │
└───────────┬───────────┘
▼
┌───────────────────────┐
│ Authentication │
└───────────┬───────────┘
▼
┌───────────────────────┐
│ Authorization │
└───────────┬───────────┘
▼
┌───────────────────────┐
│ Policy │
└───────────┬───────────┘
▼
┌───────────────────────┐
│ Risk │
└───────────┬───────────┘
▼
┌───────────────────────┐
│ Confirmation │
└───────────┬───────────┘
▼
┌───────────────────────┐
│ Validation │
└───────────┬───────────┘
▼
┌───────────────────────┐
│ MCP │
└───────────┬───────────┘
▼
┌───────────────────────┐
│ Tool │
└───────────┬───────────┘
▼
┌───────────────────────┐
│ Audit │
└───────────────────────┘Muchos proyectos de IA generativa se centran en:
Prompt
↓
LLM
↓
AnswerFORTRESS se centra en:
Intent
↓
Security Boundary
↓
Decision
↓
Controlled ExecutionEsto transforma el proyecto de una demostración típica de IA generativa en un proyecto de ingeniería de seguridad de IA.
El valor para el portafolio proviene de demostrar que el candidato comprende:
Agentes de IA;
MCP;
llamadas a herramientas;
diseño de API;
autenticación;
autorización;
motores de políticas;
mínimo privilegio;
límites de seguridad;
inyección de instrucciones;
seguridad con intervención humana;
observabilidad;
pruebas;
DevSecOps.
FORTRESS está diseñado para respaldar debates sólidos en entrevistas.
Respuesta:
La salida del LLM es una entrada de aplicación no confiable. La autorización es una decisión de seguridad, por lo que debe aplicarse de manera determinista fuera del modelo.
Respuesta:
La inyección de instrucciones se trata como una entrada no confiable. Puede influir en la solicitud del agente, pero no puede otorgar autorización de forma independiente. FORTRESS evalúa la solicitud resultante a través de su propio límite de políticas.
Respuesta:
MCP proporciona una capa estandarizada de interacción con herramientas. FORTRESS se centra en el límite de seguridad alrededor de la ejecución de herramientas en lugar de reconstruir el protocolo de herramientas.
Respuesta:
Las acciones de alto riesgo no deberían ser autorizadas automáticamente por el modelo. La confirmación explícita crea un límite de autorización separado controlado por el usuario real.
Respuesta:
Los sistemas de seguridad críticos no deberían otorgar permisos simplemente porque una herramienta o solicitud no fue bloqueada explícitamente. Las acciones desconocidas o insuficientemente autorizadas deberían fallar de forma segura.
Respuesta:
La política determinista es explicable, comprobable, reproducible y auditable. Un LLM puede ayudar con la interpretación de la intención, pero no debería ser la autoridad de seguridad final.
Respuesta:
Pytest valida el comportamiento determinista de la aplicación. DeepEval evalúa el comportamiento del modelo/agente y los escenarios relevantes para la seguridad. Resuelven diferentes problemas de prueba.
Respuesta:
Bruno valida el límite HTTP como lo haría un cliente de API externo, complementando las pruebas unitarias y de integración internas.
Respuesta:
SonarQube añade análisis estático de calidad de código y seguridad que complementa las pruebas de ejecución y las evaluaciones de seguridad específicas.
FORTRESS-MCP no es intencionadamente una plataforma de IAM empresarial.
Lo siguiente queda fuera del alcance inicial:
proveedor de identidad OAuth/OIDC empresarial;
Kubernetes;
IAM multinube;
autorización distribuida compleja;
gestión de secretos empresarial;
RAG avanzado;
orquestación de múltiples agentes a gran escala;
docenas de herramientas MCP;
infraestructura de base de datos compleja;
framework de frontend grande;
microservicios innecesarios.
Estos pueden ser extensiones futuras, pero no son necesarios para el proyecto principal.
FORTRESS-MCP es un proyecto de ingeniería de seguridad de nivel de portafolio.
Demuestra arquitectura y controles de seguridad, pero no pretende proporcionar una protección completa de nivel empresarial contra todas las amenazas de los agentes de IA.
En particular:
no se puede asumir que la inyección de instrucciones esté perfectamente resuelta;
las API externas pueden fallar;
el comportamiento del modelo sigue siendo probabilístico;
los controles de seguridad requieren una configuración de implementación adecuada;
los sistemas de producción reales requieren controles de identidad, infraestructura, monitoreo y cumplimiento más amplios.
Las afirmaciones de seguridad del proyecto se limitan a los controles que se implementan y prueban explícitamente.
Estado:
COMPLETEEntregado:
modelo de amenazas;
arquitectura de seguridad;
invariantes de seguridad;
bloqueo de alcance;
decisiones de proyecto.
Punto de control de Git:
92e3d81
docs: establish phase 1 security foundationEstado:
IN PROGRESSEntregado hasta ahora:
proyecto UV;
Python 3.12;
estructura de paquetes;
base de FastAPI;
dependencia MCP;
shell de Streamlit;
base de Pytest;
Ruff;
Mypy;
base de GitHub Actions;
base de Docker;
configuración de SonarQube;
estructura de Bruno;
dependencia de DeepEval;
documentación de decisión de reutilización.
Planificado:
modelo de identidad del agente;
límite de autenticación;
identidad de sesión;
manejo de errores de autenticación;
pruebas de identidad deterministas.
Planificado:
modelo de permisos;
motor de políticas;
decisiones de permitir/denegar;
denegar por defecto;
autorización de herramientas;
pruebas de autorización.
Planificado:
clasificación de riesgos;
requisito de confirmación;
confirmación del usuario externo;
rechazo de confirmación;
reevaluación de la autorización.
Planificado:
puerta de enlace MCP;
registro de herramientas;
calculadora;
clima;
registro de actualización;
acción sensible;
validación de argumentos;
integración en vivo de Open-Meteo.
Planificado:
escenarios de inyección de instrucciones;
límite de contenido no confiable;
eventos de auditoría seguros;
informes de eventos de seguridad.
Planificado:
pruebas de seguridad deterministas;
pruebas de integración;
escenarios adversarios;
evaluación de DeepEval;
análisis de fallos.
Planificado:
panel de seguridad completo;
colección de API de Bruno;
análisis de SonarQube;
puertas de calidad de CI;
informes de pruebas de seguridad.
Planificado:
README final;
documentación de arquitectura;
informe de seguridad;
limitaciones;
evidencia de pruebas;
preguntas y respuestas de la entrevista;
validación final;
punto de control de lanzamiento de Git.
FORTRESS-MCP está completo cuando:
[ ] 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 completeEl concepto más importante en FORTRESS-MCP es:
The model proposes.
The security gateway decides.
The MCP layer executes.
The audit layer records.Esa separación es el núcleo del proyecto.
Hito actual del proyecto:
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 ░░░░░░░░░░░░░░░░░░░░ PENDINGEl proyecto sigue teniendo un alcance deliberadamente limitado a una implementación centrada y de alto valor, en lugar de una plataforma empresarial innecesariamente grande.
Añada la licencia seleccionada del repositorio antes de la versión final.
This server cannot be installed
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
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