Segurança e barreiras de proteção para agentes de IA no Jira
As barreiras de proteção permitem que você escale a adoção da IA criando confiança com fluxos de trabalho orientados por IA. Os que funcionam são integrados aos fluxos de trabalho, para que o sistema os aplique em vez de confiar que o agente faça isso.
No Jira, esse sistema é aquele em que a equipe já executa os tickets. O Jira concede ao agente o acesso que ele deve ter por meio de permissões, pontos de verificação em que pessoas avaliam as mudanças de status do fluxo de trabalho e um registro de cada ação do agente no ticket. O Teamwork Graph oferece ao agente o contexto certo para agir.
Este guia aborda os riscos que as barreiras de proteção do agente mitigam e como aplicar isso no Jira para que você possa escalar a IA com segurança e responsabilidade, dando aos agentes mais autonomia nos tickets da equipe, desde tarefas de rotina para manter a operação até projetos de maior valor, sem perder o controle. A autonomia ao escalar depende de quatro barreiras de proteção que você define no Jira, usando os fluxos de trabalho, as permissões e as regras que a equipe já executa:
Acesso ao escopo. Defina quais dados um agente pode acessar, as ferramentas que pode usar e onde pode atuar por meio das permissões existentes do Jira.
Restrinja as chamadas arriscadas. Use mudanças de status de fluxo de trabalho para exigir aprovação humana antes que um ticket de alto impacto seja entregue.
Analise a saída. Verifique o que o agente produziu por meio da análise normal de pull request antes de ser lançado.
Mantenha o registro. Toda ação do agente fica registrada no histórico do ticket, vinculada a quem a aprovou.
O que são barreiras de proteção na engenharia orientada por IA?
Barreiras de proteção do agente são os controles que mantêm o ticket de um agente de IA seguro, intencional e registrado: o que ele pode acessar, os pontos de verificação em que uma pessoa intervém e o registro do que ele fez. Uma barreira de proteção é aplicada pelo sistema em que o agente trabalha, não é deixada para o agente respeitar por conta própria.
Você não pode tornar um agente seguro ensinando a ele como se comportar, porque as instruções podem ser esquecidas, mal interpretadas ou substituídas. Uma verdadeira barreira de proteção fica acima do agente, no ambiente, onde o limite se mantém não importando o que foi dito ao agente. É o mesmo princípio que a equipe já segue: o sistema decide o que é possível, não é a pessoa que deve seguir as regras.
Na prática, as barreiras de proteção do agente abrangem algumas áreas conectadas:
Acesso e escopo. Os dados que um agente pode acessar, as ferramentas que ele pode usar e onde pode atuar.
Tarefas delimitadas. Quais tickets um agente pode assumir de imediato e quais permanecem com uma pessoa.
Aprovação com intervenção humana. Os pontos de controle em que alguém revisa ou aprova antes de o ticket avançar.
Revisão da saída. Validação do que o agente produziu antes do lançamento.
Responsabilidade e auditoria. Um registro do que o agente fez, por que e quem aprovou.
Governança. Os controles permanentes que mantêm tudo isso consistente à medida que o uso de agentes aumenta.
Juntas, essas áreas geram confiança nos fluxos de trabalho agênticos. Elas permitem que uma equipe delegue mais responsabilidade aos agentes sem perder o controle, porque uma pessoa continua responsável pelo resultado.
Por que os agentes de IA precisam de barreiras de proteção?
Os agentes atuam. Ao contrário de um chatbot que apenas sugere, um agente pode alterar o código, mover tickets e acionar ações reais em suas ferramentas. Essa autonomia é o que os torna úteis, e também o motivo de precisarem de barreiras de proteção: quanto mais um agente puder fazer por conta própria, mais importante vai ser a manutenção de um trabalho alinhado, revisado e responsável.
Os principais riscos abordados pelas barreiras de proteção e onde o julgamento humano continua sendo essencial:
Desalinhamento: o agente otimiza para o elemento errado ou se desvia da tarefa.
Resultado incorreto ou de baixa qualidade: ticket que parece concluído, mas não atinge o objetivo, incluindo fatos ou códigos incorretos.
Acesso excessivo: o agente com acesso a dados ou sistemas que não deveria.
Ações irreversíveis e não revisadas: alterações de alto impacto que você não consegue desfazer com facilidade, como enviar para a produção ou excluir dados, e que exigem uma verificação humana antes de serem implementadas.
Falta de prestação de contas ou visibilidade: sem um registro, ninguém pode ver o que o agente fez ou quem aprovou.
Custo descontrolado: os agentes podem consumir tokens e computar sem previsão, por isso os gastos precisam de limites como qualquer outro recurso.
Uma barreira de proteção só funciona se for aplicada pelo sistema, não pelo agente. Dizer a um agente o que não fazer não é uma barreira de proteção, porque ele pode ser instruído e ainda assim executar a ação sem o seu conhecimento. As verdadeiras barreiras de proteção ficam acima do agente, no ambiente em que ele opera, para que a ação indesejada não seja possível, não apenas desencorajada.
É por isso que as barreiras de proteção são um pré-requisito para a autonomia, não um impedimento para ela. As equipes que confiam nos limites podem dar mais responsabilidade aos agentes com menos supervisão direta. As equipes que não conseguem fazer isso vão perder a velocidade pela qual adotaram os agentes.
Como governar os agentes de IA com segurança no Jira?
Se uma barreira de proteção precisa ficar acima do agente no sistema em que ele atua, então esse sistema é o que importa, e para a engenharia, é o Jira. Quando os agentes operam no System of Work da Atlassian, eles acessam os dados e tickets por meio das mesmas permissões do Jira que sua equipe já usa, além dos fluxos de trabalho e trilha de auditoria existentes. O que um agente pode fazer dentro do próprio ambiente ainda é controlado pelo agente, então o Jira gerencia o acesso ao ticket, enquanto as permissões no nível do agente controlam as ferramentas que ele executa.
Sozinho, um agente de codificação governa apenas as próprias ações. O Jira controla o ticket, então as barreiras de proteção se aplicam em um só lugar para todos os agentes, e você pode ver qual risco cada uma trata.
Os fluxos de trabalho são onde a maior parte dessa aplicação acontece. Os status, transições e regras que encaminham o ticket entre as pessoas também o encaminham para os agentes, decidem quais transições um agente pode executar e retêm alterações de alto impacto para aprovação.
Acesso: o que você pode controlar no Jira
O primeiro controle é o escopo: com quais dados, ferramentas e projetos um agente pode trabalhar. Essa é a barreira de proteção contra o acesso muito amplo. No Jira, você define isso da mesma forma que configura para qualquer colega de equipe, assim, o processo é familiar e você pode ajustar como quiser.
Como funciona no Jira: você escolhe a identidade que um agente assume. Por padrão, ele atua em nome da pessoa responsável por ele, acessando apenas os dados, projetos e tickets que essa pessoa pode acessar. Você também pode dar a um agente uma conta e permissões, para que o acesso não dependa de uma única pessoa. Os administradores controlam quais agentes estão ativos e onde. O que um agente pode fazer com as próprias ferramentas é definido pelo agente, não pelo Jira. Mantenha o acesso amplo ou defina um escopo restrito. Conforme a confiança cresce, você o expande.
Os controles que você ajusta. Essas são as mesmas alavancas de permissão que você já usa para as pessoas: esquemas de permissão e funções de projeto definem o que um agente pode fazer em um projeto, e a segurança de itens limita quais tickets específicos ele pode ver. Restringir qualquer uma dessas opções limita o alcance do agente, sem a necessidade de um sistema específico para ele.
Conceda acesso ao que a tarefa precisa. A maioria dos agentes trabalha melhor com espaço para se mover, então ajuste o escopo de acordo com a tarefa. Para sistemas muito sensíveis, restrinja o acesso a eles.
Como você controla o que os agentes fazem no seu fluxo de trabalho?
A segunda barreira de proteção é o fluxo de trabalho: as regras que definem quando um agente é executado, o que ele pode fazer sozinho e quais chamadas aguardam uma pessoa. É a sua defesa contra desalinhamentos e ações irreversíveis. Você define essas regras nas transições que a equipe já usa. Dessa forma, a supervisão não é um ponto de controle único no final.
Uma condição de transição limita em quais etapas um agente pode atuar; um validador bloqueia um ticket que não está pronto; e uma etapa de aprovação retém alterações de alto impacto para uma pessoa. A aprovação humana é uma regra entre várias. A tarefa é associar cada regra ao risco.
Como configurar isso no Jira: abra o fluxo de trabalho para o tipo do ticket e adicione um agente a uma transição. Por exemplo, ao inserir “Em revisão”, para que o agente seja executado quando um ticket chegar a esse ponto. Adicionar um agente define quando ele é executado, não se uma pessoa aprova. A aprovação humana é um controle separado: uma etapa de aprovação do fluxo de trabalho controla a transição. Você pode combinar essa etapa com as instruções do agente sobre quando pausar e perguntar, ou com uma regra de automação. A transição é um dos vários pontos de entrada. Um agente também pode iniciar quando:
O trabalho é criado, para iniciar a triagem assim que é recebido
Uma etiqueta ou campo é alterado, ou programado, por meio de uma regra de automação
Ele é executado em segundo plano para atualizações de rotina, como elaboração de notas de versão
Adeque o controle ao risco. Permita a execução automática do ticket de baixo risco (uma atualização de dependência), notifique alguém sobre o ticket de médio risco (uma alteração na configuração compartilhada) e exija aprovação para ações de alto risco ou irreversíveis (alterar a produção ou excluir dados).
Decida quais tarefas são de responsabilidade do agente. Decidir as responsabilidades de um agente vem antes da definição do ponto de controle. Deixe que um agente assuma por completo os tickets de baixo risco, prepare os tickets de maior impacto para uma pessoa finalizar e mantenha as chamadas mais críticas com um humano. Definir os limites da tarefa é a primeira decisão; o ponto de controle é como você a aplica.
Ofereça aos agentes instruções personalizadas. Você define como um agente deve se comportar e conduzir o ticket, incluindo quais decisões ele pode tomar e quando pausar e perguntar, para que siga as convenções da sua equipe em vez de padrões genéricos.
Revise o resultado: como você valida o que o agente produziu?
A terceira barreira de proteção é a revisão do produto do ticket, em que uma pessoa identifica resultados de baixa qualidade e alucinações antes da entrega. Para um agente de codificação, isso é o pull request que ele abre.
No Jira: trate o resultado do agente como não confiável até que alguém ou as verificações atuais o validem, com o mesmo critério que você aplicaria ao código de um novo colaborador. O trabalho do agente está vinculado ao ticket. As alterações de código chegam como um pull request que passa pelo seu processo normal de revisão e mesclagem. Nenhum resultado produzido por um agente pula o processo atual de revisão da sua equipe.
Veja o trabalho por trás do resultado. Você não vê apenas o resultado final. As sessões de agente no Jira oferecem um local centralizado para ver o que um agente fez e por quê, para que um revisor tenha o contexto necessário para entender o resultado em vez de optar pela reconstrução.
Legenda: Exemplo: defina padrões de revisão de código por IA no Bitbucket Cloud para uma aplicação automática em cada pull request.
Mantenha um registro de responsabilidade: quem fez o quê e quando?
A quarta barreira de proteção é o registro, a resposta para a responsabilidade. Ele vincula o trabalho do agente à intenção: o que o agente fez, por quê, qual ticket ele resolveu e quem aprovou. Esse vínculo é o que torna os itens fáceis de rastrear e solucionar quando algo dá errado.
No Jira: cada agente opera sob uma identidade conhecida: seja a pessoa que atribuiu o ticket ou o configurou, agindo com as permissões dessa pessoa, ou sua própria conta de agente com as permissões que você atribui. De qualquer forma, o registro vincula cada ação a uma identidade responsável. O registro captura o que o agente fez e quem é responsável por isso no histórico do ticket, bem como a atividade humana, com as aprovações vinculadas ao revisor que as aprovou. Os administradores também podem monitorar os logs de auditoria em busca de atividades incomuns.
Registre o ticket do agente local. O rastreamento de sessão do agente faz com que a atividade de agentes de codificação de IA locais em IDEs ou terminais locais seja vinculada ao ticket, dessa forma o ticket criado fora do Jira ainda fica em um único registro. Faça a inscrição na lista de espera.
Quais são as melhores práticas para as barreiras de proteção do agente?
Corresponda o acesso de um agente à tarefa e amplie à medida que a confiança aumenta (os agentes usam as permissões existentes do Jira).
Dê aos agentes instruções claras sobre como agir e quando pausar e perguntar.
Inicie os agentes em tickets reversíveis e de baixo risco antes de tarefas de alto impacto.
Envolva uma pessoa nas decisões mais importantes, com pontos de verificação em mais de uma etapa, não apenas na aprovação final.
Revise a saída do agente usando o mesmo processo que aconteceria com uma pessoa (mesclagem e revisão de pull request).
Mantenha as ações do agente registradas, vinculadas ao ticket (histórico e log de auditoria).
Contextualize os agentes para controlar os custos, já que os gastos excessivos acontecem quando eles tentam adivinhar e refazem tickets.
A Atlassian descobriu que a IA baseada no Teamwork Graph melhorou a qualidade das respostas em 44%, reduzindo o consumo de tokens em 48%.
Quais são as barreiras de proteção do Jira e quais ficam em outro lugar?
As barreiras de proteção estão presentes em várias camadas da pilha do agente. O Jira é responsável pela camada de ticket e acesso. As outras camadas ficam a cargo do provedor de modelo, do framework de agente e da IC.
Barreiras de proteção do Jira | Barreiras de proteção presentes em outros locais da pilha |
Definem o escopo de acesso do agente por meio das permissões do Jira e da configuração do projeto | Filtram ou moderam a saída do modelo (o provedor do modelo faz isso) |
Exigem que uma pessoa aprove o ticket em uma mudança de status de fluxo de trabalho | Executam o modelo ou o tempo de execução do agente (o agente de codificação do Jira é executado em um repositório oferecido pela Atlassian. Os agentes de terceiros são executados em no próprio framework) |
Registram ações do agente no histórico do ticket e nos logs de auditoria do administrador | Bloqueiam todas as injeções de prompt (a filtragem ajuda, mas nada é infalível. O Jira limita os danos se algo passar). |
Definem a execução autônoma ou com aprovação por tarefa | Implementam verificações no nível do código, como testes e análises de segurança (o pipeline de IC faz isso) |
O Jira controla o que os agentes podem fazer e registra as ações. Ele complementa, em vez de substituir, a segurança em nível de modelo e de tempo de execução.
Como adicionar a primeira barreira de proteção de agente no Jira
Você não precisa ter um programa de governança completo para começar. Uma barreira de proteção permite que você atribua um ticket real a um agente com responsabilidade, com uma pessoa tomando as decisões importantes, e, à medida que você fica mais confiante, pode ampliar.
Escolha uma tarefa de rotina e reversível, como um teste instável ou problemas de dependência (diminuindo o custo de um erro).
Execute o agente com o acesso que você daria a um novo colega de equipe, não mais do que o necessário.
Adicione a uma mudança de status de fluxo de trabalho para que uma pessoa aprove primeiro (detecta ações arriscadas ou desalinhadas).
Revise a pull request usando o processo normal (detecta saída de baixa qualidade ou alucinações).
Confirme se há registro no ticket (rastreabilidade caso precise reverter).
É assim que você faz o build do fluxo de trabalho para escalar a IA com responsabilidade: melhor saída do agente, menos tempo de revisão e mais autonomia que você pode ampliar com segurança.
Confira o Guia Prático de Governança Responsável de IA, como parte dos Princípios da Tecnologia Responsável da Atlassian.
Perguntas frequentes sobre as barreiras de proteção do agente de IA
Como manter os agentes de IA seguros?
Você mantém os agentes de IA seguros controlando o que eles podem acessar, exigindo aprovação humana para ações de alto impacto e registrando tudo o que eles fazem, com supervisão adequada ao risco de cada tarefa.
Como o Jira controla os agentes de IA?
O Jira controla os agentes de IA usando os controles já usados pela equipe: os agentes operam dentro das permissões e dos fluxos de trabalho do Jira, você pode exigir aprovação humana em uma mudança de status de fluxo de trabalho e as ações deles são registradas no histórico do ticket e no log de auditoria.
Os agentes de IA no Jira podem exigir aprovação humana?
Sim. Você pode adicionar um agente a uma mudança de status de fluxo de trabalho para que uma pessoa revise e aprove a saída antes que o ticket avance. A autonomia acontece em tarefas reversíveis e de baixo risco.
E quanto à injeção de prompt com agentes de IA?
A injeção de prompt é uma entrada não confiável que tenta direcionar um agente para ações não intencionais. A Atlassian filtra a entrada para agentes com tecnologia Rovo contra tentativas de injeção e, como nenhum filtro é infalível, as barreiras de proteção em camadas cuidam do resto: acesso limitado, aprovação humana e uma trilha de auditoria completa.