Crie fluxos de trabalho seguros de aplicativos de IA generativa com Amazon Verified Permissions e Agentes do Amazon Bedrock

Este post foi escrito por Ram Vittal, Samantha Wylatowska, Anil Nadiminti ,Michael Daniels e Maira Ladeira Tanke.

Os Agents do Amazon Bedrock permitem que aplicativos de IA generativa executem tarefas de várias etapas em vários sistemas e fontes de dados da empresa. Eles orquestram e analisam as tarefas e as dividem nas sequências lógicas corretas usando as habilidades de raciocínio (reasoning) do modelo de fundação (FM). Os agentes chamam automaticamente as APIs necessárias para interagir com os sistemas e processos da empresa e atender à solicitação. Durante todo esse processo, os agentes determinam se podem continuar ou se informações adicionais são necessárias.

Os clientes podem criar aplicativos inovadores de IA generativa usando os recursos dos agentes do Amazon Bedrock para orquestrar de forma inteligente seus fluxos de trabalho de aplicativos. Ao criar esses fluxos de trabalho, pode ser difícil para os clientes aplicarem controles de acesso refinados para garantir que o fluxo de trabalho do aplicativo opere somente nos dados autorizados com base nos direitos do usuário do aplicativo. Controlar o acesso aos recursos com base no contexto do usuário, nas funções, nas ações e nas condições dos recursos pode ser difícil de manter em um fluxo de trabalho de aplicativo, pois isso exigiria a codificação de várias regras em seu aplicativo ou a criação de seu próprio sistema de autorização para externalizar essas regras.

Em vez de criar seu próprio sistema de autorização para controles de acesso refinados nos fluxos de trabalho do seu aplicativo, você pode integrar o Amazon Verified Permissions (Permissões Verificadas) ao fluxo de trabalho do agente para aplicar controles de acesso detalhados. O Verified Permissions é um serviço escalável de gerenciamento e autorização de permissões para aplicativos personalizados criados pelos clientes. As Permissões Verificadas ajudam os desenvolvedores a criar aplicativos seguros com mais rapidez, externalizando o componente de autorização e centralizando o gerenciamento e a administração de políticas.

Nesta postagem, demonstramos como criar controles de acesso refinados usando Permissões Verificadas, um aplicativo de IA generativa que usa agentes do Amazon Bedrock para responder perguntas sobre reinvindicações de seguro que existem em um sistema de análise de sinistros usando instruções textuais como entradas e saídas. Em nosso caso de uso do sistema de sinistros de seguros, há dois tipos de usuários: administradores de sinistros e avaliadores de sinistros. Ambos são capazes de listar reinvindicações abertas, mas somente um é capaz de ler os detalhes da reinvindicação e fazer alterações. Também mostramos como restringir as permissões usando atributos personalizados, como a região do usuário, para filtrar reinvindicações de seguro. Nesta postagem, o termo região não se refere a uma região da AWS, mas sim a uma região definida pela empresa.

Visão geral da solução

Nesse design de solução, presumimos que o cliente tenha registros de reinvindicações em uma tabela do Amazon DynamoDB e gostaria de criar um aplicativo baseado em um chat para responder às perguntas frequentes sobre suas reinvindicações. Esse assistente de chat será usado internamente por administradores e avaliadores de sinistros para responder às perguntas de seus clientes.

A seguir está uma lista de ações que a equipe de sinistros precisa realizar para responder às perguntas de seus clientes::

• Mostre-me uma lista das minhas reinvindicações abertas
• Mostre-me os detalhes da reinvindicação para inserir o número da reinvindicação
• Atualize o status para fechado para o número de reinvindicação inserido

O cliente tem os seguintes requisitos de controle de acesso para seu sistema de sinistros:

• Um administrador de sinistros pode listar reinvindicações em várias áreas geográficas, mas não pode ler registros de sinistros individuais.
• Um avaliador de sinistros pode listar os pedidos de sua região e ler e atualizar os registros dos sinistros atribuídos a eles. No entanto, um avaliador de sinistros não pode acessar reinvindicações de outras regiões.
• é colocado em um grupo no Amazon Cognito, onde suas permissões em nível de aplicativo são definidas e mantidas.
• O cliente gostaria de usar as Permissões Verificadas para externalizar decisões de autorização em nível de entidade e registro sem codificar a lógica do aplicativo.

