Governar agentes de IA no Atlassian: o que o novo controle central do Rovo faz, e o que ele deixa por sua conta
Em agosto de 2026, a Atlassian passou a permitir que administradores de organização gerenciem e governem agentes Rovo a partir de um local central no Atlassian Administration. Segundo as notas de lançamento, o recurso dá visibilidade a todos os agentes existentes na organização, filtrados por site, e permite definir uma política de acesso padrão para agentes recém-criados, com o objetivo declarado de garantir mais segurança e conformidade sem precisar procurar site a site. É um avanço real de plataforma, e também um lembrete de escopo: o controle governa quem pode acessar e usar cada agente, não o que cada agente consegue alcançar no dado da empresa. A primeira decisão é de administração do Atlassian. A segunda é de governança de dados, e continua sendo responsabilidade de quem desenha o acesso ao dado, agente ou não.
Por que esse controle chegou agora
Agentes de IA deixaram de ser experimento e passaram a se multiplicar dentro das ferramentas de trabalho. Onde há muitos agentes criados por times diferentes, aparece um problema clássico de administração: ninguém consegue mais responder quantos existem, quem os criou e quem pode usá-los. A resposta da Atlassian a isso é o padrão que a plataforma já aplicou a outros objetos, o de trazer a visão para um ponto central.
O movimento vem acompanhado de sinais na mesma direção. As notas de lançamento de agosto também registram a substituição da abordagem de lista de permitidos por uma de lista de bloqueados na página de acesso ao Rovo, o que torna mais fácil enxergar onde os recursos estão desabilitados na organização. São mudanças de governança de uso, e elas respondem à pergunta de quem pode. É a pergunta certa, e não é a única.
A tese deste guia: governar quem usa um agente e governar o que um agente alcança são duas camadas distintas, e o novo controle central resolve a primeira. Um agente com acesso de uso restrito a poucas pessoas, mas com alcance amplo sobre dado sensível, continua sendo um risco que o painel de agentes não vê, porque esse alcance é definido na camada de dado, não na de administração de IA. Confundir as duas leva à sensação de controle sem o controle correspondente.
O que o controle central do Rovo faz

As capacidades acima são reproduzidas das notas de lançamento oficiais do Atlassian Administration de agosto de 2026. Elas descrevem controles de acesso e de uso de agentes, centralizados na administração da organização, e não controles sobre o alcance de leitura de cada agente no dado corporativo.
A camada que o painel de agentes não governa
A pergunta que o novo controle não responde é a mais consequente em ambiente com dado sensível: se este agente for acionado, o que exatamente ele consegue ler? Governar quem pode usar um agente limita o número de pessoas que o acionam. Não limita o alcance do que o agente devolve quando acionado, e esse alcance é herdado da estrutura de acesso ao dado, não da configuração do agente.
Essa é a camada de governança de dados, e ela vive onde o dado vive. Em ambiente de dados corporativo, o alcance de um agente deveria ser definido pela mesma estrutura que governa o acesso humano, e não por uma credencial criada à parte para o agente funcionar. A documentação da Databricks descreve o Unity Catalog aplicando as mesmas permissões a pessoas, notebooks e modelos, com controle de acesso, linhagem e auditoria centralizados, e controles como máscaras de coluna e filtros de linha aplicados no momento da consulta, de modo que o tratamento de dado sensível aconteça independentemente de quem, ou do que, consulta. É a resposta técnica à pergunta que o painel de agentes deixa em aberto.
A distinção entre governar o uso do agente e governar o alcance do agente no dado é formulação editorial da CSP Tech, construída a partir do escopo declarado do recurso da Atlassian e das capacidades documentadas de governança de dados. Não é uma limitação afirmada pela Atlassian sobre o próprio produto.
As duas camadas de governança de agente, lado a lado

