Cuando un agente de servicio al cliente consulta de forma autónoma bases de datos de pedidos, recupera políticas de devolución y sintetiza respuestas, necesita acceso gobernado a múltiples fuentes de datos en toda su organización. La creación de aplicaciones de IA agentes en una malla de datos moderna requiere un control de acceso detallado aplicado en cada capa de la cadena de interacción de datos. Los agentes de IA que descubren de forma autónoma esquemas de bases de datos, construyen consultas SQL y sintetizan datos de múltiples fuentes exponen brechas de gobernanza que el modelo de punto de control único creado para la generación aumentada de recuperación (RAG) no puede abordar. Las organizaciones necesitan controles desde el descubrimiento de herramientas hasta la ejecución de consultas y la síntesis de respuestas.
En una publicación anterior, Cree aplicaciones RAG seguras con lagos de datos sin servidor de AWS, mostramos cómo aplicar un control de acceso detallado (FGAC) sobre RAG mediante el filtrado de resultados de búsqueda vectorial utilizando metadatos como el dominio empresarial y la clasificación de seguridad. Ese enfoque funcionó porque la interacción de datos de RAG era simple: recuperar fragmentos de un índice vectorial prediseñado, filtrar por metadatos y presentar resultados.
Esta publicación muestra cómo construir una malla de datos gobernada y sin servidor en AWS que proporcione la base de datos segura y escalable que la IA agente de producción requiere. La arquitectura amplía la original con tres cambios clave:
Reemplazar Amazon OpenSearch Serverless con Amazon S3 Vectors para bases de conocimiento con costos optimizados, que pueden reducir el almacenamiento de vectores y los costos de consultas hasta en un 90 % en comparación con soluciones de bases de datos vectoriales especializadas en cargas de trabajo con frecuencia de consultas moderada. Reemplazar Amazon Simple Storage Service (Amazon S3) de uso general con Amazon S3 Tables (con soporte integrado de Apache Iceberg) gobernado por AWS Lake Formation, entregando hasta 10 veces más transacciones por segundo en comparación con las tablas Iceberg autoadministradas, con seguridad detallada a nivel de filas, columnas y celdas. Exponer la malla de datos como herramientas del Protocolo de contexto modelo (MCP) a través de AgentCore Gateway con interceptores respaldados por AWS Lambda para un control de acceso determinista en cada invocación de agente a herramienta.
Requisitos previos
Para implementar esta arquitectura, necesita lo siguiente:
Descripción general de la arquitectura
El siguiente diagrama ilustra el flujo de un extremo a otro desde la solicitud del cliente hasta el acceso a los datos gobernados y viceversa. Cada capa aplica sus propios controles de autorización, por lo que ningún punto de falla puede exponer datos no autorizados. El diagrama de arquitectura muestra cuatro capas: capa de agente con AgentCore Runtime y agente LangGraph, capa de puerta de enlace con interceptores de solicitud y respuesta, capa de herramientas con cuatro herramientas MCP respaldadas por Lambda (get_user_tables, get_schema, run_query, kb_search) y malla de datos gobernada con tablas S3, Athena, Lake Formation y vectores S3. Las flechas muestran el flujo de datos desde el cliente, pasando por el agente, hasta las fuentes de datos gobernadas.
Capa de agente: el cliente interactúa con AgentCore Runtime, un entorno de alojamiento seguro y sin servidor que implementa agentes en entornos microVM aislados con aislamiento de sesión. El agente se ejecuta dentro del marco LangGraph, que se integra con las herramientas MCP a través de la clase MCPClient. Capa de puerta de enlace: la puerta de enlace incluye un interceptor de solicitudes que realiza la validación del token web JSON (JWT) y la aplicación del alcance, un interceptor de respuestas que maneja el filtrado de herramientas, la redacción de datos y el registro de auditoría, y una política AgentCore con Bedrock Guardrails que evalúa las entradas y salidas de cada invocación de herramientas para una inyección rápida, contenido dañino y exposición de información confidencial en tiempo real. Capa de herramientas: cuatro herramientas MCP respaldadas por Lambda (get_user_tables, get_schema, run_query y kb_search) brindan acceso a datos gobernados. Malla de datos gobernada: tablas S3 (Iceberg) registradas en el catálogo de datos de AWS Glue (s3tablescatalog), Amazon Athena con controles de costos de grupo de trabajo, Lake Formation que aplica la seguridad a nivel de fila/columna/celda y vectores S3 que impulsan las bases de conocimiento de Amazon Bedrock.
Por qué la IA agente requiere un nuevo modelo de gobernanza
La arquitectura RAG impuso la gobernanza en un único punto de control: la recuperación de vectores filtrados por metadatos. Ese enfoque sirvió bien para las cargas de trabajo del RAG. Los patrones agentes introducen pasos adicionales, creando una cadena de varios pasos donde cada paso requiere su propia decisión de autorización. En RAG, el sistema consulta un índice vectorial prediseñado con filtros de metadatos en el momento de la recuperación. En la IA agente, el sistema descubre qué tablas existen, comprende esquemas, construye SQL, recupera datos de almacenes de vectores y sintetiza resultados.
Un filtro de metadatos en un único límite de recuperación no puede controlar esta cadena de cinco pasos. Las bases de datos vectoriales sincronizan los permisos periódicamente, lo que significa que las revocaciones no se reflejan de inmediato. Esta es una brecha inaceptable cuando un agente actúa de forma autónoma sobre los datos. Los permisos de identidad complejos, como las jerarquías de roles, el acceso basado en atributos y los filtros a nivel de fila, no se pueden expresar como pares clave-valor de metadatos sencillos en fragmentos de vectores.
Estas limitaciones motivan el cambio a una arquitectura de malla de datos gobernada donde la autorización se aplica de forma nativa en cada capa de acceso a datos.
Construyendo una malla de datos sin servidor gobernada
Una malla de datos descentraliza la propiedad de los datos a los equipos de dominio al tiempo que centraliza la gobernanza y la capacidad de descubrimiento. En AWS, los equipos de dominio son propietarios de sus productos de datos de un extremo a otro, AWS Glue Data Catalog proporciona descubrimiento de metadatos centralizado y Lake Formation aplica permisos con semántica de concesión/revocación en bases de datos, tablas, columnas, filas y celdas.
Cada dominio de productor reside en su propia cuenta de AWS. Los productores registran productos de datos en una cuenta de gobernanza central, una cuenta de AWS dedicada que aloja las políticas autorizadas de permisos de AWS Glue Data Catalog y Lake Formation para toda la organización. Los datos se comparten a través del intercambio entre cuentas de Lake Formation. No se copia ningún dato. Sólo los metadatos están vinculados a través de enlaces de recursos en los catálogos de consumidores. En el momento de la consulta, Lake Formation verifica los permisos y emite credenciales temporales al motor de consultas. El control de acceso basado en etiquetas (LF-TBAC) escala esto dinámicamente. Los administradores asignan etiquetas LF como clasificación=PII o departamento=servicio_cliente a los recursos y otorgan permisos basados en esas etiquetas.
Las siguientes subsecciones describen cómo implementamos las dos capas de datos de esta malla. Primero, cubrimos las tablas transaccionales Iceberg para datos estructurados (registros de pedidos, perfiles de clientes) regidos por la seguridad de filas y columnas de Lake Formation. Luego, describimos el almacén de vectores de conocimiento no estructurado (políticas, preguntas frecuentes) que impulsa la búsqueda semántica.
Tablas S3 con Apache Iceberg para datos transaccionales
Para nuestro agente de servicio al cliente, el equipo de dominio de Gestión de pedidos publica datos de pedidos y clientes mediante tablas de Amazon S3. S3 Tables es el primer almacén de objetos en la nube con soporte integrado para Apache Iceberg, que ofrece hasta 10 veces más transacciones por segundo en comparación con las tablas Iceberg autoadministradas en depósitos S3 de uso general. Maneja automáticamente la compactación, la administración de instantáneas y la eliminación de archivos sin referencia.
S3 Tables se integra con Amazon SageMaker Lakehouse, que completa el catálogo de datos de AWS Glue y federa el acceso a través de Lake Formation. Los tres productos de datos (pedidos_cliente, perfiles_cliente e historial_interacción) se pueden consultar desde Amazon Athena, se rigen por permisos de Lake Formation y se compactan automáticamente mediante tablas S3.
Los filtros de datos de Lake Formation aplican seguridad a nivel de fila para que el agente solo pueda acceder a los registros que pertenecen al cliente autenticado. Un filtro de datos en customer_orders con la expresión de filtro de fila customer_id = :customer_id restringe cada consulta a los registros del cliente actual, independientemente de cómo el agente construya su SQL. La función run_query Lambda inyecta la identidad del cliente autenticado como parámetro de sesión antes de enviar consultas a Athena. La seguridad a nivel de columna oculta por completo campos confidenciales como método_de_pago y dirección_de_facturación de los resultados de la consulta.
Creación de una base de conocimientos con Amazon S3 Vectors
Los datos estructurados por sí solos no son suficientes. Los clientes necesitan respuestas extraídas de conocimientos no estructurados (manuales de productos, políticas de devolución, preguntas frecuentes (FAQ) y guías de solución de problemas) que requieren capacidades de búsqueda semántica.
Amazon S3 Vectors proporciona almacenamiento vectorial nativo y soporte de consultas como un servicio totalmente sin servidor. Admite hasta 2 mil millones de vectores por índice y proporciona una sólida coherencia de escritura, lo que significa que los vectores recién agregados se pueden consultar de inmediato.
Ventajas de costes de los vectores S3
Los clientes que utilizan la función de base de conocimientos en Amazon Bedrock pueden seleccionar S3 Vectors como almacén de vectores, lo que puede reducir los costos hasta en un 90 por ciento en comparación con las soluciones de bases de datos vectoriales especializadas en cargas de trabajo de frecuencia de consultas moderadas. Para cargas de trabajo de altas consultas por segundo (QPS) que requieren una latencia de milisegundos de un solo dígito, Amazon OpenSearch Serverless sigue siendo la mejor opción. AWS proporciona exportación en un solo paso desde S3 Vectors a colecciones sin servidor de Amazon OpenSearch para cargas de trabajo que superan el perfil de rendimiento de S3 Vectors.
S3 Vectors admite metadatos filtrables (cadena, número, booleano, tipos de lista con operadores como $eq, $ne, $gt, $in, $and, $or) y metadatos no filtrables para datos contextuales más grandes devueltos con resultados. En nuestro caso de uso, los documentos se almacenan con claves de metadatos filtrables como product_category y document_type, que admiten la búsqueda semántica dirigida. El siguiente ejemplo muestra un filtro de metadatos que recupera solo políticas de devolución de productos electrónicos:
Exponer la malla de datos con AgentCore Gateway
Una vez implementada la malla de datos gobernada y la base de conocimientos, el próximo desafío es exponer estas capacidades al agente de IA de una manera segura, reconocible y estandarizada. Esta sección cubre las herramientas, los interceptores y los patrones de propagación de identidades que lo hacen posible.
AgentCore Gateway proporciona una capa centralizada para gestionar cómo los agentes de IA se conectan a las herramientas. Consolida la autenticación, la observabilidad y la aplicación de políticas en un único punto final. Gateway convierte funciones Lambda, API y servidores MCP existentes en herramientas compatibles con MCP con traducción de protocolos, autorización OAuth entrante y administración de credenciales salientes. Los agentes se conectan a través de transporte HTTP transmitible con un token de portador de OAuth.
Cuatro herramientas de datos centrales
Cuatro herramientas MCP respaldadas por Lambda brindan acceso a datos gobernados a través de Gateway. get_user_tables consulta el catálogo de datos de AWS Glue filtrado por los permisos de Lake Formation para devolver tablas autorizadas. get_schema recupera nombres, tipos y descripciones de columnas para una tabla específica. run_query valida SQL con una lista de permitidos de solo lectura, inyecta la identidad del cliente para el filtrado a nivel de fila y se ejecuta a través de Athena con límites de costo de escaneo de bytes. kb_search realiza una búsqueda semántica filtrada por metadatos en las bases de conocimiento de Amazon Bedrock.
Con el lanzamiento de Amazon Bedrock Managed Knowledge Base, las bases de conocimiento ahora están disponibles como un tipo de destino nativo prediseñado en AgentCore Gateway. Esto significa que puede exponer una base de conocimientos a través de Gateway sin una función Lambda personalizada. Gateway genera automáticamente roles de IAM, proporciona métricas de evaluación y observabilidad integradas y aplica políticas a través de la política AgentCore. En esta arquitectura, utilizamos una herramienta kb_search personalizada respaldada por Lambda para demostrar cómo los interceptores de Gateway aplican la autorización detallada y el filtrado de metadatos en el límite de invocación de la herramienta. Para cargas de trabajo de producción donde no se requiere una lógica de interceptor personalizada, el tipo de destino de KB administrado nativo reduce la sobrecarga operativa al eliminar la función Lambda por completo y al mismo tiempo conservar la compatibilidad con MCP y la aplicación de la política AgentCore.
El siguiente JSON muestra el registro del esquema de herramienta para run_query.
Implementación de interceptores y herramientas MCP:
Clone el repositorio de muestras del interceptor AgentCore Gateway. Para cada función Lambda (get_user_tables, get_schema, run_query, kb_search, interceptor de solicitudes, interceptor de respuestas), cree la función mediante la CLI de AWS:
Adjunte las políticas de IAM definidas en el directorio políticas/ del repositorio al rol de ejecución de cada función. Registre las funciones Lambda como objetivos de la herramienta MCP en AgentCore Gateway. Para obtener instrucciones, consulte Registro de objetivos de herramientas. Adjunte los interceptores de solicitud y respuesta a la puerta de enlace. Para obtener instrucciones, consulte los ejemplos del interceptor AgentCore Gateway.
Nota: Para obtener el código fuente completo de la función Lambda, las políticas de IAM y las instrucciones de implementación para las cuatro herramientas MCP y ambos interceptores, consulte los ejemplos del interceptor AgentCore Gateway.
Interceptores para control de acceso determinista
Los interceptores de AgentCore Gateway son funciones Lambda personalizadas que aplican la autorización en dos etapas del ciclo de vida de solicitud-respuesta. Los interceptores actúan como middleware que inspecciona, transforma o bloquea las solicitudes y respuestas que fluyen a través del Gateway. Un interceptor de solicitudes se ejecuta antes de que la puerta de enlace llame al Lambda de destino, y un interceptor de respuestas se ejecuta después de que el objetivo responde pero antes de que los resultados lleguen a la persona que llama.
Los patrones de interceptor resuelven distintos desafíos de seguridad en cada etapa:
Desafío de patrón resuelto Cómo control de invocaciones de herramientas basadas en el alcance de JWT Acceso no autorizado a herramientas El interceptor de solicitudes decodifica la reclamación de alcance de JWT y bloquea las herramientas/invocaciones de llamadas no autorizadas Filtrado dinámico de herramientas Fuga de descubrimiento de herramientas El interceptor de respuestas elimina las herramientas no autorizadas de las herramientas/listas según los alcances por usuario Propagación de identidades de acción en nombre Escalada de privilegios/delegado confundido] Cada salto recibe un token separado y con alcance reducido (por ejemplo, la herramienta de pedidos solo obtiene orden: lectura; la herramienta KB solo obtiene kb: búsqueda)
La verificación de autorización es intencionalmente mínima:
Para el filtrado dinámico de herramientas, el interceptor de respuesta filtra la respuesta de herramientas/lista:
Para los tokens de acción en nombre, cada token incluye un campo Acto: Agente que establece una cadena de responsabilidad clara. Una herramienta posterior no autorizada no puede reutilizar un token con privilegios excesivos para acceder a otras herramientas.
Los interceptores de puerta de enlace aplican la autorización de manera determinista en el límite de invocación de la herramienta antes de que el modelo vea o ejecute las herramientas. Sin embargo, la construcción SQL del agente todavía depende del comportamiento del modelo. Los límites de escaneo de bytes de Athena, las políticas de IAM de solo lectura y los filtros de filas de Lake Formation sirven como controles de compensación que limitan el alcance de las consultas con formato incorrecto que el modelo podría producir.
Flujo de solicitudes de agentes: el escenario de servicio al cliente en acción
A lo largo de esta publicación, un escenario de servicio al cliente demuestra la arquitectura en funcionamiento. Un cliente se pone en contacto con el servicio de asistencia y pregunta: "¿Dónde está mi pedido n.º 12345? ¿Aún puedo devolver los auriculares que compré la semana pasada?" El agente necesita consultar las tablas Iceberg gobernadas para conocer el estado del pedido, recuperar las políticas de devolución de una base de conocimiento vectorial y sintetizar una respuesta completa respetando las barreras de costos y las restricciones regulatorias. La seguridad a nivel de fila es fundamental porque cada fila de la tabla customer_orders representa el pedido de un cliente específico. Sin filtrado a nivel de fila, un agente que actúa en nombre del Cliente A podría acceder inadvertidamente al historial de pedidos, los detalles de envío o los patrones de compra del Cliente B.
Los siguientes pasos rastrean la interacción completa a través de cada capa de gobernanza, como se muestra en el siguiente diagrama:
Descubrimiento de herramientas: el agente llama al punto final de lista/herramientas de la puerta de enlace. El interceptor de respuesta filtra la lista de herramientas según los alcances JWT del representante y devuelve cuatro herramientas autorizadas. Descubrimiento de tablas: a continuación, se invoca get_user_tables. El interceptor de solicitudes valida el JWT y confirma el orden: alcance de lectura. Lambda devuelve tres tablas: pedidos_clientes, perfiles_clientes e historial_interacción. Descubrimiento de esquema: una llamada get_schema en pedidos_clientes revela las columnas ID_pedido, estado, fecha_envío, entrega_estimada y nombre_producto. La seguridad a nivel de columna de Lake Formation excluye el método de pago y la dirección de facturación, lo que hace que estas columnas sean invisibles para el agente. Ejecución de consultas: la consulta construida SELECT id_pedido, estado, fecha_envío, entrega_estimada FROM pedidos_clientes WHERE id_pedido = '12345' se envía a través de run_query, que inyecta la identidad del cliente autenticado para resolver el filtro de fila de Lake Formation. El grupo de trabajo de Athena aplica un límite de BytesScannedCutoffPerQuery (por ejemplo, 100 MB) y la política de IAM de solo lectura niega las acciones mutantes de AWS Glue. El resultado: pedido n.º 12345 enviado el 20 de marzo, entrega estimada el 25 de marzo. Recuperación de la base de conocimientos: simultáneamente, kb_search se ejecuta con la consulta "política de devolución de productos electrónicos" y el filtro de metadatos {"product_category": {"$eq": "electronics"}}. La política de devolución establece: "Los productos electrónicos pueden devolverse dentro de los 30 días posteriores a la compra en su embalaje original para obtener un reembolso completo". Síntesis de respuesta: la respuesta final combina ambos resultados: "Su pedido #12345 se envió el 20 de marzo y se estima que llegará el 25 de marzo. Con respecto a los auriculares, nuestra política de devolución de productos electrónicos permite devoluciones dentro de los 30 días posteriores a la compra en el embalaje original. Puedo iniciar una devolución por usted. ¿Le gustaría continuar?"
La autorización se aplicó en diferentes capas en cada paso utilizando interceptores de Gateway para los pasos 1 y 2, Lake Formation para los pasos 3 y 4, límites del grupo de trabajo de Athena para el paso 4 y filtrado de metadatos de S3 Vectors para el paso 5. Este enfoque de defensa en profundidad reduce el riesgo de que una falla en un solo control exponga datos no autorizados.
Gobernanza de consultas y barreras de seguridad
Una gobernanza sólida es esencial para los agentes que construyen SQL de forma autónoma. Esta sección describe las cinco capas superpuestas de protección que colectivamente limitan lo que un agente puede consultar, cuántos datos puede escanear y qué información llega al modelo.
La primera capa son los controles de costos del grupo de trabajo de Athena. Cada consulta de agente se ejecuta dentro de un grupo de trabajo dedicado de Athena configurado con un límite de BytesScannedCutoffPerQuery. Si una consulta supera este umbral, Athena la cancela automáticamente. La configuración EnforceWorkGroupConfiguration ayuda a evitar que el agente pase por alto estos límites. Las alertas de uso de datos agregados por grupo de trabajo activan notificaciones de Amazon Simple Notification Service (Amazon SNS) cuando el total de datos analizados supera los umbrales.
La segunda capa es la prevención del lenguaje de definición de datos (DDL) a través de políticas de IAM de solo lectura. La función de ejecución de Lambda conlleva una denegación explícita para mutar acciones del catálogo de datos de Glue (glue:CreateTable, pegamento:DeleteTable, pegamento:UpdateTable y equivalentes a nivel de partición). Lake Formation agrega un controlador DDL adicional: una entidad principal no puede crear bases de datos o tablas a menos que se le otorguen explícitamente esos permisos.
La tercera capa es el acceso detallado a la Formación del Lago. Las políticas de seguridad en cinco niveles de granularidad (base de datos, tabla, columna, fila y celda) se aplican de forma nativa en Amazon Athena, Amazon Redshift Spectrum, extracción, transformación y carga (ETL) de AWS Glue y Amazon EMR sin costo adicional. Para obtener más información, consulte Filtrado de datos de Lake Formation.
La cuarta capa son los interceptores de puerta de enlace. Los interceptores de solicitudes aplican la autorización basada en el alcance de JWT antes de la ejecución de la herramienta. Los interceptores de respuesta filtran listas de herramientas y redactan datos confidenciales de los resultados de las consultas.
La quinta capa son Amazon Bedrock Guardrails que se aplican a través de la política AgentCore en el Gateway. En lugar de aplicar controles de seguridad de contenido solo en el límite de inferencia del modelo, Guardrails ahora se integran directamente en AgentCore Policy Engine, donde evalúan las entradas y salidas de cada acción autorizada del agente y cada llamada a un objetivo de puerta de enlace, incluidas herramientas, agentes y modelos en tiempo real. Esto significa que los ataques de inyección rápida, el contenido dañino y la exposición de información confidencial se detectan y bloquean antes de que lleguen a los sistemas posteriores, y no simplemente se detectan en el camino de regreso del modelo. Policy Engine aplica estas barreras de seguridad de manera determinista en la capa de puerta de enlace junto con los controles de acceso basados en interceptores descritos anteriormente, creando un punto de aplicación unificado tanto para la autorización como para la seguridad del contenido. Para cargas de trabajo que requieren controles adicionales de capa de modelo, Amazon Bedrock Guardrails aún se puede aplicar en el límite de inferencia del modelo como defensa complementaria.
Por qué las barreras de seguridad a nivel de puerta de enlace son preferibles para cargas de trabajo agentes
En una arquitectura RAG tradicional, aplicar barreras de seguridad exclusivamente en el límite de inferencia del modelo es suficiente porque las interacciones de datos siguen un patrón único de recuperación y luego generación. El modelo es el único componente que sintetiza información, por lo que al filtrar su salida se detectan todas las violaciones de políticas. Sin embargo, en las arquitecturas agentic, el agente invoca de forma autónoma múltiples herramientas, construye consultas y sintetiza resultados en varios saltos antes de que se genere cualquier respuesta del modelo. Una barrera de seguridad que solo evalúa la salida final del modelo no puede evitar que una entrada maliciosa o manipulada llegue a la invocación de una herramienta; por ejemplo, una inyección rápida incorporada en la respuesta de una herramienta podría influir en llamadas posteriores a la herramienta antes de que el modelo produzca una respuesta final. Al aplicar barreras de seguridad en la puerta de enlace a través de la política AgentCore, cada interacción entre el agente y la herramienta se evalúa en tiempo real, lo que brinda defensa en el punto de acción y no solo en el punto de salida.
Compensaciones con el enfoque alternativo
La aplicación de barreras de seguridad únicamente en la inferencia del modelo ofrece simplicidad: un único punto de integración sin cambios en la infraestructura de la herramienta. Sin embargo, este enfoque introduce tres lagunas en los patrones agentes. En primer lugar, crea un punto ciego temporal que el contenido dañino puede propagar a través de llamadas a herramientas intermedias antes de alcanzar el límite de salida del modelo. En segundo lugar, no puede aplicar políticas específicas de herramientas (por ejemplo , bloquear ciertos patrones de consulta para la herramienta run_query y permitirlos para kb_search ). En tercer lugar, depende completamente de la cooperación del modelo para sacar a la luz los resultados de las herramientas para su evaluación, lo que no está garantizado en cadenas de razonamiento de múltiples pasos. El enfoque basado en Gateway elimina estas brechas al evaluar cada solicitud y respuesta en el límite de invocación de la herramienta, lo que permite la personalización de políticas por herramienta, el bloqueo en tiempo real de la inyección rápida en las entradas de la herramienta y la aplicación determinista independiente del comportamiento del modelo .
Ninguna capa es la única responsable. La defensa en profundidad, aplicada en diferentes capas, desde la red hasta la aplicación y el modelo, está diseñada para ayudar a evitar que una falla en un solo control exponga datos no autorizados.
Verifique su implementación
Después de implementar la arquitectura, valide cada capa de gobernanza:
Llame al punto final de lista/herramientas de la puerta de enlace con un token JWT con alcance que incluya el alcance de orden: lectura. Verifique que solo aparezcan herramientas autorizadas en la respuesta. Llame al punto final de lista/herramientas de la puerta de enlace con un token al que le falta el orden: alcance de lectura. Verifique que get_user_tables no se devuelva en la respuesta. Invoca get_user_tables. Verifique que la respuesta contenga solo las tablas que permiten sus permisos de Lake Formation. Verifique que las tablas de otros dominios no sean visibles en la respuesta. Ejecute run_query con una consulta contra customer_orders para el cliente autenticado. Verifique que los resultados contengan solo registros para el ID de cliente autenticado. Ejecute run_query con una consulta que intente acceder a los registros de otro cliente. Verifique que la consulta devuelva un conjunto de resultados vacío. Ejecute get_schema en customer_orders. Verifique que el método de pago y la dirección de facturación no aparezcan en la respuesta. Envíe una consulta que analice más que el límite de BytesScannedCutoffPerQuery. Verifique que Athena cancele la consulta y devuelva un error. Invoque kb_search con un filtro de metadatos. Verifique que los resultados coincidan solo con la categoría especificada.
Si encuentra errores, consulte los registros de Amazon CloudWatch para conocer las funciones de Lambda y verifique que los roles de IAM tengan los permisos correctos.
Limpiar
Para evitar cargos continuos, elimine los siguientes recursos una vez que termine de explorar esta arquitectura:
Funciones Lambda: elimine las cuatro funciones de la herramienta MCP (get_user_tables, get_schema, run_query, kb_search) y las dos funciones interceptoras. Para obtener instrucciones, consulte Eliminación de funciones Lambda. AgentCore Gateway: elimine la puerta de enlace y sus objetivos registrados. Para obtener instrucciones, consulte Eliminación de una puerta de enlace. Grupo de trabajo de Amazon Athena: elimine el grupo de trabajo del agente dedicado (esto no elimina los resultados de la consulta almacenados en S3). Para obtener instrucciones, consulte Eliminar un grupo de trabajo. Depósito de tablas de Amazon S3 Tables: Advertencia: esto elimina permanentemente todos los datos de las tablas Iceberg (pedidos de clientes, perfiles, historial de interacciones). Elimine el depósito de tablas que contiene las tablas Iceberg. Para obtener instrucciones, consulte Eliminar un depósito de tablas. Índice de vectores de Amazon S3: esto elimina permanentemente todo el contenido de la base de conocimientos (manuales de productos, políticas, preguntas frecuentes). Elimine el índice del vector y su depósito S3 asociado. Para obtener instrucciones, consulte Eliminar un índice de vector. Bases de conocimientos de Amazon Bedrock: elimine la configuración de la base de conocimientos. Para obtener instrucciones, consulte Eliminar una base de conocimientos. Permisos de Lake Formation: revocar las subvenciones de Lake Formation. Para obtener instrucciones, consulte Revocación de permisos. Filtros de datos de Lake Formation: elimine los filtros de datos creados para la seguridad a nivel de fila. Para obtener instrucciones, consulte Administrar filtros de datos. Catálogo de datos de AWS Glue: elimine la base de datos s3tablescatalog, las tablas registradas y cualquier enlace de recursos creado para compartir entre cuentas. Para obtener instrucciones, consulte Eliminación de bases de datos y tablas. Roles y políticas de IAM: elimine los roles y políticas de ejecución creados para esta arquitectura. Para obtener instrucciones, consulte Eliminación de funciones de IAM.
Conclusión
El cambio de RAG a IA agente amplía la superficie de gobernanza. RAG requería un único punto de control de recuperación filtrado de metadatos. Agentic AI introduce el descubrimiento autónomo de esquemas, la construcción de SQL, la síntesis de múltiples fuentes y la invocación de herramientas, cada uno de los cuales requiere su propio control de autorización. Esta publicación demostró cómo abordar esa superficie ampliada con una malla de datos gobernada en AWS que combina Amazon S3 Tables para almacenamiento transaccional con seguridad de Lake Formation, Amazon S3 Vectors para búsqueda semántica de costo optimizado, interceptores AgentCore Gateway para autorización determinista a nivel de herramienta, controles de grupo de trabajo Athena para gobernanza de costos de consultas y Amazon Bedrock Guardrails para seguridad de contenido en inferencia de modelos. Juntas, estas capas respaldan la implementación de producción para industrias altamente reguladas donde el cumplimiento requiere una defensa en profundidad en cada punto de decisión de acceso a datos.
Próximos pasos
Para comenzar a crear su propia arquitectura de agente gobernado, realice las siguientes acciones:
Sobre los autores
Venkata Sistla
Venkata es arquitecto senior de soluciones especializado en el equipo mundial de AWS y aporta más de 15 años de experiencia en arquitectura de nube. Se especializa en diseñar e implementar sistemas de IA/ML a escala empresarial en múltiples sectores verticales, ayudando a las organizaciones a transformar desafíos de datos complejos en ventajas competitivas a través de soluciones innovadoras en la nube. Su experiencia en múltiples industrias le permite diseñar infraestructuras altamente escalables que aceleran las iniciativas de aprendizaje automático y brindan resultados comerciales mensurables. Mentor dedicado y líder técnico, le apasiona impulsar la excelencia tecnológica y capacitar a los equipos para superar los límites de lo que es posible con la nube y la IA.
Aamna Najmi
Aamna es arquitecta senior de soluciones especializada en IA generativa que se centra en modelos antrópicos y en la operacionalización y gobierno de sistemas de IA generativa a escala en Amazon Bedrock. Ayuda a los ISV a resolver sus desafíos, adoptar la innovación y crear nuevas oportunidades comerciales con Amazon Bedrock. En su tiempo libre persigue su pasión por experimentar con la comida y descubrir nuevos lugares.
Prachi Gupta
Prachi es un especialista en datos e inteligencia artificial con más de 9 años de experiencia en la creación de arquitecturas de nube a escala empresarial. Se desempeña como arquitecta de soluciones especializada senior en el equipo mundial de AWS, donde se especializa en datos, análisis e IA/ML, con profunda experiencia en Apache Iceberg y Amazon S3 Tables, ayudando a las organizaciones a superar la complejidad de los datos para ofrecer resultados comerciales mensurables. Como oradora técnica, formadora y mentora, ofrece sesiones en eventos como AWS re:Invent y Summits, al tiempo que permite a los equipos aumentar sus habilidades y su confianza en los datos y la IA. Fuera del trabajo, fomenta y defiende el rescate de animales, explora el aire libre o se la puede encontrar perdida en un buen libro.