Para melhorar o desempenho do assistente de chat, o cliente usa FMs disponíveis no Amazon Bedrock. Para recuperar as informações necessárias da tabela de solicitações e orquestrar dinamicamente as solicitações, o cliente usa os agentes Amazon Bedrock junto com as Permissões Verificadas para fornecer autorização refinada para a invocação dos agentes.

A arquitetura do aplicativo para criar o exemplo de aplicativo de Reinvindicações em chat, baseado em IA generativa com controles de acesso refinados é mostrada no diagrama a seguir.

O fluxo da arquitetura do aplicativo é o seguinte:

1. O usuário acessa o aplicativo web Generative AI Claims (App de ).
2. O aplicativo autentica o usuário com o serviço Amazon Cognito e emite um token ID e um token de tokenID de acesso com a identidade e os atributos personalizados do usuário.
3. Usando o aplicativo, o usuário envia uma solicitação pedindo para “listar as reinvindicações abertas”. A solicitação é enviada junto com o token ID e o token de acesso do usuário. O aplicativo chama a API Claims API Gateway para executar o proxy de reinvindicações, passando solicitações e tokens do usuário.
4. O Claims API Gateway executa o Autorizador Personalizado para validar o token de acesso.
5. Quando a validação do token de acesso é bem-sucedida, o Claims API Gateway envia a solicitação do usuário ao Claims Proxy.
6. O Claims Proxy invoca o agente do Amazon Bedrock transmitindo a solicitação do usuário e o token ID.O agente do Amazon Bedrock está configurado para usar o modelo Claude da Anthropic e invocar ações usando o Claims Agent Helper (AWS Lambda)
7. O agente do Amazon Bedrock usa uma cadeia de pensamento e cria a lista de ações de API a serem executadas com a ajuda do Claims Agent Helper.
8. O Claims Agent Helper recupera registros de reinvindicações do Claims DB e constrói um objeto de lista de reinvindicações. Neste exemplo, estamos fornecendo exemplos codificados na função Lambda e nenhum DynamoDB foi adicionado à solução de exemplo fornecida. No entanto, fornecemos o componente na arquitetura para representar casos de uso reais em que os dados são armazenados fora do Lambda.
9. O Claims Agent Helper recupera os metadados do usuário (seu nome) do token ID, cria as entidades de dados de Permissões Verificadas e faz a solicitação de autorização de Permissões Verificadas. Essa solicitação contém o principal (usuário e função), a ação (ListClaim) e o recurso (Claim). As Permissões Verificadas avaliam a solicitação em relação às políticas de Permissões Verificadas e retornam uma decisão de Permitir ou Negar. Posteriormente, o Claims Agent Helper filtra as reinvindicações com base nessa decisão. As Permissões Verificadas têm a funcionalidade de “negação padrão”, o que significa que, na ausência de uma permissão explícita, o serviço usa como padrão uma negação implícita. Se houver uma negação explícita nas políticas envolvidas na solicitação, as Permissões Verificadas negarão a solicitação.
10. O agente do Amazon Bedrock de Reinvindicações recebe a lista autorizada de reinvindicações, aumenta a solicitação e a envia para o modelo Claude para conclusão. O agente devolve a conclusão ao usuário..

Fluxos de controle de acesso refinados

Com base nos requisitos de controle de acesso do cliente, há três fluxos de controle de acesso refinados, conforme ilustrado nos diagramas de sequência do sistema a seguir.

Caso de uso: o administrador de reinvindicações pode listar reinvindicações em todas as regiões

O diagrama a seguir mostra como o administrador de reinvindicações pode listar reinvindicações em todas as regiões.

O diagrama a seguir mostra como o acesso refinado do administrador de sinistros ao registro de sinistros é executado. Neste diagrama, observe uma decisão de negação da Verified Permissions. Isso ocorre porque a função do diretor não é ClaimsAdjuster.

Caso de uso: o avaliador de sinistros pode ver as reinvindicações de sua propriedade

O diagrama a seguir mostra como o acesso refinado do avaliador de sinistros para recuperar os detalhes da reinvindicação é executado. Neste diagrama, observe a decisão de permissão das Permissões Verificadas. Isso ocorre porque a função do principal é ClaimsAdjuster e o proprietário do recurso (proprietário da declaração) corresponde ao principal do usuário (ser=alice).

