Governança de acesso a IA
Governança de acesso a IA é controlar quem — pessoa ou agente — pode usar quais modelos e dados, com credenciais que nunca ficam expostas e trilha de auditoria de cada uso. Este guia detalha os quatro mecanismos: acesso por papel em vez de chave solta, isolamento por organização, credenciais guardadas num cofre com escrita protegida por segundo fator e a trilha que responde "quem fez o quê".
Acesso por papel
Acesso por papel é dar a cada pessoa ou agente um perfil com permissões definidas — não uma chave de API solta que abre tudo igual.
Quando o acesso à IA é uma chave de API espalhada pelo código ou pelas variáveis de ambiente, todo mundo alcança qualquer coisa com a mesma credencial: não há diferença entre quem deveria provisionar a plataforma e quem só deveria consultar o próprio uso. Pior, quando essa chave vaza, vaza tudo de uma vez, e não há como dizer quem fez o quê depois. O acesso por papel inverte isso: cada pessoa ou agente opera sob um perfil cujas permissões são escopadas ao que aquele perfil precisa, nada além. O que pode ser feito deixa de ser uma propriedade da chave e passa a ser uma propriedade de quem está agindo.
Na prática isso se organiza em poucos papéis claros. Um papel de plataforma alcança a configuração que atravessa as organizações — chaves de provedor, catálogo. Um papel de administração governa uma organização: centros de custo, gasto, aprovação de modelos, sempre filtrados pela própria organização. E um papel de uso comum fica restrito ao autosserviço, vendo apenas o que lhe diz respeito. Três níveis bastam para que cada ação chegue à pessoa certa sem dar a ninguém mais alcance do que a função exige.
Na Horse Labs, o controle de acesso é RBAC com três papéis: operator (plataforma, abrange organizações), admin (uma organização) e member/viewer (autosserviço) — cada um com permissões escopadas à própria função.
Isolamento por organização
Isolamento por organização é garantir que o dado de um cliente nunca seja alcançável pelo contexto de outro — tudo é filtrado pela organização de quem está agindo.
Numa operação que atende vários clientes sobre a mesma infraestrutura, o risco mais grave não é alguém ver o que não devia dentro da própria organização — é o dado de um cliente vazar para outro. Sem uma fronteira, um pedido feito sob um contrato pode, por descuido de filtro, devolver informação de um contrato vizinho, e esse tipo de vazamento é difícil de notar e impossível de desfazer. O isolamento por organização fecha essa fronteira tornando-a parte de cada consulta: gasto, requisições, centros de custo, segredos — tudo carrega a organização de quem está agindo e é filtrado por ela antes de qualquer resposta.
O ponto importante é que essa fronteira não pode depender de o desenvolvedor lembrar de aplicá-la a cada consulta; ela precisa estar embutida na camada de acesso e ser verificada de forma automática. Uma tentativa de alcançar dado de outra organização não retorna parcialmente — é recusada. E como esse comportamento é uma promessa de segurança, ele tem que ser provado, não presumido: o isolamento é coberto por testes de integração que exercitam justamente o cruzamento de fronteira e confirmam que ele é barrado.
Na Horse Labs, tudo é escopado por organização e o isolamento entre organizações é validado por testes de integração — o dado de um cliente fica isolado do de outro.
Credenciais no cofre
Credenciais de provedor vivem num cofre de segredos, entregues aos serviços sob demanda e nunca embutidas nos agentes ou modelos — e escrever um segredo exige um segundo fator.
A credencial mais perigosa de uma operação de IA é a chave do provedor, porque ela vale dinheiro e abre o modelo para quem a tiver. Deixá-la dentro do código, num arquivo de configuração ou embutida no próprio agente é convidar o vazamento: basta um repositório exposto, um log descuidado, uma imagem de container publicada. A alternativa estrutural é guardar essas chaves num cofre de segredos e entregá-las aos serviços apenas no momento de usar, sob uma identidade própria — o serviço autentica no cofre e recebe o segredo, em vez de carregá-lo consigo. Assim a chave nunca mora no artefato que a consome, e quem inspeciona o código ou o agente não encontra credencial nenhuma.
Guardar bem não basta se qualquer um pode reescrever o segredo. Por isso a escrita é tratada como uma ação privilegiada: alterar uma credencial exige uma elevação momentânea com segundo fator (2FA por TOTP), de modo que nem mesmo uma sessão já autenticada modifica um segredo sem confirmar de novo, ali, quem está agindo. Leitura pelos serviços é rotina automática; escrita é exceção deliberada e protegida. A separação entre as duas é o que mantém o cofre confiável.
Na Horse Labs, as credenciais de provedor ficam no HashiCorp Vault, entregues aos serviços via AppRole e nunca embutidas nos agentes, com a escrita de qualquer segredo protegida por 2FA (TOTP).
Trilha de auditoria
Trilha de auditoria é o registro de cada ação sensível — a base para responder "quem fez o quê" sem precisar reconstruir nada depois.
Controlar quem alcança o quê reduz o risco, mas não elimina a pergunta que vem depois de qualquer incidente ou auditoria: quem, exatamente, fez aquela ação, e quando? Se a resposta depende de reconstruir o passado a partir de logs dispersos e memória das pessoas, ela chega tarde, incompleta e contestável. A trilha de auditoria existe para que essa resposta já esteja pronta: cada ação sensível — revelar um segredo, aprovar um modelo, alterar uma configuração de governança — é registrada no momento em que acontece, com o autor e o contexto, num registro que serve de fonte única.
Esse registro é o que transforma governança de acesso numa promessa verificável em vez de uma intenção. Sem ele, todo o resto — papéis, isolamento, cofre — fica sem prestação de contas: você teria os controles, mas não a evidência de que funcionaram. Com a trilha, cada uso sensível deixa rastro auditável, e responder a uma investigação, a um cliente ou a um requisito de conformidade vira uma consulta, não uma escavação. É a camada que fecha o ciclo: define-se o acesso, impõe-se o acesso e registra-se o acesso.
Na Horse Labs, cada ação sensível fica na trilha de auditoria — revelar um segredo, aprovar um modelo, alterar governança — de modo que "quem fez o quê" é uma consulta, não uma reconstrução.
FAQ
O que é governança de acesso a IA?
É o conjunto de controles que define quem — pessoa ou agente — pode usar quais modelos e dados, com acesso por papel, isolamento por organização, credenciais guardadas num cofre e trilha de auditoria de cada uso, tudo na camada de infraestrutura.
Como impedir que o dado de um cliente vaze para outro?
Escopando tudo por organização e filtrando cada consulta por ela, de forma embutida na camada de acesso — uma fronteira coberta por testes de integração que confirmam que o cruzamento entre organizações é barrado.