Governança de Agentes de IA: Controle o que os Agentes Podem Acessar e Fazer

O que é governança de agentes de IA?

Governança de agentes de IA é o conjunto de políticas, controles, aprovações e mecanismos de evidência usados para determinar o que agentes de IA podem acessar, quais ferramentas podem invocar e quais ações podem executar.

Para uma explicação concisa sobre autoridade delegada, leia o verbete de governança de agentes de IA.

Para uma definição concisa do sistema que está sendo governado, leia o verbete sobre agente de IA.

A pergunta operacional é específica: este agente tem autoridade para executar esta ação, com estes dados de entrada, neste destino e neste contexto? A resposta exige mais do que conhecer o nome do modelo ou da aplicação. A organização precisa de um responsável pela decisão, um ponto de controle efetivo e evidência do resultado.

A governança de agentes faz parte do programa mais amplo de governança de IA. Seu foco são as ações delegadas, enquanto o programa também trata da adequação dos modelos, das responsabilidades organizacionais e dos usos permitidos da IA.

Por que agentes mudam a fronteira de segurança

Um agente pode transformar a saída de um modelo em uma solicitação a outro sistema. A fronteira de segurança passa, portanto, pelas identidades, credenciais, ferramentas e permissões de acesso a dados usadas para atender à solicitação. Uma resposta confiável do modelo não estabelece autoridade para agir.

A OWASP descreve Excessive Agency em termos de excesso de funções, permissões ou autonomia. Sua orientação recomenda aplicar a autorização nos sistemas de destino, em vez de depender do modelo para decidir o que é permitido.

Para a organização, isso significa revisar a autoridade delegada ao processo. Um prompt que diz “não altere produção” deve ser acompanhado de controles sobre as credenciais, os destinos e as operações disponíveis ao agente.

O pilar de segurança de agentes de IA examina como entradas não confiáveis podem influenciar o uso de ferramentas e credenciais disponíveis, e quais efeitos um modelo de ameaça deve restringir.

Dos prompts às ações

Exemplo hipotético: uma pessoa da equipe de engenharia pede a um agente de código que atualize uma dependência e prepare um patch. O agente pode precisar ler arquivos, editar um manifesto de dependências e executar um comando de teste. Publicar um pacote ou alterar um serviço de produção seria outra delegação de autoridade.

O pedido original estabelece o objetivo. Ele não autoriza automaticamente cada passo que o agente possa escolher para alcançá-lo. A governança deve identificar o diretório de trabalho aprovado, as operações permitidas, os destinos aceitáveis para dados e as condições que exigem revisão.

Suponha que um teste falhe e o agente proponha enviar o repositório a um serviço externo de diagnóstico. O objetivo de negócio continua igual, mas a transferência de dados proposta é nova. Um controle útil avalia essa ação, sem tratar a aprovação inicial da tarefa como permissão para toda a sequência.

O termo IA agêntica descreve como escolhas e ações são delegadas nesse tipo de fluxo.

A cadeia de execução de um agente de IA

Uma cadeia de execução conecta um usuário ou gatilho a uma mudança em um sistema. Os passos abaixo descrevem uma arquitetura conceitual, não uma implementação fixa ou um diagrama do produto KonaSense. Um agente pode repetir o ciclo, fazer solicitações em paralelo ou usar modelos diferentes.

1. Usuário ou gatilho: uma pessoa, um processo agendado ou um evento inicia o trabalho com responsável e finalidade definidos.
2. Agente e modelo: o agente reúne contexto e usa um modelo para propor o próximo passo. O contexto pode incluir instruções, material recuperado e resultados anteriores de ferramentas.
3. Seleção da ferramenta: a proposta se torna uma solicitação de ferramenta com operação, argumentos e destino. É o momento em que “atualizar uma dependência” se transforma em uma edição de arquivo ou comando concreto.
4. Avaliação de política: um controle avalia a solicitação proposta com o contexto que consegue verificar. A decisão pode permitir a solicitação, negá-la ou exigir aprovação.
5. Ação e evidência: uma solicitação permitida pode seguir para o sistema de destino, sujeita à autorização desse sistema. Uma solicitação negada para no controle. Uma solicitação que aguarda aprovação permanece pendente. Registre a decisão e, se houver execução, o resultado observado.

Permitir uma solicitação não prova que ela foi bem-sucedida. O destino pode rejeitá-la, a ferramenta pode falhar ou o resultado pode permanecer desconhecido. Uma negação também merece registro de evidência, mesmo sem execução da ação.

Onde entra o MCP