O diagrama a seguir mostra como o acesso refinado do avaliador de sinistros para listar reinvindicações abertas é executado. Neste diagrama, observe a decisão de permissão das Permissões Verificadas. Isso ocorre porque o grupo do diretor é ClaimsAdjuster e a região no recurso corresponde à região do diretor. Como resultado desse filtro de região na política de autorização, somente solicitações abertas para a região do usuário são retornadas. As Permissões Verificadas atuam no recurso principal, na ação e no recurso individual (um registro de solicitação) para a decisão de autorização. Portanto, a função Lambda precisa percorrer a lista de solicitações abertas e fazer uma solicitação isAuthorized para cada registro de solicitação. Se isso resultar em um problema de desempenho, você pode usar a API BatchIsAuthorized e enviar vários authzRequest em uma chamada de API.

Considerações sobre o design de entidades

Ao projetar controles de acesso a dados detalhados, é uma prática recomendada começar com o diagrama de entidade e relacionamento (DER) do aplicativo. Em nosso aplicativo de sinistros, o usuário operará nos registros de sinistros para recuperar uma lista de registros de sinistros, obter os detalhes de um registro de sinistro individual ou atualizar o status de um registro de sinistro. O diagrama a seguir é o DER desse aplicativo modelado em Permissões Verificadas. Com as Permissões Verificadas, você pode aplicar tanto o controle de acesso baseado em função (RBAC) quanto o controle de acesso baseado em atributos (ABAC).

Aqui está uma breve descrição de cada entidade e atributos que serão usados para RBAC e ABAC em relação aos registros de reinvindicações.

• Aplicativo – O aplicativo é um aplicativo de IA generativa baseado em chat que usa o agente do Amazon Bedrock para entender as perguntas e recuperar os dados de sinistros relevantes para auxiliar os administradores e avaliadores de sinistros.
• Reinvindicação (Claims) – A reinvindicação representa um registro de reinvindicação de seguro armazenado na tabela do DynamoDB. O sistema de sinistros armazena registros de sinistros e o aplicativo chatbot permite que os usuários recuperem e atualizem esses registros.
• Usuário – O usuário.
• Função – A função representa o acesso de um usuário dentro do aplicativo. Aqui está uma lista das funções disponíveis:
  • o Administradores de sinistros – podem listar reinvindicações em várias regiões geográficas, mas não conseguem ler registros de sinistros individuais.
  • o Avaliadores de sinistros – podem listar os pedidos de sua região e ler e atualizar seus registros de sinistros

As funções são gerenciadas por meio do Amazon Cognito e das Permissões Verificadas. O Amazon Cognito mantém um registro da função à qual um usuário está atribuído e inclui essas informações no token. As Permissões Verificadas mantêm um registro do que essa função tem permissão para fazer. Existem controles de acesso refinados para garantir que os usuários tenham as permissões apropriadas para suas funções, restringindo o acesso a dados confidenciais de solicitações com base em regiões geográficas e grupos de usuários.

Autorização refinada: design de políticas

A exibição do diagrama de ações lista os tipos de diretores que você configurou em seu repositório de políticas, as ações que eles estão qualificados para executar e os recursos nos quais eles estão qualificados para realizar ações. As linhas entre entidades indicam sua capacidade de criar uma política que permita ao diretor realizar uma ação em um recurso. A imagem a seguir mostra o diagrama de ações das Permissões Verificadas para nosso caso de uso de sinistros de seguros. O usuário principal terá acesso às ações Get (Obter), List (Listar) e Update (Atualizar). Os recursos são o Aplicativo e a entidade de Reinvindicação dentro do aplicativo. Esse diagrama gera o esquema subjacente que controla a definição da política.

Caso de uso: o administrador de reinvindicações pode listar todos os registros de reinvindicações em todas as regiões

Uma política é uma declaração que permite ou proíbe o diretor de realizar uma ou mais ações em um recurso. Cada política é avaliada independentemente das outras políticas. A política de Permissões Verificadas para esse caso de uso é mostrada no exemplo de código a seguir. Nessa política, o principal (o usuário Bob) recebe a função de administrador de sinistros.

permit (
    principal in avp::claim::app::Role::"ClaimsAdministrator",
    action in [
    avp::claim::app::Action::"ListClaim"
    ],
    resource
) ;

Caso de uso: o administrador de solicitações não consegue acessar o registro de detalhes da reinvindicação

A política de Permissões Verificadas para esse caso de uso é mostrada no exemplo de código a seguir. O uso de políticas explícitas de “proibição” é uma prática válida.

