Identidade e credenciais de agentes de IA: como limitar acessos

Um agente de IA pode ajudar a organizar informações e preparar tarefas, mas sua capacidade de agir depende das permissões concedidas aos sistemas conectados. Identificar quem executa uma ação e limitar o que essa identidade pode fazer são decisões diferentes. As duas precisam ser tratadas antes de automatizar um fluxo documental.[1][2]

Identidade não é a mesma coisa que credencial

A identidade responde a uma pergunta: quem ou o que está solicitando acesso? A credencial é o meio usado para demonstrar essa identidade, como um token de acesso ou uma credencial de serviço. Uma credencial válida permite verificar uma identidade ou autorização conforme o mecanismo adotado; ela não deve ser interpretada como permissão irrestrita para qualquer ação.[1]

Em uma integração, também convém distinguir a pessoa que pediu a tarefa, o agente ou aplicação que a executa e o serviço que recebe a solicitação. Registrar esses vínculos ajuda a investigar o que ocorreu e a quem solicitar revisão, respeitando a política de privacidade e evitando guardar segredos em logs.[1][3]

Autenticar, autorizar e aprovar são etapas distintas

A autenticação verifica a identidade apresentada. A autorização decide se aquela identidade pode realizar uma operação específica sobre determinado recurso. Já a aprovação humana é um controle adicional para uma decisão que a organização considere sensível, como disparar um documento a destinatários externos.[1][4]

Por exemplo, uma equipe pode permitir que um agente consulte o estado de documentos de um ambiente de teste, mas reservar a decisão de enviar um documento para uma pessoa autorizada. A consulta não implica permissão para envio, e a aprovação de um envio não deve ser tratada como autorização permanente para quaisquer envios futuros. Este é um exemplo de desenho de processo, não uma descrição de recursos de um produto.

Como reduzir o alcance das credenciais

1. Defina a finalidade. Registre qual tarefa será executada, quais recursos ela precisa acessar e quem responde pelo fluxo.
2. Separe ambientes e identidades. Evite compartilhar uma credencial pessoal entre pessoas e automações; use identidades próprias sempre que o sistema permitir.
3. Conceda o mínimo necessário. Quando houver controles disponíveis, limite operações, recursos e duração ao necessário para a tarefa. Revise privilégios periodicamente.[4]
4. Proteja e revogue. Use armazenamento apropriado de segredos, restrinja o acesso e defina como substituir ou revogar credenciais comprometidas. Não cole tokens em documentos, mensagens ou registros de execução.[3]
5. Verifique cada ação sensível. A política deve ser aplicada pelo sistema que controla a ação, não apenas por uma instrução escrita ao modelo. Preveja uma aprovação humana contextual quando o impacto justificar.[4]
6. Registre sem expor conteúdo. Guarde os dados necessários para rastrear a operação, como identificação da aplicação, tipo de ação, resultado e momento, conforme a política aplicável. Evite tokens e documentos completos nos logs.[3]

E quando a integração usa MCP?

O Model Context Protocol (MCP) define formas de conectar aplicações a ferramentas e recursos. As decisões de identidade, autorização e delegação continuam importantes: uma conexão estabelecida não transforma toda chamada em ação permitida. Na documentação do SDK MCP, por exemplo, o servidor deve validar tokens para o recurso correto e não repassar automaticamente o token recebido a outras APIs.[2]

Os mecanismos suportados dependem da versão, da implementação e dos sistemas envolvidos. Antes de planejar uma integração, confira a documentação e teste os controles no ambiente apropriado. Este texto não afirma que uma plataforma específica ofereça MCP, escopos ou qualquer mecanismo de identidade.

Perguntas frequentes

Um agente precisa usar a conta de uma pessoa?

Não necessariamente. O desenho depende dos sistemas envolvidos. Uma identidade própria para a automação, quando disponível, facilita separar o acesso do agente do acesso pessoal e revisar o alcance concedido.

Ter acesso de leitura autoriza o envio de documentos?

Não. Leitura e envio são operações distintas e devem ser avaliadas separadamente na política de acesso.

A aprovação humana elimina o risco?

Não. Ela é uma camada adicional, e precisa apresentar contexto suficiente para a decisão. Controles técnicos de acesso e proteção das credenciais continuam necessários.[4]

Fontes

[1] OWASP, Authentication Patterns: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Patterns_Cheat_Sheet.html
[2] Model Context Protocol, SDK PHP, Authorization e segurança: https://php.sdk.modelcontextprotocol.io/run/authorization/
[3] OWASP, Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
[4] OWASP, LLM01:2025 Prompt Injection, controles de privilégio e aprovação: https://genai.owasp.org/llmrisk/llm01-prompt-injection/