Atlassian Rovo MCP: como dar acesso ao Jira para agentes de IA sem perder o controle
Em boa parte das operações, o pedido chega por e-mail, telefone, WhatsApp e planilha. Não há fila, ninguém mede o tempo de resolução e o Jira que deveria organizar tudo acumulou campos e workflows que ninguém sabe explicar. É nesse ambiente que o time pede para ligar um agente de IA ao Jira. O Atlassian Rovo MCP, módulo novo do Forge, permite fazer essa ligação com controle, mas só rende onde a operação já tem fila, dono e prazo.
O que trava a operação antes de qualquer agente
Três situações aparecem com frequência quando um cliente procura a CSP Tech. A primeira é o atendimento sem controle: pedidos espalhados por canais diferentes, sem fila nem SLA. A segunda é a ferramenta legada, que o cliente quer trocar pelo custo ou porque deixou de acompanhar a operação. A terceira é o Atlassian subutilizado, em que o Jira acumulou campos, workflows, permissões e plugins ao longo dos anos e a empresa paga licenças avançadas para usar uma fração do que contratou.
Por trás das três existe o mesmo quadro. Falta um indicador em que a gestão confie, cada área resolve o mesmo tipo de pedido de um jeito e a demanda some quando passa de um sistema para outro. É uma operação sem governança, e o gestor percebe isso no dia em que precisa dizer onde está um pedido e ninguém sabe.
Ligar um agente a esse ambiente acelera o que já existe, inclusive a desordem. Por isso a conversa sobre o Atlassian Rovo MCP começa pela operação, e a tecnologia entra quando o desenho está pronto.
O que muda quando o agente herda o alcance do usuário
Um assistente de IA conectado ao Jira age com as permissões da pessoa que o autorizou. Imagine um analista com permissão ampla no Jira Service Management que pede ao assistente para fechar os chamados parados há semanas. O assistente executa, porque tem o mesmo alcance de quem o conectou. Ninguém aprovou aquela ação para um agente; a permissão já existia.
Num ambiente com permissões que ninguém sabe explicar, esse alcance é maior do que a empresa imagina. Uma pessoa mexe em um chamado por vez, enquanto um agente pode mexer em todos os que encontrar, em segundos, seguindo uma instrução ambígua. Quando RH, Financeiro e Compras passam a atender pelo JSM, o mesmo ambiente guarda dados de folha e aprovações de compra, e quem governa o Jira precisa saber o que um agente externo lê e o que ele altera.
Como conectar o Claude ao Jira sem expor dados?
O caminho oficial já existe. O Atlassian Rovo MCP Server é um servidor MCP hospedado pela Atlassian que liga produtos como Jira e Confluence a clientes de IA como Claude, Cursor e Codex. A autenticação usa OAuth 2.1, e as ações respeitam as permissões que o usuário já tem. O administrador define, na Atlassian Administration, quais domínios e ferramentas externas podem se conectar, e cada uso de ferramenta gera um evento no registro de auditoria da organização. Para buscar e resumir, é o ponto de partida natural.
A lacuna aparece nos fluxos que carregam regra de negócio. Abrir um pedido de acesso no JSM exige campos obrigatórios, aprovador definido e prioridade coerente com o SLA. Com as ferramentas genéricas do servidor oficial, o agente monta esse pedido por conta própria a cada vez, e cada montagem pode sair um pouco diferente. Para esses fluxos a resposta é uma ação própria, com entradas fixas e a regra embutida. Aí entra o Forge.
Como o Atlassian Rovo MCP funciona na prática
No Forge, a plataforma de apps da Atlassian, uma ação é uma função com nome, descrição e entradas definidas. O módulo rovo:mcp reúne as ações escolhidas e as publica como ferramentas para agentes. Cada app pode ter um módulo desse tipo, com até 50 ações. Para o gestor, o resultado é uma lista curta e nomeada do que um agente pode fazer, como consultar o andamento de uma solicitação de compra ou abrir um pedido de acesso.
A documentação da Atlassian fala em conexão com qualquer cliente compatível com MCP. A compatibilidade de cada cliente com o fluxo de autenticação do app é um ponto a validar no piloto. O controle acontece em camadas, e cada uma tem um responsável:
Quais ações existem. Só entra na lista do módulo o que foi desenhado para isso;
Quem liga. A exposição para clientes externos nasce desativada. O administrador da organização ou do site ativa, app a app e site a site, as ferramentas que quer liberar;
Quem autoriza. Ao conectar, o usuário passa por uma tela de consentimento OAuth 2.1, escolhe o site e vê os escopos e as ferramentas antes de aprovar;
Quem executa. Cada chamada vale só até onde vão as permissões do próprio usuário naquele site.
O app também só enxerga os dados do produto em que está instalado. Um app instalado no JSM não lê o Confluence, a menos que tenha sido configurado para múltiplos produtos. Ao desenhar esses apps, a CSP Tech soma uma camada própria: cada chamada fica registrada com quem pediu, qual ação foi executada e com quais entradas, para que a auditoria tenha o que ler quando alguém perguntar.
Preview e EAP: o que pode ir para produção hoje
Segundo a documentação da Atlassian, atualizada em 1º de outubro de 2026, o módulo rovo:mcp está em Preview. A Atlassian dá suporte completo a recursos nessa fase e os considera adequados para quem adota cedo, inclusive em produção, com a ressalva de que as janelas de descontinuação podem ser mais curtas. A conexão das ferramentas com clientes de IA de terceiros está num estágio anterior, o programa de acesso antecipado (EAP), que a documentação descreve como experimental, sem suporte e não recomendado para produção.
A consequência prática é direta. As ações podem ser construídas agora e usadas por agentes dentro do Rovo Studio. A abertura para Claude, Cursor e Codex deve rodar em sandbox, com dados fictícios ou de baixo risco, até a Atlassian mover o recurso de fase. Quem coloca isso em produção hoje aposta num contrato que o próprio fornecedor avisa que pode mudar. Esse status muda por versão, então a página do módulo vale ser reconferida antes de cada etapa do projeto.
O tempo de piloto não se perde. O trabalho mais demorado nesse tipo de iniciativa é decidir quais ações merecem existir, e essa decisão vale para qualquer cliente de IA que venha a usá-las. Os modelos e as ferramentas do outro lado da conexão vão mudar mais de uma vez. A lista do que a empresa aceita expor precisa atravessar essas trocas sem ser reescrita.
Que fluxos do Jira e do JSM merecem virar ação para agentes
Antes de escrever qualquer linha de Forge, o trabalho é mapear como o pedido anda hoje, com as exceções e os atalhos que ninguém documentou, e desenhar como deveria andar: papéis, prioridades, SLAs e indicadores. A plataforma só entra depois. Um fluxo que ainda vive em e-mail e planilha, entregue a um agente, passa a ser executado com mais rapidez e com a mesma desordem.
Os melhores candidatos costumam estar fora da TI. RH, Financeiro, Compras, Jurídico e Marketing têm pedidos repetitivos, com campos conhecidos e prazo definido, e é nessas áreas que o service desk corporativo (ESM) já organiza a entrada.
A ordem de risco sugere começar pela consulta. Perguntar em que etapa está um pedido de reembolso costuma gerar um chamado para o próprio RH. Uma ação de leitura que devolve só a etapa e o responsável resolve a dúvida sem expor o conteúdo do pedido. Em seguida vem a criação estruturada: abrir a solicitação com os campos obrigatórios preenchidos e na fila certa. Aprovar e encerrar ficam com pessoas até o registro de chamadas mostrar que consulta e criação se comportam.
Atlassian Enterprise Certified como critério de governança
Entre o agente e o Jira passam a existir apps, e cada app é uma decisão de risco. Em outubro de 2026, a Atlassian lançou o selo Atlassian Enterprise Certified, que dá às áreas de segurança e de compras um critério verificável para escolher entre eles. O selo vai para apps do Marketplace construídos no Forge, e a Atlassian o apresenta como substituto do Cloud Fortified na função de principal designação de confiança. Dá para filtrar a busca do Marketplace por ele.
Para ganhar o selo, o app precisa cumprir quatro grupos de exigência:
Segurança e gestão de vulnerabilidades: teste de penetração anual feito por empresa credenciada e participação no programa de bug bounty da Atlassian.
Privacidade e conformidade: SOC 2 Tipo 2 ou ISO 27001 verificado de forma independente, mais suporte a residência de dados e política documentada de retenção e exclusão.
Confiabilidade e suporte: página pública de status e resposta em 24 horas, cinco dias por semana, para incidentes críticos.
Acessibilidade e governança de IA: VPAT público e, quando aplicável, políticas de uso de IA que tratem de dados e de treinamento de modelos.
O selo avalia o app. Quais ações ele executa no seu Jira continua sendo decisão sua, e nenhum selo cobre isso. Existe um segundo selo, Runs on Atlassian, que trata de onde o app roda e de onde ficam os dados; um app pode ter os dois.
O selo vive nas listagens do Marketplace, e isso muda como usá-lo. Um app feito sob medida para uma única empresa, como os que expõem fluxos internos do JSM para agentes, não tem listagem e, na prática, não exibe o selo. Nesse caso as quatro exigências viram a lista de requisitos do contrato, e quem escreve o app precisa mostrar como atende a cada uma. Para apps de terceiros que passem a ficar entre os agentes e o Jira, o selo funciona como filtro de entrada. A Atlassian afirma que o programa ajuda as equipes de segurança, jurídico e compras a acelerar a revisão; a revisão da empresa continua existindo.
Por onde começar: um Health Check do ambiente Atlassian
A entrada de menor atrito é o Health Check Atlassian, um diagnóstico do ambiente atual com limpeza e um plano do que corrigir primeiro. Antes de expor qualquer ação a um agente, a empresa passa a saber o que existe no Jira, o que ainda faz sentido e quais fluxos já têm dono e prazo. Para ambientes que vão receber agentes, a CSP Tech inclui nesse diagnóstico a revisão de permissões e de apps instalados.
Dali saem os projetos estruturantes, como ITSM, ESM e migração para Cloud, do assessment ao go-live, e a continuidade: sustentação, hypercare e treinamento para que o time do cliente saiba operar o que foi entregue. Rovo e IA entram depois, quando processos, dados e base de conhecimento já estão organizados. Sem isso, o agente responde com o que encontra, e o que ele encontra é a desordem.
Essa lógica sustenta operações de portes diferentes. Na Magalu, a CSP Tech acompanhou o ciclo completo, do assessment à sustentação, com ITSM e gestão de projetos. Na A5X, setor regulado, entregou ITSM, Assets e apps Forge sob medida com regras do Bacen. A Integralmédica opera ITSM com uso intensivo de IA. Na Telecall, são mais de 22 portais de ESM, com mais de 3.500 chamados por mês atendidos por 150 agentes. A CSP Tech é Solution Partner Gold da Atlassian e acompanha o cliente do assessment à sustentação.
Para que você possa se aprofundar ainda mais, recomendamos também a leitura dos artigos abaixo:
O que faz um especialista Jira, e como reconhecer um de verdade
Consultoria Jira em 2026: quando configurar a ferramenta vira desenhar governança de dados
Antes de o primeiro agente agir
Em algum momento um agente vai agir no seu Jira, com projeto ou sem ele. Se a lista do que ele pode fazer não for escrita por alguém com nome e prazo, será escrita por quem conectou primeiro, numa tarde de teste que virou rotina. A pergunta útil para esta semana é qual fluxo do JSM já tem dono, prazo e critério de conclusão claros o bastante para abrir a lista, e quem na empresa tem autoridade para aprovar cada ação que entrar depois.
O princípio que a CSP Tech aplica a qualquer fluxo é simples: todo pedido tem responsável e prazo, e qualquer gestor sabe em que ponto ele está. Com agentes na operação, a regra passa a valer também para o pedido que um agente abriu.
Se você quer saber o que o seu ambiente Jira precisa resolver antes de receber agentes, e quais fluxos já estão prontos, converse com os especialistas da CSP Tech sobre um Health Check Atlassian.
Fale com a CSP Tech: https://www.csptech.com.br/contato
