User's blog

Construindo aplicações de IA agêntica com data mesh na AWS

Written by

Make.com Service User

in

O problema que RAG não resolve para agentes autônomos

Quando um agente de atendimento ao cliente precisa consultar bancos de dados de pedidos, recuperar políticas de devolução e sintetizar uma resposta completa de forma autônoma, ele está acessando múltiplas fontes de dados ao mesmo tempo. E cada um desses acessos precisa ser governado de forma independente.

A AWS publicou um artigo técnico aprofundado mostrando por que o modelo de governança pensado para Geração Aumentada por Recuperação (RAG) não é suficiente para esse cenário — e como construir uma fundação de dados segura, escalável e serverless para agentes de IA em produção.

Em um post anterior sobre aplicações RAG seguras com data lakes serverless, a AWS demonstrou como aplicar controle de acesso refinado filtrando resultados de busca vetorial com metadados como domínio de negócio e classificação de segurança. Essa abordagem funciona bem para RAG porque o fluxo de dados é simples: recuperar trechos de um índice vetorial pré-construído, filtrar por metadados e apresentar os resultados.

Com IA agêntica, o cenário muda. O agente descobre quais tabelas existem, entende esquemas, constrói consultas SQL, busca em bases de conhecimento vetorial e sintetiza tudo isso em múltiplas etapas. Um único filtro de metadados na borda da recuperação não consegue governar essa cadeia de cinco passos. Além disso, bancos de dados vetoriais sincronizam permissões periodicamente — o que significa que revogações de acesso não são refletidas imediatamente, uma lacuna inaceitável quando um agente age de forma autônoma sobre dados sensíveis.

A arquitetura de data mesh governado

A solução proposta pela AWS organiza a arquitetura em quatro camadas distintas, cada uma com seus próprios controles de autorização:

  • Camada do Agente: o AgentCore Runtime hospeda o agente em microVMs isolados com isolamento de sessão. O agente opera dentro do framework LangGraph, que se integra às ferramentas via MCPClient.
  • Camada do Gateway: o AgentCore Gateway inclui um interceptador de requisições (validação de token JWT e aplicação de escopos), um interceptador de respostas (filtragem de ferramentas, redação de dados e log de auditoria) e a AgentCore Policy com Amazon Bedrock Guardrails, que avalia entradas e saídas de cada invocação de ferramenta em tempo real.
  • Camada de Ferramentas: quatro ferramentas MCP com suporte Lambda (get_user_tables, get_schema, run_query e kb_search) fornecem acesso governado aos dados.
  • Data Mesh Governado: Amazon S3 Tables (Iceberg) registradas no AWS Glue Data Catalog, Amazon Athena com controles de custo por workgroup, AWS Lake Formation aplicando segurança em nível de linha, coluna e célula, e Amazon S3 Vectors alimentando as Knowledge Bases do Amazon Bedrock.

A ideia central é que nenhuma camada sozinha é responsável pela segurança. A defesa em profundidade garante que uma falha em um único controle não exponha dados não autorizados.

Três mudanças-chave em relação à arquitetura anterior

A arquitetura descrita no artigo evolui o modelo RAG anterior com três substituições importantes:

  • Substituição do Amazon OpenSearch Serverless pelo Amazon S3 Vectors para bases de conhecimento com custo otimizado — com potencial de reduzir custos de armazenamento e consulta vetorial em até 90% em cargas de trabalho com frequência moderada de consultas.
  • Substituição do Amazon S3 de uso geral pelo Amazon S3 Tables com suporte nativo ao Apache Iceberg, governado pelo AWS Lake Formation — entregando até 10 vezes mais transações por segundo em comparação com tabelas Iceberg autogerenciadas, com segurança granular em nível de linha, coluna e célula.
  • Exposição do data mesh como ferramentas do Protocolo de Contexto de Modelo (MCP) via AgentCore Gateway com interceptadores Lambda para controle de acesso determinístico em cada invocação agente-ferramenta.

Dados transacionais: S3 Tables com Apache Iceberg

Para dados estruturados como registros de pedidos e perfis de clientes, a AWS utiliza o Amazon S3 Tables, descrito como o primeiro object store em nuvem com suporte nativo ao Apache Iceberg. O serviço gerencia automaticamente compactação, snapshots e remoção de arquivos não referenciados.

O S3 Tables se integra ao Amazon SageMaker Lakehouse, que popula o AWS Glue Data Catalog e federa o acesso via Lake Formation. Os três produtos de dados do exemplo (customer_orders, customer_profiles e interaction_history) são consultáveis via Amazon Athena, governados por permissões do Lake Formation e compactados automaticamente pelo S3 Tables.

Os filtros de dados do Lake Formation aplicam segurança em nível de linha: um filtro com a expressão customer_id = :customer_id restringe todas as consultas aos registros do cliente autenticado, independentemente de como o agente construiu o SQL. A segurança em nível de coluna oculta campos sensíveis como payment_method e billing_address completamente dos resultados.

