Quem pode o quê, em governança

Correção de 12/10/2026 — o modelo de cinco ações descrito mais abaixo foi substituído em 11/10/2026. As seções a partir de "O piso, por papel" até "A concessão preserva o que não foi declarado" descrevem o modelo antigo (edital, cinco ações view/edit/approve/publish/manage, cinco escopos) e ficam preservadas como histórico. O que vale hoje está logo abaixo.

Modelo vigente (desde 11/10/2026)

Camada funcional

O edital deixou de ser contrato, e as cinco ações não descreviam o produto: editar, aprovar e publicar não protegiam nada (o ciclo de vida, o go-live e a promoção entre ambientes saíram), e "administrar" protegia toda escrita, de pausar um agente a conceder acesso. Elas foram trocadas por nove permissões, uma por ação do produto, escolhidas no editor de perfil (aba Governança) ou dadas por concessão:

Membro e Colaborador nascem sem nenhuma. Quem tinha "administrar" recebeu as seis permissões de gerenciar: ninguém perdeu acesso.

Regras que valem a pena saber:

• Toda permissão de governança traz "Ver" junto (no perfil e na concessão), porque sem ele ela não teria tela. A única exceção é a leitura condensada de consumo, lida no Leaderboard, fora da Governança. Fora o "Ver", ter uma permissão não dá as outras.
• Ninguém concede o que não tem. Quem gerencia acesso só concede as permissões que ele mesmo tem: na concessão, no papel vinculado a ela e no papel da organização. A tela desabilita as que a pessoa não pode dar; a rota responde 403 e o banco recusa o resto.
• Sem escalada por identidade, organização ou revivência (11/10/2026). A identidade de uma concessão (a quem, em qual organização) não muda por escrita do cliente; um papel não muda de organização nem se vincula a concessão de outra; e reviver ou estender uma concessão vencida conta como conceder de novo, inclusive as permissões dos papéis vinculados a ela: quem não as tem não consegue reativá-las.
• Concessão só na organização inteira. A tela concede apenas no escopo da organização (toda checagem de governança pergunta na organização, então um escopo menor seria salvo e ignorado). O escopo de ativo continua existindo só para o pedido de acesso aprovado, que concede "Ver"; o de aplicação publicada (App) segue à parte. Os escopos ambiente e caso de uso deixaram de existir.
• Os papéis de sistema gov_* saíram: nunca foram concedíveis. A concessão pela tela marca as permissões direto, e preserva um papel de organização que já estivesse anexado.
• Pedir acesso é pedir "Ver": a única ação pedível num ativo do catálogo.
• Onde se concede: Configurações da organização > Perfis (os cartões de concessões e login corporativo moraram na tela de acesso da Governança; o endereço antigo redireciona para lá).
• O item "Governança" do menu aparece para quem tem "Ver" no perfil; o portão da rota aceita "Ver" por perfil ou concessão (a tela esconde mais do que a rota fecha, na direção segura).

Histórico (até 10/10/2026)

Camada funcional

O acesso à governança não é um sistema paralelo ao papel que a pessoa já tem na organização. São dois níveis que se somam: o papel é o piso, e as concessões acrescentam a partir dele.

O piso, por papel

O caso do administrador é o mais instrutivo. Ele administra a configuração de governança, mas editar, aprovar a entrada em produção e publicar exigem concessão explícita. Ou seja: quem configura o sistema de controle não ganha, de brinde, o poder de aprovar aquilo que o sistema controla — que é exatamente a separação que uma área de conformidade exigiria.

O dono atravessa tudo, e isso é deliberado: não pode existir um estado em que ninguém consegue destravar a organização. "Tudo", aqui, são as cinco ações — desde 12/09/2026 existe um segundo tipo de permissão que fica ao lado delas, e que nem o dono recebe sem concessão explícita. A seção sobre permissões nomeadas explica por quê.

"Nenhuma" na linha do membro se refere às cinco ações, e só a elas. Ele não quer dizer que um membro não vê nada em nenhuma tela sob o guarda-chuva de governança — algumas são governadas pelo papel na organização, e não por este controle.

O exemplo concreto, para não deixar a dúvida no ar: a configuração de retenção da trilha de auditoria segue o papel na organização. Ver depende de ser membro; alterar depende de administrar. Quando esta página e a da trilha parecerem discordar, é porque são dois sistemas de autorização diferentes — não porque uma das duas esteja errada.

As cinco ações

Visualizar, editar, aprovar a entrada em produção, publicar e administrar governança.

Os nomes curtos que o sistema usa para elas são contrato, não detalhe interno: a matriz de conformidade que um auditor externo preenche é escrita contra eles. Por isso a lista foi preservada inteira mesmo quando o cálculo por trás mudou.

Os cinco escopos