A segunda linha é a que amarra a novidade ao trabalho de instância. O controle central diz quem pode usar; o registro de que o agente fez algo, com dono e histórico, continua morando na configuração da instância, e é ali que a ação assistida deixa rastro auditável ou não deixa. As três perguntas juntas descrevem a governança completa de um agente, e nenhuma delas é resolvida sozinha pelo painel novo.
O que muda para quem administra o Atlassian
A chegada do controle central não reduz o trabalho de governança, ele o reorganiza. Três frentes passam a ser tratáveis a partir da administração da organização, e três continuam dependendo de desenho fora dela.
• Passa a ser central: o inventário. Saber quantos agentes existem e onde deixa de exigir varredura site a site. É a base de qualquer governança, e agora está disponível.
• Passa a ser central: a política de acesso padrão. Agente novo já nasce com uma política, em vez de herdar acesso amplo por omissão. Isso corrige o hábito mais comum, que é o acesso concedido por conveniência.
• Continua de instância: o registro da ação. O que o agente faz precisa virar item com dono e histórico, e isso é configuração de tipos de item, workflow e trilha na própria instância.
• Continua de dados: o alcance de leitura. O que o agente consegue ler é definido na plataforma de dados, com o mesmo modelo de permissão do acesso humano e tratamento aplicado na consulta.
Por que isso pede especialista de instância e de dados ao mesmo tempo: o controle central é operado por quem administra o Atlassian, o registro da ação é desenhado por quem configura a instância, e o alcance no dado é governado por quem desenha o acesso na plataforma de dados. As três precisam conversar, ou a empresa fica com a sensação de governança que o painel novo oferece sem a substância que falta nas outras duas camadas. A CSP Tech atua como Atlassian Gold Partner na instância e na administração, e como especialistas na governança de dados que define o alcance, o que permite tratar a governança do agente como um desenho único.
Quando o controle central já basta
• Agentes que só leem dado público interno. Se o alcance de leitura não inclui dado sensível, governar quem usa é suficiente, e a camada de dado tem pouco a acrescentar.
• Agentes que não executam ação em sistema. Se o agente apenas responde e não altera registro nem dispara fluxo, a camada de registro de ação perde peso, e o controle de uso cobre a maior parte do risco.
• Organização pequena, com poucos agentes e permissões já estreitas. Quando o alcance já é mínimo por desenho, o inventário central e a política padrão resolvem, e o esforço adicional rende pouco.
Perguntas frequentes
Como governar agentes Rovo no Atlassian?
Desde agosto de 2026, administradores de organização podem gerenciar e governar agentes Rovo de um local central no Atlassian Administration, com visibilidade de todos os agentes filtrados por site e definição de uma política de acesso padrão para agentes recém-criados. O acesso granular por agente também pode ser gerido ali. Segundo a Atlassian, o objetivo é garantir mais segurança e conformidade sem procurar site a site. Esse controle governa quem pode usar o agente.
O controle central do Rovo governa o que o agente pode acessar nos dados?
O recurso, conforme descrito nas notas de lançamento, governa o acesso e o uso dos agentes, ou seja, quem pode usá-los. O que um agente consegue ler no dado corporativo é definido pela estrutura de acesso da plataforma de dados, não pela administração de agentes. O desenho recomendado é que o alcance do agente siga o mesmo modelo de permissão do acesso humano, com tratamento de dado sensível aplicado no momento da consulta, de modo que a proteção não dependa de o agente cooperar.
Qual a diferença entre governar o uso e governar o alcance de um agente de IA?
Governar o uso limita quem pode acionar o agente, e é o que o controle central do Rovo faz. Governar o alcance limita o que o agente consegue ler ou fazer quando acionado, e isso vive em duas camadas fora do painel de agentes: o registro da ação, que mora na configuração da instância, e o acesso ao dado, que mora na plataforma de dados. Um agente com uso restrito e alcance amplo sobre dado sensível continua sendo um risco que o controle de uso não enxerga.
O que muda para o administrador Atlassian com a governança central de agentes?
O trabalho é reorganizado, não reduzido. Passam a ser tratáveis da administração central o inventário de agentes e a política de acesso padrão para novos agentes. Continuam dependendo de desenho fora da administração de IA o registro rastreável do que o agente faz, que é configuração de instância, e o alcance de leitura sobre o dado, que é governança da plataforma de dados. As três camadas precisam conversar para que a governança do agente seja completa.
Próximo passo
Se a sua empresa usa agentes no ambiente Atlassian, o novo controle central resolve uma pergunta importante e vale ser adotado. Antes de dar o tema por encerrado, porém, vale fazer as outras duas: o que cada agente registra quando age, e o que cada agente consegue ler. Solicite uma avaliação de governança de agentes de IA no seu Atlassian com a CSP Tech e receba o mapa das três camadas no seu ambiente: quem usa, o que fica registrado e qual o alcance real de cada agente sobre o seu dado.
Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Revisão técnica por especialistas Atlassian e de dados da CSP Tech (Atlassian Gold Partner, parceira Databricks, Microsoft Gold Partner, participante do Anthropic Partner Network, 34 anos de mercado, produto próprio Power BI for Jira no Atlassian Marketplace).
Fontes (oficiais, acesso set/2026): Atlassian, notas de mudanças do Atlassian Cloud referentes ao período de agosto de 2026 (confluence.atlassian.com/cloud/blog), quanto ao recurso que permite a administradores de organização gerenciar e governar agentes Rovo de um local central no Atlassian Administration, com visibilidade de todos os agentes filtrados por site, definição de política de acesso padrão para agentes recém-criados e gestão de acesso granular por agente, com o objetivo declarado de melhorar segurança e conformidade sem procurar site a site; e quanto à substituição da abordagem de lista de permitidos por lista de bloqueados na página de acesso ao Rovo. Databricks Documentation (docs.databricks.com), quanto ao Unity Catalog aplicando as mesmas permissões a pessoas, notebooks e modelos, com controle de acesso, linhagem e auditoria centralizados, e a máscaras de coluna e filtros de linha aplicados no momento da consulta. A distinção entre governar o uso do agente e governar o alcance do agente no dado, bem como a organização em três camadas, são formulação editorial da CSP Tech, construídas a partir do escopo declarado dos recursos citados, e não constituem afirmação da Atlassian sobre limitações do próprio produto. Nenhum número fora das fontes citadas foi utilizado. Este conteúdo trata de arquitetura e governança técnica e não constitui aconselhamento jurídico.