Base de conhecimento vetorial: Amazon S3 Vectors

Para dados não estruturados como manuais de produtos, políticas de devolução e perguntas frequentes, a arquitetura usa o Amazon S3 Vectors, um serviço totalmente serverless com suporte nativo a armazenamento e consulta vetorial. O serviço suporta até 2 bilhões de vetores por índice e oferece consistência forte de escrita — vetores recém-adicionados são imediatamente consultáveis.

Clientes que usam o recurso de Knowledge Base no Amazon Bedrock podem selecionar o S3 Vectors como vector store, com potencial de redução de custos de até 90% em cargas de trabalho com frequência moderada de consultas. Para cargas de trabalho de alto volume de consultas por segundo (QPS) que exigem latência de milissegundos de um dígito, o Amazon OpenSearch Serverless ainda é a melhor opção. A AWS oferece exportação em etapa única do S3 Vectors para coleções do OpenSearch Serverless para cargas que superem o perfil de desempenho do S3 Vectors.

O S3 Vectors suporta metadados filtráveis (tipos string, número, booleano e lista, com operadores como $eq, $ne, $gt, $in, $and, $or). No exemplo do artigo, documentos são armazenados com chaves de metadados filtráveis como product_category e document_type. O filtro a seguir recupera apenas políticas de devolução de eletrônicos:

{"$and": [{"product_category": {"$eq": "electronics"}}, {"document_type": {"$eq": "return_policy"}}]}

AgentCore Gateway: expondo o data mesh com segurança

O AgentCore Gateway é a camada centralizada que gerencia como os agentes de IA se conectam às ferramentas. Ele consolida autenticação, observabilidade e aplicação de políticas em um único endpoint, convertendo funções Lambda, APIs e servidores MCP existentes em ferramentas compatíveis com MCP.

As quatro ferramentas MCP do exemplo têm funções bem definidas:

  • get_user_tables: consulta o AWS Glue Data Catalog filtrado pelas permissões do Lake Formation para retornar tabelas autorizadas.
  • get_schema: recupera nomes de colunas, tipos e descrições de uma tabela especificada.
  • run_query: valida SQL contra uma lista de permissões somente leitura, injeta a identidade do cliente para filtragem em nível de linha e executa via Athena com limites de custo por bytes escaneados.
  • kb_search: realiza busca semântica com filtros de metadados contra as Knowledge Bases no Amazon Bedrock.

O esquema de registro da ferramenta run_query no Gateway é definido da seguinte forma:

{
  "name": "run_query",
  "description": "Executes a read-only SQL query against governed Iceberg tables via Amazon Athena with byte-scan limits and Lake Formation row-level security.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql": {"type": "string", "description": "A read-only SQL SELECT statement."},
      "database": {"type": "string", "description": "The Glue Data Catalog database name."}
    },
    "required": ["sql", "database"]
  }
}

Interceptadores: controle de acesso determinístico

Os interceptadores do AgentCore Gateway são funções Lambda personalizadas que aplicam autorização em dois momentos do ciclo de vida da requisição: antes de o Gateway chamar a Lambda de destino (interceptador de requisição) e depois que o destino responde mas antes de os resultados chegarem ao chamador (interceptador de resposta).

O artigo descreve três padrões principais de interceptação:

  • Controle de invocação por escopo JWT: o interceptador de requisição decodifica o campo de escopo do token e bloqueia invocações de ferramentas não autorizadas.
  • Filtragem dinâmica de ferramentas: o interceptador de resposta remove ferramentas não autorizadas da resposta tools/list com base nos escopos por usuário.
  • Propagação de identidade act-on-behalf: cada hop recebe um token separado com escopo reduzido (por exemplo, a ferramenta de pedidos recebe apenas order:read; a ferramenta de KB recebe apenas kb:search), evitando escalada de privilégios e o problema do confused deputy.

O código do interceptador de resposta para filtragem dinâmica de ferramentas é o seguinte:

def lambda_handler(event, context):
    gateway_response = event['mcp']['gatewayResponse']
    auth_header = gateway_response['headers'].get('Authorization', '')
    token = auth_header.replace('Bearer ', '')
    claims = decode_jwt_payload(token)
    scopes = claims.get('scope', '').split()
    tools = gateway_response['body']['result'].get('tools', [])
    filtered_tools = [t for t in tools if check_tool_authorization(
        scopes, t['name'].split('___')[1], t['name'].split('___')[0])]
    return {
        "interceptorOutputVersion": "1.0",
        "mcp": {
            "transformedGatewayResponse": {
                "statusCode": 200,
                "headers": {"Authorization": auth_header},
                "body": {"result": {"tools": filtered_tools}}
            }
        }
    }

O fluxo completo: cenário de atendimento ao cliente

O artigo usa um cenário prático para ilustrar a arquitetura em ação. Um cliente entra em contato com o suporte e pergunta: “Onde está meu pedido #12345, e ainda posso devolver os fones de ouvido que comprei semana passada?”

