Segurança do Rovo MCP: o que revisar antes de permitir que agentes de IA atuem no Jira
Quem liberou o conjunto de gestão do Jira para agentes de IA em agosto talvez não saiba que, no fim de setembro, ele passou a incluir ferramentas que leem workflows e alteram telas. Ninguém voltou ao painel para aprovar isso. A segurança do Rovo MCP depende menos do dia da conexão e mais de configurações que continuam decidindo depois dele.
No artigo de 14 de outubro tratamos do que vale expor a um agente. Falta o lado do administrador da organização: o que travar no servidor oficial da Atlassian antes de liberar a escrita.
O que mudou no servidor MCP da Atlassian entre setembro e outubro
O registro de mudanças do Atlassian Rovo MCP teve entradas em oito datas diferentes entre 22 de setembro e 16 de outubro de 2026. Parte delas é ajuste fino de ferramenta. Outra parte mexe no que um agente consegue fazer dentro do seu ambiente.
Em 24 de setembro chegaram conjuntos de leitura e escrita para planejamento de capacidade individual, com ferramentas que alteram a alocação de pessoas entre projetos. Em 26 e 30 de setembro, o conjunto manage_jira ganhou ferramentas para consultar workflows, abrir o editor de workflow e ler e atualizar telas do Jira. No dia 29, a Atlassian incluiu um controle do servidor MCP na política de segurança de dados da organização. Em 13 de outubro vieram os MCP apps, cards visuais para buscar, criar, editar e transicionar issues do Jira dentro da conversa com o assistente, com distribuição gradual prevista até 23 de outubro.
O volume ajuda a medir o peso dessas mudanças. Segundo a Atlassian, o servidor recebe mais de cinco milhões de chamadas de ferramenta por dia útil, e quase um terço delas são escritas: criar itens, comentar, atualizar status. Com os cards, quem nunca configurou um conector passa a mover chamados pelo chat. A tarde de teste que vira rotina fica mais fácil de acontecer.
Como controlar o que agentes de IA escrevem no Jira?
O controle fica na aba Permissions do servidor, em Atlassian Administration, no caminho Connectors e depois Atlassian MCP server. Ali o administrador da organização libera ou bloqueia separadamente leitura, escrita e busca. A documentação da Atlassian trata essa aba como o principal ponto de controle e diz que o que for definido nela prevalece sobre Connected Apps e sobre as permissões individuais de apps do Marketplace.
A regra pode valer para a organização inteira ou por produto. Em Edit details, dá para manter a escrita fechada no Jira e aberta no Confluence. A mudança tem efeito imediato. Quando o agente tenta uma escrita bloqueada, o usuário recebe uma mensagem de acesso negado que nomeia a permissão não autorizada, então pelo menos a falha é visível.
Para quem está começando, a configuração que recomendamos é leitura e busca liberadas e escrita bloqueada no nível da organização. Assim a ordem de risco do artigo anterior, consulta antes de criação, vira regra da casa, sem depender de cada pessoa escolher bem os escopos na tela de consentimento. A escrita abre depois, produto a produto, quando existir um fluxo com dono e uma ação desenhada para ele.
A opção que libera ferramentas novas sem revisão
Quando o administrador libera uma intenção na aba Permissions, a liberação se estende a qualquer permissão nova que peça a mesma intenção. A documentação chama isso de aplicar a adições futuras e descreve o efeito sem rodeios: as permissões novas não passam por revisão do administrador e ficam disponíveis aos usuários assim que são adicionadas. Dá para desligar em Edit details, mas o comportamento vem embutido no próprio gesto de marcar a permissão na tabela.
Setembro mostrou o que isso quer dizer. Quem tinha aprovado o manage_jira passou a ver, sem nenhuma decisão nova, ferramentas para consultar workflows, abrir o editor de workflow e atualizar telas do Jira. Alterar uma tela é mexer na configuração do produto, tarefa que costuma ficar com os administradores do Jira. A aprovação original tinha sido dada a outro conjunto de ferramentas.
Duas providências reduzem bastante esse risco. Desligar a aplicação automática para escrita e gestão faz cada ferramenta nova entrar por decisão de alguém com nome. E a leitura do registro de mudanças do servidor precisa entrar na rotina de quem sustenta o ambiente Atlassian. Com oito datas de mudança em menos de quatro semanas, uma revisão por trimestre chega tarde.
Política de dados do Rovo MCP: o que ela bloqueia e o que passa por fora
Desde 29 de setembro, o administrador encontra em Security, Data protection e Data security policies um controle próprio para o servidor MCP da Atlassian. Ele define um padrão para a organização e aceita exceções por produto, por espaço e por nível de classificação. Quando bloqueia um conteúdo, o agente deixa de lê-lo pelo MCP mesmo que o usuário tenha permissão para abri-lo no Jira, e o acesso pela interface continua como estava.
A página do controle lista o que fica de fora, e a lista pesa. Servidores MCP customizados não são cobertos. As APIs REST usadas pelos recursos dos próprios produtos também não. E as políticas de segurança de dados valem apenas para autenticação OAuth, não para token de API.
Esse último ponto corrige uma simplificação do nosso artigo anterior, que apresentou o OAuth 2.1 como a forma de conectar o agente. Ele é o padrão e o caminho que a Atlassian recomenda, mas o administrador pode permitir conexões por token de API, pensadas para automações e ferramentas sem interação que usam uma conta compartilhada. Segundo a documentação de configuração do servidor, quem entra por token nem passa pela lista de domínios permitidos; fica sujeito apenas à allowlist de IP e aos escopos do token.
A chave de token de API, na seção Authentication do servidor, deveria ficar desligada até surgir um caso concreto que a justifique. Ligada, ela pede um inventário das automações que usam token, com a conta e o escopo de cada uma. E pede que a área de segurança saiba que esse tráfego não obedece à política de dados que acabou de configurar.
Classificação de dados e Atlassian Guard: quando o controle por espaço não basta
O controle de MCP na política de dados exige Atlassian Guard Standard. A cobertura por nível de classificação, a mais precisa, só vem com o Guard Premium. Para a empresa, isso vira uma decisão de licença que convém tomar antes do primeiro agente com permissão de escrita.
O critério é onde mora o dado sensível. Se folha de pagamento, contratos e dados de clientes ficam em projetos e espaços separados, exceções por espaço resolvem boa parte do problema com o Guard Standard. O quadro muda quando RH, Financeiro e Compras atendem pelo mesmo Jira Service Management e o pedido sensível divide a fila com o pedido trivial. Nesse caso só a classificação acompanha o conteúdo, porque ela marca o item, e não o lugar onde ele está guardado.
E a classificação precisa existir antes de proteger alguma coisa. Na mesma leva de mudanças do controle de MCP, a Atlassian liberou regras de classificação que atribuem níveis a partir de detecções, o que diminui a dependência de alguém marcar item por item. Alguém ainda precisa definir os níveis e testar as regras. Uma política por classificação aplicada a uma base sem classificação não bloqueia nada.
O bloqueio que o agente não percebe
Os dois controles falham de jeitos diferentes. O bloqueio da aba Permissions aparece: o usuário recebe acesso negado e sabe que precisa procurar o administrador. O da política de dados é silencioso. Itens cobertos somem das buscas, inclusive das consultas JQL feitas pelo agente, e o pedido por um item específico volta como inexistente ou sem permissão. A Atlassian avisa que agentes que contam com esse conteúdo podem devolver resultados incompletos.
Pense num agente que monta toda segunda-feira o resumo de incidentes abertos para a diretoria. Depois que um projeto classificado entra na política, o número cai e nenhum erro aparece. Quem lê o relatório enxerga melhora onde houve só filtro. Na consulta de reembolso que usamos como exemplo no artigo anterior, o colaborador ouve que o pedido não existe.
Por isso a ativação da política merece o tratamento de uma mudança em produção. Antes de ligar, alguém precisa levantar os agentes e automações que leem pelo MCP e avisar os donos desses fluxos. Um teste simples resolve muita dúvida: consultar um item conhecido antes e depois da ativação e comparar as respostas. Relatórios gerados por agente devem passar a informar que a visão é filtrada.
Onde a segurança do Rovo MCP entra no Health Check Atlassian
O Health Check Atlassian da CSP Tech já inclui, para ambientes que vão receber agentes, a revisão de permissões e de apps instalados. Com as mudanças de setembro e outubro, essa revisão passa a cobrir o servidor MCP de forma explícita. Começa pelo método de autenticação de cada agente conectado, separando o que entra por OAuth do que entra por token, e com qual conta. Segue pela aba Permissions, com a divisão por produto e a situação da aplicação automática a ferramentas novas. Depois vêm a política de dados, com seu padrão e suas exceções, e a conversa sobre Guard Standard ou Premium, decidida pelo lugar onde o dado sensível está.
A rede entra na mesma revisão. A allowlist de IP da organização vale para chamadas via MCP qualquer que seja a autenticação, e algumas ferramentas de IA saem por endereços próprios, o que derruba chamadas feitas de dentro da VPN corporativa até esses endereços serem incluídos. Os cards visuais dependem de acesso a *.atlassian.net na saída da rede. Quem mantém allowlists com os IPs da Atlassian em integrações e backends tem até 1º de janeiro de 2027 para incluir as faixas novas anunciadas em 16 de outubro.
Nada disso se resolve numa configuração única. O registro de mudanças vai continuar se mexendo, e a leitura dele, com a decisão sobre cada ferramenta nova, fica com o time de sustentação que já acompanha o ambiente no dia a dia.
Para que você possa se aprofundar ainda mais, recomendamos também a leitura dos artigos abaixo:
Proteja sua equipe com o Atlassian Guard Premium
Consultoria Jira em 2026: quando configurar a ferramenta vira desenhar governança de dados
Quem aprova a próxima ferramenta
No servidor MCP da Atlassian, uma aprovação dada hoje vale para ferramentas que ainda não existem. Quem liberou o conjunto de gestão do Jira em agosto decidiu também sobre o que entrou nele em setembro, sem ter visto. A pergunta útil para esta semana é quem na empresa tem nome e autoridade para aprovar cada ferramenta nova, e de quanto em quanto tempo essa pessoa abre o registro de mudanças.
Se hoje a resposta é ninguém, a configuração padrão está decidindo no lugar da empresa. Melhor corrigir isso antes que um relatório filtrado por uma política silenciosa vire base para uma decisão da diretoria.
Se você quer saber como estão as permissões e a política de dados do seu ambiente antes de liberar a escrita para agentes, converse com os especialistas da CSP Tech sobre um Health Check Atlassian.
Fale com a CSP Tech: https://www.csptech.com.br/contato