A arquitetura do Model Context Protocol descreve clientes e servidores que trocam contexto e expõem capacidades como ferramentas. MCP é uma das formas de uma aplicação com agentes acessar uma ferramenta. Esses processos também podem usar funções incorporadas ou APIs diretamente.

O MCP tem uma especificação de autorização para transportes HTTP. Essa capacidade do protocolo não determina quais ações de negócio uma organização deve permitir. A especificação de ferramentas também exige controles de acesso no servidor. Avalie o servidor, as ferramentas, as permissões e a implementação concreta, sem tratar uma conexão MCP como evidência de que o processo está governado.

O que as organizações precisam governar

A unidade útil de revisão é uma ação proposta dentro de uma tarefa delegada. As perguntas a seguir transformam uma política ampla em algo que um arquiteto de segurança e o responsável pelo processo conseguem avaliar juntos.

Identidade e autoridade delegada

Identifique a pessoa ou o serviço que iniciou o trabalho, o runtime do agente e a identidade usada no destino. Essas identidades podem ser diferentes. Registre quem responde pelo processo e quais permissões a ferramenta realmente utiliza. Uma conta de serviço com acesso amplo não deve aumentar silenciosamente a autoridade de uma tarefa aprovada com escopo restrito.

Contexto e dados

Determine de qual diretório de trabalho, conta, ambiente e fontes de dados a decisão depende. Diferencie instruções de material fornecido como contexto. Um arquivo do repositório ou resultado de ferramenta pode conter texto que pareça uma nova instrução; estar no contexto não transforma esse texto em uma solicitação autorizada.

No exemplo hipotético da atualização de dependência, o repositório permitido e o destino importam tanto quanto a operação de edição. Decida separadamente qual conteúdo o sistema de governança precisa inspecionar ou reter. Evite copiar credenciais ou arquivos de código inteiros para a evidência apenas porque estão disponíveis.

Acesso a ferramentas e ações

Revise a operação junto de seus parâmetros. Ter permissão para usar um shell é muito mais amplo do que poder executar um teste específico em um diretório de trabalho específico. A definição atual desse teste também importa: o nome do comando não basta se o script acionado por ele pode mudar.

Identifique onde a restrição é aplicada. A interface do agente, um componente que controla a chamada da ferramenta, o ambiente de execução e o serviço de destino podem conter partes do controle. Documente os caminhos que não passam por essas verificações para não confundir uma decisão em uma integração com controle sobre o ambiente inteiro.

Aprovações e evidência

Especifique quais solicitações podem seguir conforme uma política predefinida e quais precisam de uma decisão humana. Vincule a aprovação à ação e ao contexto revisados. Preserve esse escopo junto da decisão de política e do resultado observado. Os registros devem mostrar o que foi autorizado sem sugerir que a autorização, sozinha, comprova a execução.

Governança no design e governança em runtime

A governança no design estabelece as capacidades permitidas ao processo antes do uso. A governança em runtime aplica decisões enquanto ele opera. As duas são necessárias: uma verificação em runtime depende da autoridade e do contexto definidos para ela.

No exemplo hipotético, limitar as credenciais do agente a um repositório de desenvolvimento reduz sua autoridade inicial. Avaliar um upload proposto acrescenta uma decisão sobre o destino específico. Um controle não torna o outro redundante.

Para distinguir configuração de políticas, decisões e aplicação, veja o verbete sobre plano de controle de IA.

Observar e controlar

A observação fornece evidências sobre a atividade. O controle participa da decisão de permitir ou não uma ação. Um sistema pode oferecer uma dessas funções, as duas ou nenhuma para um determinado tipo de evento. Verifique o momento e o efeito da integração, sem depender de um rótulo genérico como “visibilidade de agentes”.

Pré-execução e pós-execução

A governança pré-execução avalia uma ação proposta em um ponto capaz de negar permissão. A observação pós-execução recebe evidências depois de uma ação ou tentativa. Ela pode apoiar a investigação e uma resposta posterior, mas não pode impedir o evento já concluído.

Na atualização de dependência, uma decisão pré-execução pode governar a gravação de arquivo proposta. Um resultado posterior da ferramenta pode estabelecer se a gravação funcionou. Uma reversão posterior é outra ação, com autorização e riscos próprios; registrar um evento não torna a ação original reversível.

Defina explicitamente o que acontece se a avaliação exceder o tempo limite, faltar contexto ou o serviço de aprovação estiver indisponível. Um controle que permite continuar em caso de falha tem limites operacionais diferentes de outro que interrompe a solicitação. Teste e documente o comportamento que o processo realmente utiliza.

Para avaliar as evidências, examine por que observar um agente não é o mesmo que governá-lo.