forbid (
    principal in avp::claim::app::Role::"ClaimsAdministrator",
    action in [
    avp::claim::app::Action::"GetClaim"
    ],
    resource
) ;

Caso de uso: o avaliador de sinistros pode listar reinvindicações de sua propriedade em sua região

A política de Permissões Verificadas para esse caso de uso é mostrada no exemplo de código a seguir. Nessa política, a principal (a usuária Alice) recebe a função de avaliadora de sinistros e sua região é passada como um atributo personalizado no token ID.

permit (
    principal in avp::claim::app::Role::"ClaimsAdjuster",
    action in [
    avp::claim::app::Action::"ListClaim"
    ],
    resource
) when {
    resource has owner &&
    principal == resource.owner &&
    principal has custom &&
    principal.custom has region &&
    principal.custom.region == resource.region
};

Caso de uso: o avaliador de sinistros pode recuperar ou atualizar uma reinvindicação de sua propriedade

permit (
    principal in avp::claim::app::Role::"ClaimsAdjuster",
    action in [
    avp::claim::app::Action::"GetClaim",
     avp::claim::app::Action::"UpdateClaim"
    ],
    resource
) when {
    principal == resource.owner&&
    principal has custom &&
    principal.custom has region &&
    principal.custom.region == resource.region
};

Considerações sobre o design de autenticação

A configuração do Amazon Cognito para esse caso de uso seguiu as práticas de segurança incluídas como parte do fluxo de trabalho de configuração padrão: uma política de senha forte, autenticação multifatorial (MFA) e um segredo do cliente. Ao usar o Amazon Cognito com Permissões Verificadas, seu aplicativo pode passar o acesso ao grupo de usuários ou tokens de identidade às Permissões Verificadas para tomar a decisão de permitir ou negar. As Permissões Verificadas avaliam a solicitação do usuário com base nas políticas armazenadas no repositório de políticas.

Para atributos personalizados, estamos usando a região para restringir quais reinvindicações um avaliador de sinistros pode ver, excluindo reinvindicações feitas em regiões fora da própria região do avaliador. Também estamos usando a função como um atributo personalizado para fornecer essas informações no token ID que é passado para o agente do Amazon Bedrock. Quando o usuário é registrado no grupo de usuários do Cognito, esses atributos personalizados serão registrados como parte do processo de inscrição.

O Amazon Cognito se integra às Permissões Verificadas por meio da seção Fontes de identidade no console. A captura de tela a seguir mostra que conectamos nosso grupo de usuários do Cognito ao armazenamento de políticas de Permissões Verificadas da Amazon.

Autorização refinada: passando o token ID para o agente do Amazon Bedrock

Quando o usuário é autenticado no grupo de usuários do Cognito, ele retorna um token ID e um token de acesso ao aplicativo cliente. O token ID será passado por um gateway de API e um proxy Lambda por meio de SessionAttributes na chamada invoke_agent.

# Invoke the agent API
response = bedrock_agent_runtime_client.invoke_agent(
    …    
    sessionState={
        'sessionAttributes': {
            'authorization_header': '<AUTHORIZATION_HEADER>'
        }
    },
)

O cabeçalho é então recuperado do evento Lambda na função Lambda do Action Group e as Permissões Verificadas são usadas para verificar o acesso do usuário em relação à ação desejada.

# Retrieve session attributes from event and use it to validate action
sessAttr = event.get("sessionAttributes")
auth, reason = verifyAccess(sessionAttributes, action_id)

Autorização refinada: integração com Agentes do Amazon Bedrock

O token ID emitido pelo Amazon Cognito contém a identidade e os atributos personalizados do usuário. Esse token ID é passado para o agente do Amazon Bedrock, e o Agent Helper Lambda recupera esse token do atributo de sessão do agente. Em seguida, o Agent Helper Lambda recupera registros de solicitações abertas do DynamoDB, constrói as entidades do esquema de Permissões Verificadas e faz a chamada da API IsAuthorized.

Como os recursos de Permissões Verificadas operam no nível de registro individual (um único registro de solicitação), você precisa iterar sobre o objeto da lista de solicitações e fazer com que a API isAuthorized chame a decisão de autorização e, em seguida, criar a lista de solicitações filtradas. A lista de solicitações filtradas é então enviada de volta para o chamador. Como resultado, o avaliador de sinistros só verá reinvindicações de sua região, enquanto um administrador de sinistros poderá ver reinvindicações em todas as regiões.

