Gobernanza y riesgo MCP de OWASP: ¿dejar entrar ese servidor?

Los agentes de IA se conectan a sistemas reales a toda velocidad, y el conector que hace ese cableado es el Model Context Protocol (MCP). Un servidor MCP puede permitir que un agente lea vuestras wikis, abra pull requests, publique en Slack y dispare flujos de producción, muchas veces sin que un humano vea cada paso. El proyecto OWASP MCP Governance & Risk existe para responder la única pregunta que importa antes de conectar uno: ¿debe permitirse este servidor en nuestro entorno y bajo qué controles?

Cuatro puertas antes de cualquier puntuación

La idea más afilada del marco es que ciertas cosas no se negocian. Antes de ponderar un solo factor de riesgo, deben superarse cuatro puertas, y el fallo de cualquiera bloquea la aprobación por sí solo. Puedes recorrer esta misma lógica de puertas con la herramienta de gobernanza de servidores MCP antes de firmar nada.

• Sin propietario, no hay aprobación. Cada servidor tiene un responsable nombrado y rendible de cuentas, o no se despliega.
• Sin registro, no hay producción. Una traza de auditoría de cada acción es obligatoria en producción.
• Sin alcance definido, no hay acceso. Los datos que puede leer y las acciones que puede ejecutar quedan documentados.
• Sin revisión, no hay despliegue empresarial. La aprobación no es un evento único: se programa una revisión periódica del nivel de riesgo.

Clasificar: del Nivel 0 al Nivel 4

No todos los servidores MCP suponen el mismo riesgo, así que el marco clasifica cada uno en uno de cinco niveles, y el listón sube a medida que se asciende: el Nivel 0 es lectura de datos públicos; el Nivel 1, lectura interna no sensible; el Nivel 2, lectura sensible; el Nivel 3, capacidad de escritura; y el Nivel 4, privilegiado o crítico. Un servidor de búsqueda documental de Nivel 0 y uno de Nivel 4 que puede desplegar a producción se rigen por las mismas reglas, pero con umbrales muy distintos. El nivel es donde la pregunta "¿bajo qué controles?" encuentra su respuesta.

El riesgo principal: el encadenamiento de herramientas

De todas las formas en que un despliegue MCP se tuerce, el marco nombra el encadenamiento de herramientas como el riesgo principal: un servidor capaz de invocar otras herramientas o disparar flujos posteriores convierte una sola acción aprobada en una cadena que el usuario nunca vio. Alrededor se sitúan las preocupaciones habituales: autorización y alcance de acceso, exposición de credenciales y fuga de datos, huecos en la auditoría, confianza en la cadena de suministro y despliegues en la sombra. El modelo de ocho factores puntúa exactamente esto, de modo que dos servidores del mismo nivel pueden acabar con riesgos residuales muy distintos. Si además vas a exponer un modelo, complementa el análisis con el escáner de riesgo de modelos.

Encaja con lo que tus auditores ya esperan

Esto no es un estándar aislado. El marco se alinea con el OWASP MCP Top 10, el OWASP LLM Top 10, el NIST AI RMF, la ISO/IEC 42001 y SOC 2, así que una decisión de gobernanza registrada aquí encaja directamente en la evidencia de cumplimiento que ya produces. El objetivo final es sencillo: hacer que el camino aprobado sea más rápido que el despliegue en la sombra, porque una gobernanza más lenta que "ejecútalo tú mismo" no se sigue, se esquiva.