Intervenção humana

A revisão humana é útil quando a pessoa consegue entender a ação e tem autoridade para decidir. Mostre a operação, o destino, os parâmetros relevantes, o motivo do encaminhamento e o efeito esperado. “Permitir que o agente continue?” oferece pouca base para uma decisão se esses detalhes ficarem ocultos.

Defina se a aprovação cobre uma ação ou uma classe delimitada de ações. Uma mudança relevante no destino, nos dados de entrada, na identidade ou no escopo deve levar à reavaliação conforme a política da organização. A aprovação não deve acompanhar uma solicitação alterada apenas porque a mesma sessão do agente continua em andamento.

No upload hipotético, a pessoa responsável pela revisão precisa saber o que sairia do repositório e para onde iria. Se isso não puder ser estabelecido, registre a informação ausente e mantenha a solicitação sem resolução conforme a política escolhida. Não transforme silenciosamente a falta de evidência em consentimento.

A análise sobre human-in-the-loop e governança examina o que os revisores podem decidir e por que aceitar risco é diferente de verificar um fato.

Trilhas de auditoria para ações de agentes

Uma trilha de auditoria deve permitir relacionar a delegação, a solicitação, a decisão e o resultado observado. A definição de ação de agente distingue a operação em análise de sua proposta, tentativa e resultado observado. O princípio de prestação de contas da OCDE prevê rastreabilidade de dados, processos e decisões conforme o contexto. Um registro prático de ação de agente pode incluir:

• A identidade que iniciou o trabalho, o responsável pelo processo, a sessão e o identificador da solicitação.
• A ferramenta, o destino, os parâmetros de entrada relevantes e o contexto disponível para a decisão.
• A versão da política, a decisão, o motivo e qualquer aprovação com seu escopo.
• A tentativa de execução, o resultado informado, os horários e as lacunas conhecidas.

Este é um exemplo editorial de estrutura de evidência, não um schema universal obrigatório. Retenção, acesso e minimização de dados devem atender à necessidade de investigação. Proteja os registros contra alterações não autorizadas, mas não declare imutabilidade ou não repúdio apenas porque existe um log.

Mantenha distintos os estados “solicitado”, “permitido”, “tentado” e “concluído”. Se o resultado estiver ausente, ele permanece desconhecido. A correlação ajuda a reconstruir a sequência; ela não cria um evento que nunca foi observado.

O guia de arquitetura de governança de agentes de IA acompanha esses registros entre o runtime, o serviço de ferramenta e o destino, inclusive quando uma resposta se perde.

Como a KonaSense governa agentes de IA

O Kona for Agents conecta processos de agentes de código compatíveis à avaliação de políticas por meio de integrações em runtime. O controle disponível depende do agente, do tipo de evento, da instalação e da configuração.

No caminho PreToolUse da implementação do adaptador Claude Code revisada para este guia, uma negação de política corresponde a uma resposta do hook que nega a chamada da ferramenta, e um encaminhamento para aprovação corresponde a um pedido de aprovação ao usuário. Essa implementação retorna Allow quando a avaliação de política falha. Esse comportamento deve ser considerado ao decidir quais ações precisam de um controle independente no destino.

Avalie o runtime instalado, a versão, o registro dos hooks, as permissões e o comportamento de falha para a implantação pretendida. A capacidade de uma integração receber eventos não deve ser tratada como prova de que ela pode interromper qualquer ação. Para aprofundar a terminologia, Agente de IA é uma leitura complementar.

Perguntas frequentes

Governança de agentes de IA é o mesmo que observabilidade de agentes?

A observabilidade fornece informações sobre a atividade dos agentes. A governança também determina autoridade, responsabilidades, aprovações e controles. Evidências de observação podem apoiar uma decisão de governança sem conseguir aplicá-la como controle antes da ação.

Toda chamada de ferramenta precisa de aprovação humana?

Defina os requisitos de aprovação pelo escopo e pelas consequências da ação. Políticas predefinidas podem cobrir operações delimitadas, enquanto solicitações fora desse escopo exigem uma decisão de um responsável designado. O modelo de aprovação deve ser explícito o suficiente para ser testado e não deve depender da descrição que o agente faz da própria segurança.

Como uma equipe pode verificar se um agente está governado?

Escolha um processo representativo e examine uma ação permitida, uma proibida, um pedido de aprovação e uma falha de controle. Verifique onde cada decisão teve efeito e se a evidência corresponde ao resultado. Registre o que não foi coberto. Passar nessas verificações sustenta o escopo testado, não uma afirmação sobre todas as ações ou todos os runtimes.