De prototipo a producción: permisos, verificación y catálogo vivo

La demo funcionó: el agente leyó tickets, consultó la base y mandó un Slack. En producción, a la segunda semana, borró un registro de staging pensando que era dev, gastó el triple de tokens en un loop de reintentos y llamó un endpoint de Slack deprecated que el MCP no actualizó. Ninguno de esos fallos es “el modelo alucinó” — son fallos de harness: permisos demasiado amplios, cero verificación antes de actuar y un catálogo de tools que nadie revisó.

Permisos mínimos

Regla base: el agente debe tener acceso a lo mínimo necesario para la tarea, no a todo lo que podés conectar.

Base de datos. Usuario read-only para consultas. Si necesita writes, un usuario con permisos acotados a tablas específicas — nunca el superuser de prod.

APIs (Linear, Slack, GitHub). Scopes mínimos: issues:read antes de issues:write, canal de Slack dedicado antes del #general. Los MCPs de security ayudan a auditar qué expone cada integración.

Filesystem. En Claude Code, --dangerously-skip-permissions es tentador en local y suicida en CI. En producción usá allowlists explícitas de directorios y comandos.

Anthropic propone ir más allá de prompts de permiso: sistemas estructurados de autorización (ALLOW / DENY / REQUIRE_APPROVAL) en lugar de confiar en que el usuario lea cada popup. Si tu equipo aprueba el 93% de los prompts sin leer, los permisos no están funcionando.

Human-in-the-loop

No todo debe ser autónomo. Definí qué acciones requieren aprobación humana:

• Deletes o updates masivos
• Envío de comunicaciones externas (mail, Slack a clientes)
• Deploys o cambios de infraestructura
• Cualquier operación irreversible

El patrón: el agente prepara la acción, muestra un resumen y espera confirmación. En headless (CI, cron), usá un clasificador de riesgo que bloquee acciones de alto impacto en lugar de pedir permiso cada vez.

Para RAG sobre documentos PDF, human-in-the-loop también aplica al contenido: ¿el agente puede citar documentos confidenciales? ¿Hay chunks que no deberían entrar al contexto? Los MCPs de knowledge-and-memory resuelven el retrieval; vos definís qué corpus es seguro.

Verificar antes de actuar

Tests de integración. Antes de darle acceso a prod, corré el flujo contra staging con datos sintéticos. Si el agente no puede completar el flujo 5 veces seguidas en staging, no lo subas a prod.

Evals, no solo unit tests. Los agentes fallan de formas que los unit tests no capturan: loops, tool selection incorrecta, degradación silenciosa. Anthropic recomienda eval harnesses que midan comportamiento end-to-end, no solo “¿la tool devolvió JSON válido?”

Dry-run mode. Algunos MCPs soportan modo simulación. Si no, pedile al agente que muestre qué haría antes de ejecutar: “Voy a ejecutar DELETE FROM … — ¿confirmás?”

Monitoreo. Un MCP de monitoring o MCP de monitoreo y alertas te avisa cuando el agente dispara errores, excede latencia o llama tools inesperadas. Sin observabilidad, el primer síntoma de un harness roto es un ticket de un usuario enojado.

Señales de un MCP abandonado

El catálogo del directorio muestra último commit y badge Archivado en cada card. En producción, revisá periódicamente:

• MCPs con commit > 90 días en integraciones críticas
• Repos archivados que siguen en tu .mcp.json
• MCPs cuyo vendor deprecó la API (Slack, GitHub cambian endpoints sin aviso en el README del MCP community)

El re-sync semanal del directorio (GitHub Actions) actualiza stars, commits y marca entries removidas del README como source_present=false — desaparecen de búsqueda pero la fila persiste para auditoría. En el footer del directorio MCP ves “Última sincronización”: si dice más de 7 días, el badge se pone amber. Tu stack debería apoyarse en un catálogo fresco, no en una lista que copiaste hace seis meses.

Catálogo vivo vs lista estática

mcpservers.org y los READMEs awesome son útiles como punto de partida, pero no te dicen si el repo sigue mantenido ni si el install_ref funciona hoy. Savante enriquece cada entry con señales de GitHub y búsqueda por intención — pero la responsabilidad de revisar tu stack en prod es tuya.

Checklist trimestral:

1. ¿Todos los MCPs del stack tienen commit reciente o justificación?
2. ¿Los permisos siguen siendo mínimos después de agregar features?
3. ¿Hay evals que corran en CI antes de deploy?
4. ¿El footer del directorio muestra sync < 7 días?

Cerrar el learning path

Recorriste las cuatro piezas: qué es el harness, cómo elegir MCPs, cómo armar el primer stack y qué cambia en producción. El directorio te da el catálogo y las configs; estas guías te dan el criterio.

Si tenés un agente concreto en mente y querés el stack armado con arquitectura y puntos de falla, describilo en la banda de síntesis. La búsqueda y el copy-paste siguen siendo gratis — el email desbloquea la síntesis completa.