Automatiza las comprobaciones de cumplimiento con repositorios MCP: guía práctica

El cumplimiento no tiene por qué ser lento ni misterioso. Con los repositorios MCP puedes integrar estándares en los flujos de trabajo cotidianos y dejar que las máquinas persigan la evidencia.

Qué son los repositorios MCP (y por qué ayudan)

Model Context Protocol (MCP) te da una forma coherente de conectar herramientas, fuentes de datos y prompts para que un agente de automatización o asistente actúe con contexto. Un repositorio MCP es el manifiesto portátil de ese mundo: servidores (conectores y lógica), recursos (datos) y prompts (instrucciones repetibles) empaquetados en una estructura predecible. En lugar de cablear scripts puntuales, montas un repositorio que tu equipo y los runners de CI pueden reutilizar en distintos entornos.

El cumplimiento exige repetibilidad. Los repositorios MCP ofrecen:

• Un manifiesto declarativo de qué herramientas existen y qué pueden hacer
• Entradas/salidas predecibles para comprobaciones y recolección de evidencia
• Prompts y políticas versionadas para que las auditorías sean reproducibles
• Un único lugar para gestionar excepciones, mapeos y metadatos

En resumen, los repositorios MCP te permiten implementar “cumplimiento como código” en una forma que personas y máquinas realmente pueden usar.

Resultados de cumplimiento a los que aspirar

Antes de escribir una sola regla, define resultados prácticos:

• Prevenir drift respecto a tu línea base (CIS, SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR)
• Detectar problemas temprano en pull requests y CI, no durante revisiones trimestrales
• Recopilar evidencia duradera como artefactos, no capturas de pantalla
• Permitir excepciones basadas en riesgo con caducidad y propietario
• Mapear cada comprobación a un ID de control y mostrar el estado de un vistazo

Esos resultados moldean el diseño del repositorio y lo que expondrán tus servidores MCP.

Arquitectura de referencia: MCP para compliance-as-code

Piensa en capas:

• Fuentes: cuentas cloud (AWS, Azure, GCP), clústeres Kubernetes, Terraform/CloudFormation, proveedores de identidad, herramientas endpoint, sistemas SaaS y repositorios de código.
• Servidores MCP: conectores que obtienen configuraciones, ejecutan consultas, llaman a motores de política y emiten hallazgos estandarizados.
• Manifiesto del repositorio: describe servidores, herramientas, recursos y prompts para que cualquier runner pueda ensamblar el grafo.
• Orquestación: jobs programados, pipelines de CI y flujos de trabajo en chat que invocan el repositorio.
• Almacén de evidencias: un object store o registro de artefactos para conservar logs, hallazgos y atestaciones.
• Reportes: dashboards o comentarios en pull requests alimentados por las salidas del MCP.

Cada servidor debería hacer bien un trabajo: recopilar, comprobar o atestiguar. Mantén los contratos estrechos y las salidas amigables para máquinas.

Construir un repositorio MCP mínimo

Los bloques que definirás:

