Em resumo
Um agente de IA que apoia o time jurídico consulta o drive, a gestão de contratos e o e-mail. Entre os documentos que ele alcança estão contratos sob cláusula de sigilo, abertos apenas aos advogados de cada caso. Se o agente responde a qualquer pessoa do departamento com tudo o que consegue ler, a cláusula perde efeito. O controle de acesso é o conjunto de regras que define quem pode ver ou alterar cada dado. Com agentes, ele precisa acompanhar cada consulta, e é uma das funções do Company Brain, a camada que conhece a empresa: quais dados existem, onde vivem, como se relacionam e quem pode ver o quê.
Todo sistema corporativo responde a três perguntas antes de exibir um registro: quem está pedindo, o que essa identidade pode fazer e sobre quais registros. A autenticação resolve a primeira. O controle de acesso resolve as outras duas, com regras de leitura, alteração e exclusão. Três modelos são os mais usados:
O controle de acesso de um HRIS costuma combinar os três. O papel de gestor libera o módulo de desempenho, o atributo de unidade restringe a filial e a regra por linha mostra só os liderados diretos.
Nos sistemas tradicionais, a pessoa abre a tela e o sistema aplica a regra. Com um agente, surge um intermediário que recebe a pergunta, consulta vários sistemas e monta uma resposta única. Ele age em nome de alguém, e cada sistema consultado precisa saber em nome de quem.
A resposta também mistura fontes com regras diferentes. Uma pergunta sobre um colaborador pode reunir HRIS, folha e chamados internos. Se uma fonte libera mais do que deveria, o excesso entra na resposta junto com o restante.
O modelo de linguagem não aplica permissão por conta própria. Uma instrução no prompt para omitir dados restritos depende da continuação mais provável e pode ser contornada por uma pergunta bem formulada. O controle de acesso precisa acontecer antes, na consulta às fontes.
A edição de 2025 da lista da OWASP para aplicações de LLM trata parte desses riscos como agência excessiva e recomenda executar as ações tomadas em nome de um usuário no contexto desse usuário, com o mínimo de privilégio necessário.
O Company Brain conecta ERP, HRIS, gestão de contratos e documentos uma vez e organiza esses dados em um grafo de conhecimento. A permissão vem junto. Cada consulta carrega a identidade de quem perguntou, e cada fonte devolve o recorte que essa pessoa já vê no próprio sistema.
Não há controle paralelo para manter. Em uma operação de M&A, os documentos do projeto confidencial ficam restritos ao grupo do projeto no repositório. O agente de FP&A recebe apenas o que a analista que perguntou já pode abrir, e quando alguém sai do grupo, a mudança na origem vale para todos os agentes.
O contexto é servido ao modelo via MCP, já filtrado, e cada resposta cita o sistema e o registro de origem. A segurança consegue reconstruir quem perguntou, quais fontes foram lidas e com qual permissão.
A LGPD limita o tratamento ao mínimo exigido pela finalidade e exige medidas contra acessos não autorizados. Um agente que lê prontuários de toda a base para responder sobre um paciente contraria os dois princípios. O controle de acesso por registro, aplicado antes do modelo, e o registro de cada consulta são a evidência de como a empresa trata esses dados.
A herança vale o que vale a permissão de origem. Sistemas legados com perfis grosseiros, em que todo o financeiro enxerga tudo, exigem uma regra adicional, definida com a área dona do dado.
Herdar também significa herdar erros. A revisão periódica de acessos continua necessária e ganha peso, porque o agente torna qualquer acesso mais fácil de exercer.
Um bom ponto de partida é um caso em que o acesso já é bem definido na origem, como contratos sob sigilo no jurídico. Antes de conectar o agente, convém mapear quais sistemas ele consulta, com quais credenciais e se a identidade de quem pergunta chega a cada fonte. Com esse mapa, o controle de acesso do primeiro agente se apoia na permissão herdada, e os casos seguintes reaproveitam as mesmas conexões e regras.