Uma concessão não é "pode editar", é "pode editar aqui": na organização inteira, num ambiente, num caso de uso, num ativo específico, ou dentro de uma aplicação publicada.

Vale como padrão geral o que aconteceu aqui: os quatro primeiros vieram do requisito de conformidade e não mudam. O quinto foi acrescentado depois, e a regra adotada foi generalizar o vocabulário e crescer em volta do que já estava escrito, nunca substituir. Quando o nome faz parte do contrato que um terceiro vai auditar, mantê-lo estável vale mais do que a arrumação.

Concessões com prazo

Uma concessão carrega escopo, ambiente, caso de uso, o recurso a que se aplica e validade. Acesso temporário é de primeira classe, não um remendo: dar acesso por duas semanas é tão suportado quanto dar acesso permanente.

Três tipos de sujeito, e o terceiro é diferente

Uma concessão vai para uma pessoa, um time ou um agente — e nunca para mais de um ao mesmo tempo. O terceiro caso existe para o agente agir dentro de uma aplicação publicada com identidade própria, e não emprestando a de alguém.

O agente é, de propósito, um sujeito mais pobre que a pessoa:

• Não tem piso. O piso por papel de organização vale só para pessoa. Herdá-lo daria a todo agente de um dono os poderes do dono.
• Não herda concessão de time. Concessão a time se propaga aos membros do time; agente não é membro de time, então conta só o que foi concedido a ele diretamente.
• Perde o acesso sozinho quando é apagado ou muda de organização, na pergunta seguinte, sem ninguém precisar revogar nada.

Permissões nomeadas, ao lado das cinco ações

Desde 12/09/2026, existe um segundo tipo de permissão, que fica ao lado das cinco ações do edital, nunca dentro delas: uma permissão nomeada, escolhida de um catálogo e ligada a um recurso específico da plataforma. A primeira a estrear esse mecanismo controla quem enxerga o consumo de ferramentas de IA contratadas fora daqui, em dois níveis — ver e administrar.

A diferença para as cinco ações não é só de rótulo:

• Não integra o piso por papel. Nem dono nem administrador a recebem de graça só por serem quem são — só por concessão explícita.
• Só vale no escopo da organização. Concedê-la num escopo mais estreito — um ativo, um caso de uso, um ambiente — seria guardar algo que nunca teria efeito, então a gravação recusa na hora em vez de deixar uma promessa vazia no lugar.
• Não é semeada em papel de sistema. Papel de sistema não pertence a nenhuma organização, e a permissão nomeada só vale dentro de uma — semeá-la ali prometeria um acesso que nunca se concretiza.

O motivo de existir ao lado, e não dentro: a matriz de conformidade do edital é escrita contra as cinco ações por nome, e uma sexta mudaria o que já foi declarado ali.

A concessão preserva o que não foi declarado

O escopo, o ambiente, o caso de uso e o recurso dizem a que uma concessão se aplica — é o endereço dela, e não muda por gravação. O que se escreve nesse endereço são quatro partes, desde 12/09/2026 separáveis umas das outras: o papel que a concessão confere ali (distinto do papel da pessoa na organização, que é o piso de onde tudo parte), as ações do edital, as permissões nomeadas e a validade. Cada gravação substitui o conjunto inteiro — e, como agora dois caminhos diferentes escrevem a mesma concessão conhecendo só a própria metade, passou a existir diferença entre "não mexi nesta parte" e "esvaziei esta parte". O que não foi mencionado é relido do que já estava valendo e regravado, em vez de apagado.

Sem essa distinção, marcar uma permissão nomeada apagaria em silêncio o papel e as ações que a pessoa já tinha — e o contrário também.

Na tela, isso aparece assim (desde 15/09/2026): marcar só a permissão nomeada, sem escolher papel nenhum, já habilita o salvar — e quem recebe continua com o papel que tinha. As caixas das permissões nomeadas só aparecem quando a concessão é no escopo da organização, que é o único em que elas valem.

A trilha de auditoria guarda os dois lados separados: o que foi pedido e o que ficou valendo. Eles divergem justamente quando uma parte foi preservada sem ter sido mencionada, e é essa diferença que permite reconstruir depois por que alguém continuou com um acesso que ninguém pediu naquela gravação.

SSO: o portão existe, o provedor é que precisa ser ligado

A exigência de conformidade pede entrada por padrões amplamente aceitos, e a habilitação efetiva depende de fatores externos ao produto — o plano contratado no provedor de autenticação e a configuração do provedor de identidade do cliente.

O que existe hoje é a parte que cabe a nós: a política por organização — exigir entrada por provedor de identidade, e quais aceitar — e a verificação de que a sessão atual satisfaz essa política.

Dito sem rodeio, para evitar as duas leituras erradas: o portão já funciona; falta o provedor ser provisionado. Nem "já temos SSO", nem "não há nada".

O que dá para fazer, e onde