• servers: los endpoints ejecutables (p. ej., aws-inventory, k8s-auditor, policy-evaluator)
• tools: los métodos que exponen los servidores (p. ej., list_buckets, eval_policy, get_manifest)
• resources: dónde viven los datos (p. ej., s3://compliance-artifacts, endpoints https)
• prompts: plantillas de instrucción reutilizables para ejecutar comprobaciones y formatear informes

Un manifiesto compacto podría verse así:

{
	"name": "mcp-compliance",
	"description": "Automated compliance checks and evidence collection",
	"servers": {
		"aws-inventory": { "command": "python", "args": ["servers/aws_inventory.py"] },
		"k8s-auditor": { "command": "node", "args": ["servers/k8s_auditor.js"] },
		"policy-engine": { "command": "opa", "args": ["run", "bundles/policies/"] },
		"evidence-store": { "command": "python", "args": ["servers/evidence_store.py"] }
	},
	"resources": [
		{ "uri": "artifact:s3://org-compliance/evidence" },
		{ "uri": "vault:kv/team/security" }
	],
	"prompts": [
		{ "name": "run_cis_aws", "description": "Evaluate CIS AWS checks and write evidence" }
	]
}

El verdadero poder aparece cuando cada herramienta devuelve hallazgos normalizados: id, título, severidad, mapeos de control, IDs de recurso, URIs de evidencia y pistas de remediación.

Diseñar comprobaciones portables

Las comprobaciones portables sobreviven a los cambios de plataforma. Apunta a:

• Entradas normalizadas: account_id, region, cluster, repo, resource_id, timestamp
• Salidas normalizadas: finding_id, control_id, severity, status (pass/fail/error), rationale, evidence_uri
• Lógica de políticas versionada: versiona tus políticas y etiqueta los hallazgos con policy_version
• Ejecución determinista: las mismas entradas deben producir los mismos resultados

Trata las comprobaciones como APIs. Entradas dentro, hallazgos estructurados fuera, más un código de salida claro para gating en CI.

Elige cómo almacenar y evaluar la política

Tienes opciones:

• Lógica embebida en servidores MCP: rápido para empezar, más difícil de compartir entre stacks.
• OPA/Rego en un servidor policy-engine: popular, expresivo y auditable.
• Consultas estilo SQL contra snapshots de configuración: ideal para análisis de grafos de configuración.
• Híbrido: el servidor MCP reúne datos; el motor de políticas evalúa; el almacén de evidencias atestigua.

Elige un patrón consistente por dominio de control para evitar confusión y lógica duplicada.

Ejemplo: Tres comprobaciones de extremo a extremo

1. Los buckets S3 no deben ser públicos

• Inventario: la herramienta aws-inventory lista buckets y banderas de ACL/política.
• Política: policy-engine evalúa “no READ/WRITE público vía ACL o política.”
• Evidencia: evidence-store escribe un artefacto JSON con nombre del bucket, fragmento de política y rastro de evaluación.
• Salida: hallazgo con control_id “CIS-3.1”, estado y pasos de remediación.

2. Los pods de Kubernetes no deben ejecutarse privileged

• Inventario: k8s-auditor solicita specs de pods en todos los namespaces.
• Política: rechaza securityContext.privileged=true y hostNetwork=true sin excepciones.
• Evidencia: almacena la spec violadora, el namespace y un enlace al propietario del workload.
• Salida: hallazgo mapeado a tu control interno “K8S-PRIV-01”.

3. Secretos no deben aparecer en el historial de Git

• Inventario: un repo-scanner transmite commits recientes y diffs.
• Política: detecta patrones (claves AWS, JWTs, tokens de Slack) y rutas de archivos que deben bloquearse.
• Evidencia: un extracto de diff redactado, hash del commit y autor.
• Salida: el hallazgo marca status fail y solicita rotación inmediata si se confirma.

_{Photo by Scott Rodgerson on Unsplash}

Haz que el repositorio sea ejecutable en CI

Añade un workflow que:

• Instale dependencias y autentique con cloud/clúster/entorno de pruebas
• Arranque los servidores MCP definidos en el manifiesto del repositorio
• Ejecute prompts que orquesten las comprobaciones
• Suba artefactos al almacén de evidencias
• Falle el job en hallazgos de severidad crítica salvo que apliquen excepciones

Snippet de ejemplo para GitHub Actions:

jobs:
  compliance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -r servers/requirements.txt
      - run: npm ci --prefix servers
      - name: Run MCP compliance
        run: python runner.py --manifest mcp.json --prompt run_cis_aws
      - name: Upload evidence
        uses: actions/upload-artifact@v4
        with:
          name: evidence
          path: out/evidence/**

Mantén el runner simple: parsea hallazgos, compáralos con umbrales de política, publica un comentario resumido y ajusta el código de salida.

Etiqueta los hallazgos con controles reales

Cada hallazgo debería llevar mapeos de control:

• control_id: externo (p. ej., CIS 1.1, ISO A.12.1.2) e interno (p. ej., SEC-001)
• control_name: etiqueta legible para humanos
• requirement_text: una referencia breve al requisito
• policy_version: qué versión produjo el resultado

Cuando los auditores pregunten “muéstrame evidencia para el control X”, podrás consultar por etiqueta y devolver un bundle estable.

Evidencia que resiste una auditoría

Qué almacenar:

• Entradas crudas: snapshots de recursos, configs, manifests
• Salida de evaluación: pass/fail, rationale, rastro de la regla
• Metadatos: quién/qué/cuándo ejecutó la comprobación; versión del repositorio; commit SHA
• Hashes: digests de contenido para probar integridad
• Atestaciones: declaraciones firmadas que enlacen con artefactos

Formatea los artefactos como JSON con esquemas consistentes. Emite nombres de archivo deterministas (p. ej., control/bucketName/timestamp.json) para mantener la navegación predecible.

Gestiona excepciones sin caos

Los sistemas reales necesitan excepciones. Géstionalas como código:

• Las excepciones viven en un fichero versionado (exceptions.yaml) con campos: resource_id, control_id, owner, reason, risk_level, expires_at, ticket_url.
• Los servidores MCP chequean excepciones primero y anotan el hallazgo con status=waived o status=accepted-risk según corresponda.
• Las excepciones que caducan disparan recordatorios en CI o en chat.

No más correos. No más notas adhesivas. Todo en el repositorio y visible en diffs.

Alinea equipos con severidades y SLAs claros

Define una rúbrica de severidad:

• Critical: explotación probable; bloquear despliegues; SLA de corrección 24h
• High: riesgo significativo; SLA de corrección 3–5 días
• Medium: necesita atención; corregir en sprint
• Low: higiene; corregir cuando convenga

Deja que las comprobaciones MCP asignen severidad de forma determinista (p. ej., bucket S3 público con tag sensitive=Critical). Los fallos en CI y los umbrales de dashboard siguen el mismo mapa.

Agiliza la experiencia de desarrollo

Las comprobaciones de cumplimiento ganan cuando son rápidas y locales:

• Crea un prompt “dev profile” que apunte solo a los recursos cambiados
• Proporciona un script de inicio rápido (p. ej., make compliance) para ejecuciones puntuales
• Imprime remediaciones legibles para humanos junto a las salidas máquina
• Cachea las peticiones de inventario para acelerar repeticiones
• Ofrece modos dry-run y —explain que incluyan trazas de reglas

Cuanto menos tiempo espere un desarrollador, más probable es que ejecute comprobaciones antes de abrir un PR.

Escala entre cuentas y clústeres

Al expandir:

• Shardea el inventario por cuenta/región/clúster para evitar timeouts
• Agrupa evaluaciones de políticas y stream de resultados de forma incremental
• Usa concurrencia con backoff para respetar límites de API
• Introduce una cola para comprobaciones de larga duración
• Guarda un “run manifest” que registre qué shards se ejecutaron y cuáles se saltaron

Cuando algo falle a mitad de ejecución, quieres reanudar sin rehacer horas de trabajo.

Mantén secretos y privilegios bajo control

Las buenas prácticas de seguridad aplican a servidores MCP:

• Concede el menor privilegio posible; solo lectura cuando sea factible
• Rota credenciales usadas por CI; prefiere tokens de corta duración
• Restringe el egress de red de servidores a lo estrictamente necesario
• Loggea cada acceso a recursos sensibles con IDs de correlación
• Cifra la evidencia en reposo y en tránsito; usa claves gestionadas por KMS

Tu automatización de cumplimiento no debe convertirse en tu mayor riesgo.

Monitoriza lo que importa

Sigue un pequeño conjunto de métricas:

• Mean time to detect y mean time to fix por severidad
• Recuento de excepciones y edad media
• Cobertura de controles: comprobaciones activas vs. controles requeridos
• Tasa de drift: número de fallos recurrentes entre ejecuciones
• Salud de ejecución: tasa de éxito y tiempo medio por shard

Los dashboards están bien, pero tendencias semanales en un informe ligero mantienen a los equipos centrados.

Errores comunes a evitar

• Mezclar lógica y datos: separa el código de política del fetching de inventario
• Sobrecargar un servidor con demasiadas responsabilidades
• Escribir reglas que dependan de campos volátiles (p. ej., timestamps) y rompan la determinismo
• Ignorar el formato de la evidencia hasta la semana de auditoría
• Dejar que las excepciones se descontrolen sin caducidad
• Ocultar resultados en formatos propietarios que nadie puede parsear

Piezas pequeñas y reutilizables vencen a un gran “monolito de cumplimiento”.

Biblioteca de patrones para controles frecuentes

Crea una librería de patrones en el repositorio:

• Alcance de recursos: puertos abiertos, endpoints públicos, trust cross-account
• Protección de datos: cifrado en reposo/tránsito, propiedad de claves KMS
• Identidad: MFA, antigüedad de claves, asunción de roles, permission boundaries
• Endurecimiento de workloads: capacidades restringidas, network policies, imágenes inmutables
• Integridad del build: firmas de artefactos, presencia de SBOM, puertas de vulnerabilidades

Para cada patrón, incluye un esquema de entrada, esbozo de regla y fixtures de prueba mínimos.

Probar tus comprobaciones

Trata la política como cualquier otro código:

• Tests unitarios con inventarios mock
• Golden files para salidas de evidencia y detectar regresiones
• Tests de contrato para esquemas I/O de herramientas
• Smoke tests end-to-end en una cuenta/clúster sandbox
• Un “control canario” que falle deliberadamente para probar que la canalización lo detecta

Haz que las pruebas se ejecuten localmente sin credenciales cloud usando fixtures.

Integrar con revisión y chat

Convierte los hallazgos en acción:

• En PRs, comenta con un informe conciso: controles que fallan, remediación principal y enlaces a artefactos de evidencia
• Proporciona comandos slash en chat para relanzar comprobaciones o recuperar el último bundle de evidencia
• Notifica a los propietarios cuando su excepción esté a punto de expirar
• Publica resúmenes semanales en el canal del equipo con tendencias y éxitos

El estado de cumplimiento solo ayuda si la gente lo ve en el momento adecuado.

Mapear a marcos sin ahogarse

Nunca mapearás perfectamente todos los marcos el primer día. Empieza con:

• Un único set interno canónico de controles
• Un fichero de mapeo que enlace marcos (CIS, SOC 2, ISO, PCI, HIPAA, GDPR) a esos controles internos
• Los hallazgos MCP referencian IDs internos; las capas de reporte expanden a etiquetas de marcos cuando haga falta

Esto mantiene estable la lógica de política incluso cuando los marcos evolucionan.

Un loop de runner ligero

Tu runner puede ser un script mínimo:

• Parsear el manifiesto
• Arrancar servidores
• Resolver recursos y excepciones
• Ejecutar prompts (o llamadas directas a herramientas)
• Stream de hallazgos normalizados a stdout y al almacén de evidencias
• Salir con código no cero si se supera un umbral de severidad

Los runners pequeños son más fáciles de depurar y menos frágiles que capas de orquestación complejas.

Evoluciona sin romper a los consumidores

Versiona bundles de política y el esquema de hallazgos:

• Usa semver; sube la versión mayor solo en cambios incompatibles
• Emite policy_version y schema_version en cada artefacto
• Mantén un changelog con notas de riesgo (“control XYZ ahora trata tag=sensitive de forma distinta”)
• Proporciona un script de migración para artefactos antiguos si es necesario

Tus auditores (y tu yo del futuro) te lo agradecerán.

Victorias rápidas para lanzar este trimestre

• Empieza con 5 controles de alta señal por plataforma, no 50
• Levanta un almacén de evidencias y un esquema antes de añadir más comprobaciones
• Conecta gates de CI solo para hallazgos Critical; expande después
• Documenta el proceso de excepciones y aplica caducidad
• Publica un dashboard o digest semanal para visibilidad

El momentum importa más que la cobertura perfecta al principio.

Mirando al futuro

Una vez que lo básico funcione:

• Añade atestaciones con declaraciones firmadas vinculadas a commit SHAs
• Introduce etiquetas de clasificación de datos para influir en severidad
• Enriquece los hallazgos con datos de propiedad desde tu CMDB interna
• Expande a señales en runtime (eBPF, comportamiento de workloads)
• Ofrece un portal self-service donde los equipos vean su postura de control por servicio

Tu repositorio MCP se convierte en la columna vertebral para un cumplimiento continuo y explicable: menos teatro, más pruebas.

Enlaces externos

MCP integration for the metadata Compliance Checker - GitHub How MCP Integrates Security, Compliance, and Observability in … Why MCP is a Game-Changer for DevSecOps Security & Compliance How to Leverage Itential MCP & Agentic AI For Network Config … Automating Security Checks with AWS Terraform MCP Server