Los proveedores de software como servicio (SaaS) que crean aplicaciones agentes multiinquilino deben abordar desafíos arquitectónicos más allá de las preocupaciones típicas de seguridad, gobernanza y precisión de la respuesta. Estos incluyen aislamiento de inquilinos, identidad de inquilinos, observabilidad de inquilinos, aislamiento de datos, atribución de costos y mitigación de vecinos ruidosos. Cerrar la brecha entre una demostración funcional y una implementación de producción requiere una infraestructura diseñada para entornos multiinquilino. Amazon Bedrock AgentCore es un servicio administrado y sin servidor para crear, implementar y operar de forma segura aplicaciones agentes en AWS. Proporciona estructuras para implementar agentes y alojar servidores MCP, con soporte integrado para administración de identidades, memoria, observabilidad y evaluaciones, todo diseñado para hacer que las arquitecturas de agentes multiinquilino sean fáciles de construir.
Esta publicación, parte 1 de la serie de blogs, explora consideraciones de diseño para diseñar aplicaciones agentes multiinquilino y el marco necesario para abordar los desafíos de la arquitectura SaaS con Amazon Bedrock AgentCore.
Consideraciones de diseño para crear un agente multiinquilino
La creación de aplicaciones agentes seguras para múltiples inquilinos con un fuerte aislamiento requiere decisiones arquitectónicas cuidadosas en ciertos componentes clave, como se muestra en la Figura 1. Cada componente debe equilibrar el aislamiento de los inquilinos, la eficiencia operativa y la optimización de costos mientras se mantienen los estándares de seguridad y cumplimiento. Estas consideraciones de diseño giran en torno a tres patrones de aislamiento de inquilinos: silo, piscina y puente, con la estrategia de niveles como consideración clave al elegir entre ellos.
Figura 1: Consideraciones de diseño para un agente multiinquilino
En la siguiente sección, explicamos cómo el arrendamiento múltiple afecta a cada uno de estos componentes.
1. Implementación del tiempo de ejecución del agente: dedicado en comparación con compartido
Una decisión clave en una arquitectura agente multiinquilino es cómo se aprovisiona el tiempo de ejecución del agente en relación con los inquilinos. Un tiempo de ejecución dedicado por inquilino crea una instancia de un entorno de ejecución independiente para cada inquilino, con su propia imagen de contenedor, espacio de proceso y ciclo de vida. Este enfoque de silo ofrece la mayor protección contra vecinos ruidosos y agiliza las auditorías de cumplimiento. Un tiempo de ejecución compartido aloja agentes para todos los inquilinos dentro de la misma imagen de contenedor y grupo de procesos, lo que reduce los costos de infraestructura y la sobrecarga operativa, pero requiere una estricta propagación del contexto de los inquilinos durante el proceso.
Amazon Bedrock AgentCore Runtime resuelve esta tensión mediante computación basada en microVM con sesión aislada. AgentCore Runtime lanza microVM livianas por sesión, sin el costo o la latencia de poner en marcha una máquina virtual completa para cada inquilino. Cada sesión lleva su propio sistema de archivos persistente, por lo que los agentes pueden leer y escribir archivos con alcance de sesión, mantener artefactos de cálculo intermedios y preservar el estado en interacciones de varios pasos, lo que reduce el riesgo de fuga de datos entre sesiones. La arquitectura es una buena opción para alojar servidores MCP, agentes y servidores AG-UI de múltiples inquilinos. El contexto del inquilino fluye hacia el entorno de ejecución aislado a través de encabezados HTTP personalizados. Cuando la plataforma SaaS reenvía una solicitud a una sesión de AgentCore Runtime, adjunta encabezados que contienen metadatos específicos del inquilino, como identificador de inquilino, nivel, preferencias regionales, indicadores de funciones o derechos, junto con tokens de autorización estándar. El agente lee estos encabezados en el momento de la invocación para establecer un conocimiento total del inquilino, de modo que pueda ejecutar flujos de trabajo ajustados a la lógica empresarial de ese inquilino, invocar solo herramientas con licencia y llamar a puntos finales de API específicos del inquilino sin una lógica de enrutamiento codificada.
2. Compartido en comparación con Nivel específico en comparación con. Modelos ajustados
Los modelos de base compartidos (FM) sirven como punto de partida recomendado para la mayoría de las implementaciones multiinquilino y ofrecen operaciones optimizadas con mantenimiento de un solo modelo. Los inquilinos normalmente se benefician de las actualizaciones automáticas del modelo sin personalizaciones por inquilino. La opción de seleccionar el modelo según el nivel de inquilino (modelo específico de nivel) permite flexibilidad y equilibra el costo, el rendimiento y la precisión entre los niveles de inquilino. Los modelos ajustados específicos para inquilinos se vuelven necesarios para casos de uso especializados que requieren terminología, cumplimiento normativo o SLA de rendimiento específicos para inquilinos, aunque introducen una mayor complejidad operativa y canalizaciones por inquilino. Un enfoque híbrido, que utiliza modelos menos capaces para niveles estándar y modelos ajustados o más capaces para clientes empresariales premium, equilibra la eficiencia de costos con las necesidades de personalización. Amazon Bedrock ofrece una variedad de modelos de lenguaje grande (LLM) de proveedores líderes, lo que permite a los proveedores de SaaS elegir un modelo adecuado para las necesidades específicas del inquilino y del nivel. El ajuste de Amazon Bedrock admite la personalización de FM utilizando sus propios conjuntos de datos etiquetados para mejorar el rendimiento de tareas específicas del dominio. Con Amazon Bedrock Custom Model Import, puede traer sus propios modelos ajustados e implementarlos utilizando la infraestructura administrada de Amazon Bedrock.
3. Flujos de trabajo: patrones de silo, grupo y puente
Las aplicaciones de agentes multiinquilino requieren una gestión de flujo de trabajo flexible en la que cada agente ejecuta diferentes secuencias de pasos según los requisitos del inquilino y la lógica empresarial. Los flujos de trabajo se pueden implementar a través de múltiples mecanismos: como herramientas MCP que encapsulan procesos paso a paso, como puntos finales de API que definen flujos de lógica empresarial o como habilidades de agente que incorporan patrones de flujo de trabajo específicos de un dominio.
Tres patrones principales administran flujos de trabajo específicos de los inquilinos. El patrón de silo utiliza habilidades específicas de inquilinos donde el flujo de trabajo completo de cada inquilino, incluida toda la lógica empresarial, las reglas de validación y los pasos de integración, está integrado en habilidades de agentes aislados. Esto brinda máxima personalización y total independencia, pero requiere un mantenimiento de habilidades separado por inquilino. El patrón de grupo utiliza habilidades de agente compartidas. El patrón puente incorpora pasos de flujo de trabajo comunes, como autenticación, registro y manejo de errores, en habilidades de agente compartidas que invocan habilidades específicas de los inquilinos en tiempo de ejecución para la lógica crítica para el negocio. El resultado es una infraestructura reutilizable que coexiste con la personalización específica del inquilino.
4. RAG multiinquilino
Los sistemas de recuperación de generación aumentada (RAG) requieren decisiones de aislamiento de datos. El patrón de silo utiliza bases de datos vectoriales dedicadas por inquilino, lo que proporciona máxima seguridad y separación completa de datos. Esto se recomienda para industrias reguladas y clientes empresariales que requieren infraestructura dedicada. El patrón de grupo utiliza bases de datos vectoriales compartidas con filtrado de inquilinos basado en metadatos y control de acceso basado en espacios de nombres, lo que admite operaciones rentables para plataformas SaaS que prestan servicios a muchos inquilinos pequeños y medianos. Las operaciones de recuperación deben incluir la inyección automática de filtros de inquilinos y la desinfección de resultados para ayudar a prevenir la fuga de datos entre inquilinos.
Amazon Bedrock Knowledge Bases proporciona capacidades RAG totalmente administradas que conectan los FM con sus fuentes de datos, manejando automáticamente la ingesta, fragmentación, generación de incrustación y almacenamiento vectorial de datos. Admite múltiples bases de datos vectoriales y brinda la capacidad de crear bases de datos vectoriales aisladas o compartidas (mediante filtrado de metadatos).
Para obtener orientación detallada sobre la implementación de arquitecturas RAG multiinquilino con Amazon Bedrock Knowledge Bases, consulte RAG multiinquilino con bases de conocimiento de Amazon Bedrock para patrones de implementación de silos, grupos y puentes y Multiinquilino en aplicaciones RAG en una única base de conocimientos de Amazon Bedrock con filtrado de metadatos para el aislamiento de inquilinos basado en metadatos dentro de una base de conocimientos compartida.
5. Contexto del inquilino, patrones de acción en nombre y propagación de tokens
La gestión de identidades de múltiples inquilinos requiere un manejo cuidadoso del contexto de los inquilinos a lo largo de toda la cadena de servicios. El contexto del inquilino, que representa la identidad completa, y el estado específico de la solicitud deben fluir a través de cada capa arquitectónica utilizando mecanismos confiables y seguros. A diferencia de las API de software deterministas con rutas de ejecución predecibles, los agentes de IA no son deterministas y pueden ser potencialmente autónomos, lo que hace que las consideraciones de seguridad sean diferentes en aspectos importantes. Los agentes deshonestos o comprometidos podrían realizar llamadas no autorizadas a servicios posteriores, lo que provocaría el robo de credenciales, una escalada de privilegios y el problema del diputado confuso. Cuando los agentes operan con credenciales de usuario completas (suplantación), un único agente comprometido obtiene acceso completo a todos los permisos de usuario en todos los sistemas posteriores. Este riesgo crece a medida que los agentes se vuelven más autónomos y toman decisiones independientes sobre qué herramientas invocar, cuándo invocarlas y con qué parámetros. El patrón de acción en nombre es importante porque establece una distinción clara entre el usuario y el agente, donde los agentes realizan llamadas en nombre del usuario con permisos específicos y explícitamente limitados para cada operación específica.
Codifique el contexto del inquilino dentro de tokens web JSON (JWT) que capturen tres dimensiones: contexto de seguridad (reclamaciones estándar: iss, sub, exp, aud), contexto del inquilino (tenant_id y ámbitos específicos del inquilino) y contexto de solicitud (atributos específicos del dominio para la lógica empresarial). Codificar el contexto del inquilino de esta manera proporciona una base sólida y flexible para operaciones multiinquilino.
Elija entre dos patrones con distintas implicaciones de seguridad: la suplantación permite a los agentes operar con permisos e identidad de usuario completos, ofreciendo una implementación sencilla pero violando los principios de privilegios mínimos y creando riesgos de seguridad. Actuar en nombre (delegación), el enfoque recomendado, implementa una verdadera delegación donde los tokens se transforman en cada límite de servicio con credenciales de alcance limitado y una reclamación de acto (según OAuth 2.0 RFC 8693) que identifica al agente. Utilice el intercambio de tokens en nombre de AgentCore Identity, lo que permite a los agentes y otras cargas de trabajo, como servidores MCP, intercambiar un token de acceso de usuario entrante por un token de acceso nuevo con alcance dirigido a un servidor de recursos descendente. A medida que el intercambio convierte un token emitido para una audiencia directamente en un token para una audiencia posterior diferente, sus agentes pueden acceder a recursos protegidos en nombre de usuarios autenticados sin activar flujos de consentimiento adicionales. El token intercambiado lleva tanto la identidad del agente como la identidad de la persona que llama original, dando a los servidores de recursos las señales que necesitan para aplicar una autorización detallada y de confianza cero en cada salto.
6. Control de acceso detallado para herramientas y API de MCP
Las aplicaciones agentes multiinquilino requieren restringir el acceso al servidor MCP mediante políticas, control de acceso detallado en la capa de invocación de herramientas y aislamiento de inquilinos en las capas de acceso a datos. En la capa de autorización, las políticas evalúan el contexto del inquilino en tiempo de ejecución para tomar decisiones de autorización/denegación y para evaluar las cuotas de los inquilinos, los permisos basados en niveles y los límites de uso antes de permitir invocaciones de herramientas basadas en el estado actual del inquilino en lugar de depender únicamente de permisos estáticos integrados en los tokens. Los almacenes de políticas desacoplados y centralizados permiten actualizaciones dinámicas sin reimplementación, con versiones de políticas que admiten seguimientos de auditoría y capacidades de reversión. AgentCore Policy intercepta y evalúa todas las solicitudes de los agentes según las políticas definidas antes de permitir el acceso a la herramienta, proporcionando un control detallado basado en la identidad del usuario y los parámetros de entrada de la herramienta, con políticas creadas utilizando lenguaje natural o directamente en Cedar.
En la capa de invocación, los servidores MCP aplican un control de acceso detallado filtrando las herramientas disponibles según el nivel de inquilino, indicadores de características y límites de cuota antes de que los agentes puedan invocarlas. Los interceptores de herramientas validan las afirmaciones de JWT para confirmar que el principal solicitante tiene los permisos adecuados para la operación específica. Las capacidades de traducción de esquemas adaptan las interfaces de las herramientas según las configuraciones y los derechos de los inquilinos. AgentCore Gateway permite a los agentes acceder de forma segura a las herramientas transformando las API y las funciones de AWS Lambda en herramientas compatibles con los agentes y conectándose a servidores MCP existentes, con soporte para Amazon API Gateway, esquemas OpenAPI, modelos Smithy, funciones Lambda y servidores MCP. Puede implementar el control de acceso a través de interceptores de puerta de enlace para una lógica personalizada o utilizar políticas basadas en recursos para un control de acceso estándar al estilo de AWS. En la capa de acceso a datos, las políticas de control de acceso basado en atributos (ABAC) imponen el aislamiento de los inquilinos para el acceso a los datos, y la identificación de los inquilinos se produce a través de notificaciones JWT. Las políticas ABAC utilizan condiciones de AWS Identity and Access Management (IAM) para restringir el acceso a los datos en función de etiquetas y atributos principales, de modo que los agentes solo puedan consultar recursos que coincidan con el contexto de su inquilino a través de políticas de almacenamiento o seguridad a nivel de fila.
7. Memoria: aislamiento del espacio de nombres jerárquico
La gestión de la memoria multiinquilino requiere un diseño arquitectónico cuidadoso para que los agentes puedan mantener el contexto y la información aprendida y, al mismo tiempo, evitar la fuga de datos entre inquilinos. Los sistemas de memoria deben implementar cinco niveles lógicos:
Global (conocimiento compartido entre inquilinos) Estrategia (patrones y comportamientos específicos del tipo de agente) Inquilino (preferencias y historial de conversaciones en el ámbito del inquilino) Usuario (contexto de usuario individual dentro de un inquilino) Sesión (memoria efímera a corto plazo para conversaciones activas)
El control de acceso impone el aislamiento a través de políticas basadas en atributos que validan las identidades principales frente a las rutas de espacio de nombres solicitadas, de modo que los agentes solo puedan leer y escribir memoria dentro de su alcance permitido. El patrón de grupo utiliza una infraestructura compartida con aislamiento lógico basado en espacios de nombres jerárquicos para lograr eficiencia operativa y de costos, almacenando todos los datos de los inquilinos en un almacén de datos común con filtrado estricto basado en prefijos de espacios de nombres. El patrón de silo implementa almacenes de memoria dedicados por inquilino para lograr un aislamiento máximo, lo que reduce el riesgo de acceso entre inquilinos a un mayor costo operativo. La implementación implica construir identificadores compuestos a partir de información de inquilinos y usuarios (por ejemplo, inquilino_123:usuario_456), autenticarse con credenciales de alcance que llevan el contexto del inquilino como notificaciones o etiquetas y anteponer a todas las operaciones de memoria la ruta de espacio de nombres adecuada.
AgentCore Memory proporciona aislamiento jerárquico del espacio de nombres en los niveles global, de estrategia, de inquilino, de usuario y de sesión, lo que admite experiencias de agentes conscientes del contexto con memoria a corto plazo para conversaciones de varios turnos y memoria a largo plazo que persiste entre sesiones. Admite políticas basadas en recursos y control de acceso basado en atributos para un acceso detallado.
8. Identidad, confianza y descubrimiento del agente
A medida que las aplicaciones agentes interactúan con agentes externos a través de los límites organizacionales, surgen tres preocupaciones fundamentales: identidad del agente, confianza del agente y descubrimiento del agente. Si bien están relacionados, cada uno aborda un problema distinto.
Agent Identity responde "¿Quién es este agente? ¿Puede probarlo?" – establecer una identidad única y verificable vinculada a una organización.
Agent Trust responde "¿Debería confiar en este agente?" – evaluar la confiabilidad basándose en una combinación de señales, no en una sola credencial.
Agent Discovery responde "¿Cómo encuentro al agente adecuado?" – localizar agentes por capacidad o afiliación sin conocimiento previo de los puntos finales.
Identidad del agente con AgentCore Identity
Amazon Bedrock AgentCore Identity implementa identidades de agentes como identidades de cargas de trabajo, un patrón bien establecido en seguridad nativa de la nube. Cada agente recibe una identidad verificable criptográficamente anclada a la cuenta de AWS y la infraestructura de IAM de la organización. Los agentes pueden acceder de forma segura a los recursos de AWS y a las herramientas de terceros en nombre de los usuarios mediante flujos de OAuth 2.0, y AgentCore Identity se integra con los proveedores de identidad corporativa existentes, como Okta, Microsoft Entra ID y Amazon Cognito, sin necesidad de migrar al usuario.
Confianza del agente
La identidad por sí sola no determina si se debe confiar en un agente. La industria está trabajando activamente en este problema. El Servicio de nombres de agentes (ANS) v2, actualmente un borrador de Internet del IETF (trabajo en progreso), que ancla cada identidad de agente a un nombre de dominio DNS. Los clientes pueden elegir niveles de garantía que sean apropiados para el riesgo de su transacción con tres niveles de verificación, Bronce (PKI), Plata (PKI + DANE) y Oro (PKI + DANE + Registro de Transparencia).
Descubrimiento de agentes con AWS Agent Registry
AWS Agent Registry, disponible a través de Amazon Bedrock AgentCore, proporciona un catálogo centralizado para descubrir agentes, habilidades, servidores MCP y recursos personalizados en toda una organización. Los equipos pueden publicar, versionar y compartir capacidades de agentes reutilizables. Los consumidores descubren agentes a través del lenguaje natural o la búsqueda estructurada sin necesidad de conocimientos previos de identificadores o puntos finales. Los controles de gobernanza integrados determinan cómo los consumidores acceden al registro y si los registros requieren aprobación antes de ser detectables. En resumen, AgentCore Identity proporciona la prueba fundamental de identidad, Agent Registry resuelve el descubrimiento y los marcos de confianza emergentes como ANS tienen como objetivo cerrar la brecha en la evaluación de confianza de señales múltiples.
9. Seguimiento de costos por inquilino y observabilidad
La atribución precisa de costos multiinquilino requiere instrumentación a nivel de aplicación que emita métricas etiquetadas por inquilino a una solución de registro para cada invocación de agente, capturando tokens de E/S, invocaciones de herramientas y duración de ejecución. El registro estructurado con contexto de inquilino permite un análisis detallado de los patrones de uso, los cuellos de botella en el rendimiento y la planificación de la capacidad. AgentCore Observability proporciona visibilidad en tiempo real de los flujos de trabajo de los agentes con integración compatible con OpenTelemetry impulsada por Amazon CloudWatch, que ofrece visualizaciones detalladas de cada paso de la ejecución del agente.
10. Barandillas: seguridad del contenido
Las barandillas para múltiples inquilinos refuerzan la seguridad y el cumplimiento en tres puntos de aplicación. Las barreras de seguridad de entrada de preprocesamiento validan la entrada del usuario antes del procesamiento del agente, bloqueando mensajes maliciosos, inyecciones de mensajes y desinfectando la PII en función de los requisitos de cumplimiento específicos del inquilino, como HIPAA para atención médica y PCI-DSS para finanzas. Las barreras de seguridad de salida de posprocesamiento validan las respuestas de los agentes para determinar la precisión de los hechos, detectan alucinaciones, confirman el cumplimiento del formato y escanean en busca de fugas de datos confidenciales a través de los límites de los inquilinos. Puede aplicar barreras de seguridad por inquilino o nivel, proporcionando configuraciones para la detección de toxicidad, filtrado de contenido y términos bloqueados personalizados, con métricas de observabilidad que rastrean las tasas de activación, las solicitudes bloqueadas por categoría y las tasas de falsos positivos para una mejora continua. Amazon Bedrock Guardrails proporciona filtrado de contenido y controles de seguridad con políticas configurables para temas denegados, filtros de contenido, filtros de palabras y redacción de información confidencial, lo que respalda la implementación responsable de IA en todas las interacciones del modelo.
Estos diez componentes proporcionan un marco integral para diseñar agentes multiinquilino. En las siguientes secciones, exploramos la implementación de los modelos de silo, grupo y puente dentro de AgentCore, teniendo en cuenta estos componentes principales.
Implementando el modelo Silo con AgentCore
Como se describe en la siguiente figura, el modelo de silo permite que cada inquilino opere dentro de una pila completamente aislada con su propio Bedrock AgentCore Runtime, Bedrock AgentCore Gateway y Bedrock AgentCore Memory dedicados, todos con alcance detrás de límites separados de AWS IAM. Se admiten varias clasificaciones de memoria, como la de largo plazo, la de corto plazo y la episódica, que deben configurarse según los requisitos del inquilino.
Componentes arquitectónicos clave
Capa de agente en silos: tiempo de ejecución de AgentCore dedicado, cada uno implementado con roles de ejecución de IAM separados para permisos específicos del inquilino. Puerta de enlace aislada: puerta de enlace AgentCore dedicada para la orquestación de herramientas mediante MCP, acceso con alcance a la capa de datos según roles de ejecución. Memoria de agente aislada: memoria AgentCore dedicada con aislamiento jerárquico del espacio de nombres, lo que elimina la necesidad de incluir ID de inquilinos en cada ruta del espacio de nombres. Los agentes acceden a la memoria específica del inquilino a través de roles de IAM. Capa de datos aislada: herramientas dedicadas, bases de conocimientos, bases de datos y recursos de backend para un máximo aislamiento de datos.
Flujo de solicitudes
Autenticación: los usuarios se autentican mediante el proveedor de identidad y reciben tokens JWT que contienen el contexto del inquilino (ID del inquilino y nivel de suscripción). Enrutamiento del proxy de la aplicación SaaS: el proxy de la aplicación SaaS decide qué agente invocar en función del contexto del inquilino. Esto requiere que se establezca una configuración de mapeo entre la implementación del inquilino y del agente, una función que generalmente forma parte del plano de control de SaaS. El proxy transforma las solicitudes a nivel de aplicación en llamadas API AgentCore Runtime (InvokeAgent), adjuntando el token JWT del inquilino. Ejecución del agente: AgentCore Runtime valida el JWT utilizando AgentCore Identity, crea una sesión de microVM aislada y comienza el razonamiento del agente. Además, valida si la identificación del inquilino está autorizada para invocar a este agente (por ejemplo, "permitir solo si id_inquilino = Inquilino A") mediante la configuración de reclamos personalizados en el Autorizador JWT de AgentCore Identity. El agente accede a la memoria AgentCore específica del inquilino mediante funciones de ejecución de IAM en tiempo de ejecución. Acceso a herramientas mediante AgentCore Gateway: cuando el agente debe invocar herramientas, llama a AgentCore Gateway dedicado, que tiene un alcance específico para acceder a herramientas MCP para un inquilino específico. La puerta de enlace: valida el JWT utilizando AgentCore Identity. Extrae el contexto del inquilino del token validado y verifica que la puerta de enlace esté asignada al inquilino en contexto mediante interceptores personalizados. Se integra con recursos de backend específicos de inquilinos aislados (API, bases de datos, bases de conocimiento). Flujo de respuesta: las respuestas de la herramienta fluyen de regreso a través del Gateway al agente, que completa su razonamiento. El agente en silos aplica un formato específico del inquilino antes de regresar al proxy de la aplicación SaaS. El proxy devuelve la respuesta al usuario.
El patrón Silo está diseñado para que las sesiones de agente, el acceso a las herramientas y la memoria de cada cliente estén completamente contenidos, y los costos se atribuyan directamente al cliente cuya alerta desencadenó el trabajo. La contrapartida es una mayor sobrecarga operativa, ya que cada cliente ejecuta recursos dedicados en lugar de compartirlos. Pero para flujos de trabajo críticos para la seguridad y sensibles al cumplimiento, el alcance limitado del impacto potencial lo convierte en la opción correcta.
Figura 2: Modelo de silo con AgentCore
Implementación del modelo de grupo con AgentCore
Como se describe en la siguiente figura, el modelo de grupo permite compartir recursos entre múltiples inquilinos, por lo que puede diseñar arquitecturas que maximicen la utilización de recursos y brinden eficiencia operativa.
Componentes arquitectónicos clave
Capa de agente agrupada: tiempo de ejecución de AgentCore compartido y lógica de agente entre varios inquilinos. Pooled Gateway: puerta de enlace AgentCore centralizada para la orquestación de herramientas mediante MCP. Memoria de agente agrupada: memoria AgentCore compartida particionada según el contexto del inquilino. Capa de datos agrupados: herramientas, bases de conocimientos, bases de datos y recursos de backend compartidos. Gestión de identidades agrupadas: proveedor de identidades agrupadas con propagación de contexto de inquilinos basada en JWT.
Flujo de solicitudes
Autenticación: los usuarios se autentican mediante el proveedor de identidad y reciben tokens JWT que contienen el contexto del inquilino (ID del inquilino y nivel de suscripción). Enrutamiento de proxy de aplicación SaaS: la aplicación SaaS actúa como paso a través del cual enruta la solicitud de entrada con el contexto del inquilino a los agentes que se ejecutan en AgentCore Runtime agrupado. El proxy de la aplicación SaaS transforma las solicitudes a nivel de aplicación en llamadas API AgentCore Runtime (InvokeAgent), adjuntando el token JWT del inquilino. Ejecución del agente: AgentCore Runtime valida el JWT utilizando AgentCore Identity, crea una sesión de microVM aislada, extrae el contexto del inquilino del JWT y comienza el razonamiento del agente. El agente accede a la memoria AgentCore del ámbito del inquilino mediante particiones basadas en espacios de nombres (por ejemplo, actor_id: “tenant-a:user-123”). Acceso a herramientas mediante AgentCore Gateway: cuando el agente debe invocar herramientas, llama al AgentCore Gateway agrupado, que está diseñado específicamente para la orquestación de herramientas MCP, no para el enrutamiento genérico. La puerta de enlace: valida el JWT utilizando AgentCore Identity. Extrae el contexto del inquilino del token validado. Enruta llamadas de herramientas a recursos de backend agrupados (API, bases de datos, bases de conocimiento). Aplica el aislamiento a nivel de herramienta a través de configuración y credenciales con ámbito de inquilino. Aplica la aplicación de políticas e interceptores para inquietudes transversales. Flujo de respuesta: las respuestas de la herramienta fluyen de regreso a través del Gateway al agente, que completa su razonamiento. La respuesta del agente regresa a través del tiempo de ejecución al proxy del vendedor, que aplica un formato específico del inquilino antes de regresar al usuario.
El modelo de grupo es muy eficiente y podría ser la única opción cuando se tiene un gran número de inquilinos pequeños. La contrapartida es un mayor rigor en las pruebas de control de acceso detallado y se necesita más instrumentación para atribuir el costo a los inquilinos.
Figura 3: Modelo agrupado con AgentCore
Implementación del modelo puente con AgentCore
El modelo puente (el modelo híbrido) representa un punto medio estratégico entre los patrones de implementación de silo y pool. Este enfoque combina la rentabilidad de la infraestructura compartida con los beneficios de seguridad de los recursos de datos aislados.
Dependiendo de sus necesidades, puede optar por implementar el patrón puente de varias maneras:
Tiempo de ejecución/puerta de enlace/herramienta/memoria de AgentCore en silos para inquilinos de nivel premium y tiempo de ejecución/puerta de enlace/herramienta/memoria de AgentCore compartidos compartidos para tiempo de ejecución en silos de nivel estándar con memoria/puerta de enlace/herramientas agrupadas Otros
La idea es poder elegir el arrendamiento en cada capa y componente, en lugar de vincularlo a un patrón de aislamiento de inquilinos específico. Este enfoque combina los beneficios de ambos enfoques, según su implementación. Por ejemplo, en el caso de uso del analista de SOC, la puerta de enlace podría aislarse para manejar las interacciones de la API de correo electrónico y otros recursos de inquilinos posteriores, mientras que el tiempo de ejecución del agente agrupado aloja al agente y realiza el razonamiento, ya que cada investigación se ejecuta en su propia microVM aislada.
Figura 4: Modelo de puente con AgentCore (variación 1)
Figura 5: Modelo de puente con AgentCore (variación 2)
¿Qué sigue?
En esta publicación, cubrimos los conceptos fundamentales para crear agentes multiinquilino. En las próximas publicaciones, analizaremos más profundamente los aspectos de implementación de estos conceptos. Específicamente, analizaremos una implementación funcional de un extremo a otro de los modelos de implementación de silo y grupo, incorporando los componentes descritos en la sección de consideraciones de diseño.
Conclusión
La creación de aplicaciones agentes multiinquilino listas para producción requiere algo más que agentes de IA funcionales. Exige un enfoque arquitectónico integral que aborde el aislamiento de los inquilinos, la gestión de identidades, la atribución de costos y la seguridad en cada capa. Amazon Bedrock AgentCore proporciona los elementos básicos necesarios para abordar estos desafíos, ofreciendo patrones de implementación flexibles a través de modelos de silo, grupo y puente que se pueden adaptar a su estrategia de niveles específica y a sus requisitos de cumplimiento. Ya sea que esté brindando servicios a clientes empresariales que requieren una infraestructura dedicada u optimizando costos en cientos de inquilinos más pequeños, puede utilizar los componentes integrados de tiempo de ejecución, puerta de enlace, memoria, identidad y observabilidad de AgentCore para crear flujos de trabajo agentes seguros y escalables para múltiples inquilinos sin tener que reinventar la rueda. Estas primitivas trabajan juntas para ayudar a mantener el aislamiento de los datos de los inquilinos, el acceso a herramientas con alcance, la atribución precisa de costos y los límites de seguridad, transformando la complejidad de la arquitectura de agentes multiinquilino en una solución manejable y lista para producción que escala con su negocio SaaS.
Alentamos a los lectores a explorar el taller sobre agentes multiinquilino para obtener experiencia práctica en la creación de estos agentes multiinquilino con Amazon Bedrock AgentCore.
Sobre los autores
Dhawal Patel es líder principal de tecnología de IA generativa en AWS. Ha trabajado con organizaciones que van desde grandes empresas hasta medianas empresas en problemas relacionados con la IA agente, el aprendizaje profundo y la computación distribuida.
Anubhav Sharma es arquitecto principal de soluciones en AWS con más de dos décadas de experiencia en la arquitectura y creación de aplicaciones críticas para el negocio. Trabaja en estrecha colaboración con proveedores de software independientes (ISV), guiándolos en el proceso de creación, implementación y operación de soluciones SaaS en AWS. Más recientemente, ha estado ayudando a los clientes a reinventar sus productos y flujos de trabajo a través de una transformación de IA agente.
Aswin Vasudevan es arquitecto senior de soluciones de seguridad, ISV en AWS. Es un gran admirador de la IA generativa y la arquitectura sin servidor y disfruta colaborar y trabajar con los clientes para crear soluciones que impulsen el valor empresarial.
Sahil Thapar es arquitecto principal de soluciones en AWS, donde trabaja con clientes ISV para crear aplicaciones altamente disponibles, escalables y resistentes en la nube de AWS. Se especializa en contenedores, aprendizaje automático e IA generativa, y ayuda a las empresas a diseñar soluciones de nivel de producción.
Ujwal Bukka es arquitecto de soluciones socio senior en Amazon Web Services con más de 20 años de experiencia en la creación y entrega de aplicaciones escalables de nivel empresarial. Trabaja con proveedores de software independientes (ISV) para diseñar, lanzar y operar soluciones SaaS multiinquilino en AWS. También ayuda a los ISV a modernizar productos y flujos de trabajo utilizando IA agente, respaldando todo, desde el diseño de soluciones en AWS hasta la planificación estratégica y la ejecución de comercialización. A Ujwal le apasiona impulsar el éxito de los socios a través de talleres prácticos, contenido técnico y programas de habilitación de alto impacto.