O fluxo passa por cada camada de governança:

  1. Descoberta de ferramentas: o agente chama o endpoint tools/list do Gateway. O interceptador de resposta filtra a lista com base nos escopos JWT do atendente, retornando quatro ferramentas autorizadas.
  2. Descoberta de tabelas: get_user_tables é invocado. O interceptador de requisição valida o JWT e confirma o escopo order:read. Retorna três tabelas: customer_orders, customer_profiles e interaction_history.
  3. Descoberta de esquema: get_schema em customer_orders revela colunas como order_id, status, ship_date e product_name. A segurança em nível de coluna do Lake Formation exclui payment_method e billing_address — invisíveis para o agente.
  4. Execução da consulta: a query SELECT order_id, status, ship_date, estimated_delivery FROM customer_orders WHERE order_id = '12345' é submetida via run_query, que injeta a identidade do cliente autenticado para resolver o filtro de linha do Lake Formation. O workgroup do Athena aplica o limite BytesScannedCutoffPerQuery. Resultado: pedido #12345 enviado em 20 de março, entrega estimada para 25 de março.
  5. Recuperação da base de conhecimento: simultaneamente, kb_search é executado com a query “return policy for electronics” e filtro de metadados {"product_category": {"$eq": "electronics"}}. A política retornada indica: eletrônicos podem ser devolvidos em até 30 dias da compra na embalagem original.
  6. Síntese da resposta: o agente combina os dois resultados em uma resposta coerente ao cliente.

Cinco camadas de governança de consultas

O artigo detalha cinco camadas sobrepostas de proteção que limitam o que o agente pode consultar, quanto dado pode escanear e quais informações chegam ao modelo:

  1. Controles de custo do workgroup do Athena: limite BytesScannedCutoffPerQuery cancela automaticamente consultas que excedam o threshold. A configuração EnforceWorkGroupConfiguration impede o agente de contornar esses limites.
  2. Prevenção de DDL via políticas IAM somente leitura: a role de execução da Lambda possui deny explícito para ações mutantes no Glue Data Catalog (glue:CreateTable, glue:DeleteTable, glue:UpdateTable).
  3. Acesso refinado do Lake Formation: políticas de segurança em cinco níveis de granularidade (banco de dados, tabela, coluna, linha e célula) aplicadas nativamente no Athena, Redshift Spectrum, AWS Glue ETL e Amazon EMR sem custo adicional. Mais detalhes em Lake Formation data filtering.
  4. Interceptadores do Gateway: interceptadores de requisição aplicam autorização baseada em escopo JWT antes da execução da ferramenta; interceptadores de resposta filtram listas de ferramentas e redigem dados sensíveis.
  5. Amazon Bedrock Guardrails via AgentCore Policy: controles de segurança de conteúdo integrados diretamente ao Policy Engine do AgentCore, avaliando entradas e saídas de cada ação do agente em tempo real — bloqueando injeção de prompt, conteúdo prejudicial e exposição de informações sensíveis antes que cheguem a sistemas downstream.

O artigo explica por que aplicar guardrails exclusivamente na fronteira de inferência do modelo é insuficiente para arquiteturas agênticas: em RAG, o modelo é o único componente que sintetiza informações, então filtrar sua saída captura todas as violações. Em IA agêntica, o agente invoca múltiplas ferramentas e constrói consultas em vários hops antes de qualquer resposta do modelo ser gerada. Um guardrail que avalia apenas a saída final do modelo não pode impedir que uma entrada maliciosa ou manipulada chegue a uma invocação de ferramenta intermediária.

Pré-requisitos para implementação

Para implementar essa arquitetura, a AWS lista os seguintes requisitos:

Deploy das ferramentas MCP e interceptadores

O processo de deploy descrito no artigo envolve clonar o repositório de exemplos de interceptadores do AgentCore Gateway e criar cada função Lambda via AWS CLI:

aws lambda create-function --function-name get_user_tables \
  --runtime python3.12 --handler lambda_function.lambda_handler \
  --role arn:aws:iam::ACCOUNT_ID:role/mcp-tool-role \
  --zip-file fileb://function.zip

Em seguida, as políticas IAM do diretório policies/ do repositório são anexadas a cada role de execução. As funções Lambda são registradas como targets de ferramentas MCP no AgentCore Gateway e os interceptadores de requisição e resposta são anexados ao gateway. O código-fonte completo das quatro ferramentas MCP, as políticas IAM e as instruções de deploy estão disponíveis nos exemplos de interceptadores do AgentCore Gateway.

Limpeza dos recursos

Para evitar cobranças contínuas após explorar a arquitetura, a AWS recomenda excluir os seguintes recursos:

Próximos passos

Para começar a construir sua própria arquitetura de agente governado, a AWS sugere as seguintes ações:

Fonte

Building agentic AI applications with a modern data mesh strategy on AWS (https://aws.amazon.com/blogs/machine-learning/building-agentic-ai-applications-with-a-modern-data-mesh-strategy-on-aws/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts