El archivo mcp.json que tu equipo de seguridad no sabe que existe
Imagina que abres la laptop de un colega para ayudarle con un error. En la carpeta de configuración encuentras un archivo llamado mcp.json. Adentro: la contraseña de la base de datos de producción en texto plano. Al lado, un comentario que dice TODO: rotate this. Tu equipo de seguridad no tiene idea de que ese archivo existe, ni de cuántos más hay como ese en el resto de la organización.
Este no es un escenario inventado. Es exactamente el patrón que AWS describe como el problema central de las empresas que ya están usando agentes de IA conectados a herramientas internas. Y en agosto de 2026, con la proliferación de asistentes como Claude Code, Cursor y Kiro, este problema ya no es teórico: es operacional.
En este artículo analizamos el enfoque que AWS propone con Amazon Bedrock AgentCore Gateway para gobernar el acceso de agentes de IA a herramientas empresariales, y qué significa esto en la práctica para empresas en Perú y América Latina.
El problema real: cinco patrones de riesgo que ya están ocurriendo
Cuando múltiples agentes de IA se conectan a herramientas internas sin una capa de gobernanza centralizada, los equipos enfrentan cinco problemas estructurales que AWS identifica con precisión.
El primero es el credential sprawl: credenciales secretas dispersas en archivos de configuración locales de cada desarrollador o asistente. El segundo es el policy drift: si tienes 10 asistentes conectados a 5 APIs internas, estás manteniendo 50 configuraciones de credenciales independientes. Cuando cambia una política en un backend, debes actualizarla en los 50 lugares — y nadie lo hace en sincronía.
Los otros tres son igualmente críticos: audit gaps (no puedes responder quién invocó qué herramienta y cuándo), cost opacity (el gasto en llamadas a herramientas no se puede atribuir a equipos específicos), y shadow IT (integraciones desplegadas fuera de cualquier proceso de revisión). La combinación de estos cinco patrones convierte a los agentes de IA en un vector de riesgo silencioso que crece con cada nuevo asistente que el equipo adopta.
La solución: una puerta gobernada con cuatro niveles de madurez
El enfoque de AWS con Amazon Bedrock AgentCore Gateway parte de una idea conceptualmente simple pero poderosa: en lugar de que cada agente de IA cargue su propio archivo de configuración con credenciales locales, toda la organización tiene un único punto de entrada gobernado para el tráfico agéntico.
Este gateway sabe quién está llamando y bajo qué autoridad, aplica políticas a nivel de herramienta y parámetro, registra cada decisión en CloudTrail, y permite que los equipos publiquen herramientas sin necesidad de tickets de soporte. Lo que hace particularmente inteligente a este diseño es que propone cuatro niveles de madurez progresivos, donde cada nivel entrega valor independiente y solo avanzas al siguiente cuando aparece un nuevo problema real.
Scope 1 — Connect es el punto de partida para equipos de 1 a 20 usuarios piloto. En esencia, reemplazas las credenciales locales por un gateway con autenticación JWT respaldada por Amazon Cognito. Los agentes obtienen un token por sesión, el gateway lo valida, y las credenciales de backend nunca salen de AWS. Esto se puede implementar en una semana y ya responde la pregunta básica de seguridad: ¿quién accedió a qué y cuándo?
Scope 2 — Control agrega identidad granular: RBAC y ABAC con Cedar, redacción automática de PII en las respuestas, consentimiento explícito del usuario (OAuth 3LO), y logs de auditoría por identidad. Este nivel responde preguntas como: ¿están los usuarios pasando datos personales a través de las herramientas? ¿Diferentes grupos de usuarios deberían tener acceso diferenciado?
Scope 3 — Catalog resuelve el problema de escala: un registro centralizado donde los equipos pueden publicar y descubrir herramientas sin depender de tickets de infraestructura, incluyendo sistemas on-premises. Scope 4 — Harden es para organizaciones con más de 1,000 usuarios, añadiendo conectividad privada, circuit breakers, dashboards de gobernanza, y failover multi-región.
¿Cómo aplica esto en empresas de Perú y LATAM?
En la mayoría de empresas medianas de la región, el escenario más común hoy es el equivalente al Scope 0: agentes de IA conectados a herramientas internas con credenciales en archivos locales, sin inventario, sin auditoría, y con una confianza implícita que nadie ha cuestionado formalmente.
El salto al Scope 1 no requiere una transformación completa. Requiere una decisión: centralizar el punto de entrada antes de que el número de agentes haga el problema inmanejable. En términos prácticos, una empresa con 5 desarrolladores usando asistentes de IA conectados a sus sistemas internos ya tiene suficiente complejidad para justificar este primer nivel de gobernanza.
Para empresas que manejan datos sensibles de clientes — finanzas, salud, logística — el Scope 2 deja de ser opcional en el momento en que el primer agente de IA toca esos datos. La pregunta no es si implementar gobernanza, sino cuándo hacerlo antes de que ocurra un incidente.
Un aspecto relevante para la región es que este tipo de arquitectura también aplica a integraciones con ERPs como Odoo, donde los agentes de IA pueden estar consultando o modificando datos de clientes, inventario o finanzas. Tener un gateway gobernado entre el agente y el ERP es exactamente el tipo de control que diferencia una implementación profesional de una experimental.
¿Cómo aplica esto en tu empresa?
Antes de evaluar cualquier herramienta, responde estas tres preguntas en menos de un minuto:
- ¿Puedes listar todos los agentes de IA que actualmente tienen acceso a sistemas internos de tu organización?
- ¿Sabes quién autorizó cada uno de esos accesos y bajo qué política?
- ¿Tienes un log auditable de qué herramientas invocó cada agente en los últimos 30 días?
Si la respuesta a alguna de estas preguntas es no, el Scope 1 de AgentCore Gateway es el punto de partida correcto. La implementación básica — gateway con Cognito JWT, un target Lambda registrado, y CloudTrail habilitado — puede estar operativa en menos de una semana sin interrumpir el trabajo actual de los equipos.
Si ya tienes respuesta para las tres preguntas pero no puedes distinguir qué grupos de usuarios acceden a qué herramientas, el Scope 2 con Cedar RBAC es el siguiente paso lógico. El principio clave es no construir todo de golpe: avanzar solo cuando el siguiente problema de gobernanza se vuelve real y visible.
Conclusión
La gobernanza de agentes de IA no es un problema futuro. Es un problema que ya existe en cualquier organización donde un desarrollador tiene un asistente de IA conectado a un sistema interno. La diferencia entre una empresa que lo gestiona bien y una que no, es si tomó la decisión de centralizar el control antes o después de un incidente.
El modelo de cuatro scopes que propone AWS con Amazon Bedrock AgentCore Gateway es uno de los enfoques más pragmáticos que hemos visto publicados hasta la fecha: no te pide que construyas todo antes de empezar, sino que empieces con el control mínimo necesario y crezcas cuando el problema lo justifique.
En Consultoría-Ti trabajamos con empresas en Perú y LATAM que están en este proceso de transición: desde el primer agente de IA en producción hasta arquitecturas de automatización a escala. Si estás evaluando cómo gobernar el acceso de tus agentes de IA a sistemas internos — incluyendo ERPs, bases de datos, o APIs propias — podemos ayudarte a diseñar una arquitectura que sea segura desde el primer día.
👉 Conversemos sobre tu proyecto en Consultoría-Ti
Fuentes y Referencias
✨ Contenido generado con ContentFlow — Consultoría-Ti