O agente do Amazon Bedrock então usa essa lista de reinvindicações filtrada para concluir a solicitação do usuário para listar reinvindicações. O aplicativo de chat só pode acessar os registros de reinvindicações que o usuário está autorizado a visualizar, fornecendo o controle de acesso refinado integrado ao fluxo de trabalho do agente do Amazon Bedrock.

Começando

Confira nosso código fonte para começar a desenvolver seu aplicativo seguro de IA generativa usando as Permissões Verificadas da Amazon. Fornecemos uma implementação de ponta a ponta da arquitetura descrita nesta postagem e uma interface de usuário de demonstração que você pode usar para testar as permissões de diferentes usuários. Atualize este exemplo para implementar aplicativos de IA generativa que se conectem ao seu caso de uso.

Conclusão

Neste post, discutimos os desafios da aplicação de controles de acesso refinados para fluxos de trabalho de agentes em um aplicativo de IA generativa. Compartilhamos uma arquitetura de aplicativo para criar um exemplo de aplicativo generativo de IA baseado em chat que usa Agentes do Amazon Bedrock para orquestrar fluxos de trabalho e aplicar controles de acesso refinados usando Amazon Verified Permissions. Discutimos como criar permissões de acesso refinadas por meio do design de fluxos de trabalho de controle de acesso baseados em personas. Se você está procurando uma maneira escalável e segura de aplicar permissões refinadas aos seus fluxos de trabalho generativos baseados em agentes de IA, experimente essa solução e deixe seu feedback.

Sobre os autores

	Ram Vittal é Principal Arquiteto de Soluções de ML na AWS. Ele tem mais de 3 décadas de experiência na arquitetura e criação de aplicativos distribuídos, híbridos e em nuvem. Ele é apaixonado por criar soluções de AI/ML e big data seguras, escaláveis e confiáveis para ajudar clientes corporativos em sua jornada de adoção e otimização da nuvem para melhorar seus resultados comerciais. Em seu tempo livre, ele anda de moto e caminha com seu filho de três anos de idade, sheep-a-doodle!
	Samantha Wylatowska é arquiteta de soluções na AWS. Com experiência em DevSecOps, sua paixão está em orientar as organizações em direção à eficiência operacional segura, aproveitando o poder da automação para uma experiência perfeita na nuvem. Em seu tempo livre, ela geralmente está aprendendo algo novo por meio da música, literatura ou cinema.
	Anil Nadiminti é arquiteto sênior de soluções na AWS, especializado em capacitar organizações a aproveitar a computação em nuvem e a IA para transformação digital e inovação. Sua experiência na arquitetura de soluções escaláveis e na implementação de estratégias orientadas por dados permite que as empresas inovem e prosperem no cenário tecnológico atual em rápida evolução.
	Michael Daniels é especialista em IA/ML na AWS. Sua experiência está na criação e liderança de soluções de IA/ML e IA generativa para problemas comerciais complexos e desafiadores, o que é aprimorado por seu PhD pela Universidade do Texas e seu mestrado em especialização em ciência da computação em aprendizado de máquina pelo Instituto de Tecnologia da Geórgia. Ele se destaca na aplicação de tecnologias de nuvem de ponta para inovar, inspirar e transformar organizações líderes do setor, ao mesmo tempo em que se comunica de forma eficaz com as partes interessadas em qualquer nível ou escala. Em seu tempo livre, você pode ver Michael esquiando ou praticando snowboard.

Maira Ladeira Tanke é cientista sênior de dados de IA generativa na AWS. Com experiência em aprendizado de máquina, ela tem mais de 10 anos de experiência na arquitetura e criação de aplicativos de IA com clientes de vários setores. Como líder técnica, ela ajuda os clientes a acelerar a obtenção de valor comercial por meio de soluções generativas de IA no Amazon Bedrock. Em seu tempo livre, Maira gosta de viajar, brincar com seu gato e passar tempo com sua família em algum lugar quente.

Sobre os tradutores

Guilherme Ricci é Arquiteto de Soluções Sênior para startups na Amazon Web Services, ajudando startups a modernizar e otimizar os custos de suas aplicações. Com mais de 10 anos de experiência em empresas do setor financeiro, atualmente trabalha com uma equipe de especialistas em AI/ML.