Segurança em Agentes de IA: Aplicando o Princípio do Menor Privilégio com o novo template da Curity e Azure

Agentes de IA: o risco real da autonomia

Ao desenvolver demos de agentes de IA, a primeira euforia reside na capacidade da LLM em interpretar linguagem natural e orquestrar ferramentas. No entanto, o cenário muda drasticamente ao desenhar para ambientes corporativos: como impedir que um agente, por meio de uma prompt injection ou erro lógico, exiba dados de um cliente para outro? A segurança de agentes de IA exige uma mudança de paradigma, indo além da autenticação simples para a autorização delegada granular.

Este novo azd template une a expertise da Curity em padrões de identidade com a robustez do ecossistema de agentes do Azure. O foco aqui não é apenas "fazer funcionar", mas estabelecer um padrão de segurança para o design de tokens em arquiteturas de agentes.

O que o template disponibiliza para o time de engenharia?

O template automatiza o deploy de um ambiente completo no Azure, estruturado em:

• Backend Agent: Desenvolvido em C# usando Microsoft A2A e MCP SDKs.
• MCP Server: Expondo a API de portfólio para testes.
• IdP Layer: Integração do Curity Identity Server com o Microsoft Entra ID.
• Gateway Layer: Gateways interno e externo para token exchange e logging de auditoria.
• Infraestrutura: Bicep pronto para Container Apps, Azure AI Foundry e Key Vault.

Por que a autorização deve ser o foco do design?

A maioria dos exemplos de mercado confunde identidade (quem é você) com autorização (o que você pode acessar). Como agentes são criativos e não determinísticos, eles se tornam vetores de risco se tiverem privilégios amplos. O padrão proposto utiliza tokens de curta duração com Claims específicas, removendo a necessidade de lógica de autorização complexa dentro da aplicação.

O padrão: Tokens com delegação e scoping

O template implementa um fluxo de token exchange. O primeiro token é convertido para um JWT com escopos estritos, como no exemplo abaixo:

Copiar{
  "scope": "stocks/read",
  "customer_id": "178",
  "region": "USA",
  "client_type": "ai-agent",
  "agent_id": "autonomous-agent"
}

Dessa forma, o serviço de backend (MCP Server) apenas lê o customer_id do token e filtra a query no banco de dados SQL. Isso mantém o código limpo e desacoplado da lógica de autorização.

Estrutura de deployment e o papel da plataforma

O projeto utiliza uma abordagem em camadas: Base (Rede/Compartilhados), Identity (Curity/Gateways) e Application (Agentes). O uso de gateways internos é um ponto de atenção crítico: eles centralizam o log de auditoria e forçam regras de corte, impedindo, por exemplo, que agentes mal-intencionados utilizem tokens com privilégios de escrita.

Ao planejar a expansão desse padrão para a sua realidade (ex: aprovação humana em processos transacionais ou agentes federados entre parceiros), o segredo estará no design dos tokens, e não na complexidade do prompt.

Primeiros passos para o time de SRE e Devs

Para avaliar a implementação, recomendamos iniciar localmente via Docker (conforme orientações no repositório curityio/azd-ai-autonomous-agent). Observe o fluxo de logs no gateway interno (az containerapp logs...) para entender como os tokens são injetados e validados em cada hop da requisição.

Perguntas Frequentes

• O que torna a automação de agentes de IA diferente das integrações de API tradicionais?
  Diferente de aplicações tradicionais com chamadas determinísticas, agentes de IA operam de forma não determinística, podendo decidir autonomamente quais ferramentas utilizar. Isso exige que a autorização seja granular e baseada em tokens, para evitar que o agente execute ações além do que o usuário final tem permissão.

• Como este template resolve o risco de 'excesso de privilégio'?
  O template utiliza múltiplos níveis de token exchange, onde tokens de curta duração carregam claims específicas como customer_id e scope. Isso permite que a API filtre dados na query, garantindo que o agente só consiga acessar informações autorizadas daquele usuário específico.

• Essa solução requer a substituição do Microsoft Entra ID?
  Não. O template mantém o Entra ID para a autenticação do usuário, adicionando o Curity Identity Server como um emissor de tokens especializado para os fluxos de delegação, garantindo que os agentes operem apenas com privilégios limitados.

---

Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.