Quando um agente de inteligência artificial usa a credencial de um usuário humano para acessar bancos de dados, o sistema não obtém uma «identidade de agente» oculta por trás da conta; ele vê o próprio usuário. Essa é a conclusão central de uma medição realizada por Naseeb Ahmed Mian em um ambiente de produção que utiliza Azure, Azure CLI e sqlcmd.
Na configuração examinada, as habilidades do agente de software conectavam-se aos bancos de dados por meio do comando sqlcmd, usando autenticação pelo Azure CLI. O comando extrai o token de acesso armazenado em cache após o login do usuário e o apresenta ao banco de dados. Como resultado, as conexões apareciam em nome do usuário, com o nome de seu dispositivo e a ferramenta sqlcmd, tivesse ele escrito a consulta pessoalmente ou o agente a tivesse executado.
O registro de auditoria vê a credencial, mas não vê a intenção
O registro da sessão mostrava o nome de login do usuário, o nome da estação de trabalho e a interface do cliente, mas não incluía um campo que distinguisse as ações executadas pelo agente. Assim, as consultas humanas e automatizadas tornam-se idênticas no registro, e os controles posteriores não conseguem aplicar uma taxa de requisições, uma etapa de aprovação ou uma política de retenção diferente com base na origem da execução.
O problema não se limita às investigações de segurança. Se uma consulta executada meses antes for questionada posteriormente, o registro não provará se o usuário a escreveu ou se uma ferramenta automatizada a executou. Ele é preciso ao atribuir a ação à credencial, mas permanece silencioso quanto à intenção e ao autor efetivo.
O que o token de acesso revela?
O token entregue pelo Azure CLI continha o escopo user_impersonation, além de uma declaração indicando que a autenticação incluíra um fator de autenticação multifator. Na prática, cada ação executada pelo agente vem acompanhada de uma prova de que o usuário passou pela autenticação multifator, mesmo que isso tenha ocorrido horas antes e no contexto de uma tarefa diferente.
Além disso, a duração do token, de 84 minutos, não representa necessariamente o fim da execução do agente. A CLI renova o token automaticamente usando um token de atualização e, por isso, a execução não supervisionada pode continuar até que o token de atualização expire ou a conta do usuário seja desativada.
A associação a grupos amplia o quadro
Uma análise das atribuições de funções mostrou apenas uma linha: a função Reader em uma assinatura não produtiva. Porém, o token de acesso continha 37 grupos, enquanto uma consulta de associação direta mostrava 34 grupos, com a existência de grupos aninhados. Entre os grupos relacionados ao acesso estavam funções como visualizador de bancos de dados SQL, usuário com privilégios elevados, colaborador de recursos e administrador de banco de dados.
O risco está no fato de que essas associações podem carregar as permissões efetivas na camada de dados e não aparecer necessariamente nas verificações de funções da camada de controle. Portanto, o escopo de acesso do agente pode parecer limitado em uma revisão pelo método tradicional, enquanto a associação aos grupos lhe concede uma capacidade maior.
O que muda na prática?
Ao testar a mesma identidade em dois armazenamentos de produção com uma diferença de uma hora, surgiram dois resultados extremamente distintos. Em um deles, a identidade possuía apenas as permissões CONNECT e SELECT e não conseguia se conectar à camada segura. Já outro ponto de análise de produção mostrou 430 tabelas e 107 permissões, incluindo leitura, gravação, definição de esquema e administração de banco de dados.
A comparação mostra que o escopo das permissões não é determinado apenas pela identidade; o caminho de acesso, o mecanismo e os controles associados ao endpoint também são fatores decisivos. Um endpoint pode ser somente para leitura de acordo com sua documentação, enquanto suas regras de segurança não são necessariamente transferidas quando os dados são acessados por outro mecanismo.
A leitura editorial da certi.news: o problema não é que o agente esteja «sem identidade», mas que a identidade humana tenha sido usada como substituta rápida de uma identidade automatizada independente. Isso falha em três pontos: atribuição, ampliação de privilégios e revogação. A medição também mostrou que o ambiente em que a credencial tinha capacidade de exclusão em um banco de dados seguro era o único sem um registro de auditoria ativado. Permanecem em aberto questões importantes sobre a consistência da associação a grupos, a persistência de permissões temporárias dentro dos tokens emitidos e a capacidade das instituições de registrar a intenção da execução, e não apenas o titular da credencial.