RBAC vs ABAC: Escolhendo um Modelo de Controle de Acesso para Agentes de IA

O que o RBAC realmente é

O controle de acesso baseado em papéis (RBAC - Role-Based Access Control) coloca uma camada nomeada entre pessoas e permissões. Você não concede a Priya a capacidade de ler um secret group. Você define um papel chamado Secret Group Viewer contendo essa permissão e atribui Priya a ele.

Três elementos compõem o modelo de controle de acesso baseado em papéis:

O valor está na indireção. Quando a equipe de segurança decide que os leitores não devem mais visualizar valores secretos, eles editam um único papel e todos os leitores são atualizados de uma só vez. O NIST formalizou este modelo há décadas, razão pela qual todo console de nuvem possui uma página de papéis (roles).

A fraqueza também está na indireção. Os papéis são conjuntos estáticos. Se uma permissão deve ser aplicada apenas a partir de um IP corporativo, ou apenas a registros na própria região do solicitante, o RBAC simples não consegue expressar isso. As equipes respondem criando mais papéis: analyst-eu, analyst-eu-readonly, analyst-eu-readonly-prod. Isso é a explosão de papéis (role explosion), a razão mais citada para as pessoas buscarem o ABAC.

O que o ABAC realmente é

O controle de acesso baseado em atributos (ABAC - Attribute-Based Access Control) remove o conjunto nomeado. Em vez de perguntar qual papel um sujeito possui, ele avalia uma expressão de política no momento da requisição considerando quatro categorias de atributos:

Uma política lê algo como: permitir leitura quando subject.department == resource.owning_team e resource.classification != "restricted" e env.network == "corp". O NIST SP 800-162 é a documentação canônica; na prática, o ABAC é disponibilizado como uma linguagem de política como XACML, Rego ou Cedar por trás de um serviço de autorização.

O ABAC é genuinamente mais expressivo. Uma única regra bem escrita pode substituir uma centena de papéis e lida com relações que o RBAC não consegue declarar de forma alguma: “o médico atribuído a este paciente”.

Essa expressividade tem um custo. Políticas são código: elas precisam de revisão, testes, versionamento e uma maneira de entender como as regras interagem. E a pergunta que um auditor faz primeiro — quem pode ler estes dados? — deixa de ter uma resposta de consulta direta. Você precisa enumerar cada sujeito e avaliar a política em relação a cada um. Por essa razão, alguns motores oferecem ferramentas de consulta reversa; a maioria das implantações não as utiliza.

Diferenças entre RBAC e ABAC em síntese

Uma coisa que a tabela esconde: o ABAC tem um pré-requisito, atributos confiáveis. Uma política baseada em resource.data_region é tão boa quanto a disciplina de marcação de tags que preenche esse campo. A maioria das organizações que tenta usar ABAC descobre que tem um problema de dados não etiquetados antes de ter um problema de autorização. E os dois modelos não são exclusivos — a estrutura comum em produção é o RBAC como espinha dorsal com algumas condições de atributo por cima.

Onde as equipes erram nisso

Tratar a explosão de papéis como motivo para mudar de modelo. A explosão de papéis geralmente é um erro de escopo, não uma falha do modelo. Se você tem analyst-team-a, analyst-team-b e analyst-team-c, você não precisa de atributos — você precisa de um papel analyst vinculado separadamente aos recursos de cada equipe. A maior parte da dor atribuída ao RBAC vem de conceder permissões em todo o tenant quando a vinculação deveria pertencer a um único recurso.

Comprar expressividade que você não pode auditar. O ABAC permite escrever uma regra que sua equipe de conformidade não consegue ler. Essa troca às vezes vale a pena, mas nunca por acidente. Antes de adotar um motor de políticas, pergunte quem responderá ao questionário de revisão de acesso no próximo trimestre e como.

Esquecer que as concessões se somam. Um sujeito pode ter acesso diretamente e herdá-lo por meio de uma equipe, e remover um não remove o outro. Fica pior quando um motor de políticas é adicionado por cima, porque dois sistemas podem conceder acessos de forma independente.

Definir permissões para o humano e ignorar o agente. Todo controle do lado humano é decorativo se o agente que eles criaram for executado com um token de serviço compartilhado com acesso a todo o tenant.

Quer ver o acesso com escopo definido na prática?

Inicie o TrueFoundry e conceda um papel em um único recurso em vez de todo o tenant — leva cerca de dois minutos.

Comece gratuitamente

Por que agentes de IA parecem o cenário perfeito para o ABAC

Um agente de IA é um sujeito não humano cuja autoridade efetiva não é fixa. Ele pode ler um repositório público em um momento e acessar um registro de cliente no momento seguinte. Ele atua para diferentes pessoas em momentos diferentes. Suas entradas podem ser adversariais — o corpo de uma issue envenenada pode direcioná-lo a uma ferramenta que ele não deveria chamar. E, ao contrário de um humano, ele não pausa para refletir se uma ação é sensata.

Escreva isso como um requisito e parecerá exatamente um resumo de ABAC: permitir esta chamada de ferramenta quando o usuário solicitante tiver acesso upstream ao destino, a ferramenta não for destrutiva e a requisição não tiver origem em conteúdo não confiável. Três atributos, uma regra. Então, por que quase nada é implementado dessa forma?

Porque os atributos não estão disponíveis de forma confiável no momento da decisão. “Esta requisição originou-se de conteúdo não confiável” não é um campo, é um problema de pesquisa. “O usuário solicitante tem acesso upstream” é passível de conhecimento — mas a maneira correta e mais barata de saber é chamar o sistema upstream com as próprias credenciais desse usuário e deixar que ele responda, em vez de espelhar seu modelo de permissão em seu motor de políticas e torcer para que a cópia permaneça atualizada.

O custo de auditabilidade também é mais pesado exatamente onde os agentes operam. Permissões de agentes são o que a revisão de segurança mais questiona, e “a política é avaliada como permitida sob estas condições” é uma resposta muito pior do que uma tabela dizendo que este agente possui MCP Server User nestes três servidores.

Portanto: agentes precisam de acesso mais restrito do que humanos e mais inspecionável do que humanos. O ABAC entrega o primeiro e prejudica o segundo. Daí o padrão de implementação — RBAC com escopo rígido de recursos, acrescido de algumas poucas restrições contextuais onde o contexto realmente importa.

Como isso funciona no TrueFoundry

O TrueFoundry implementa RBAC com vinculações de papéis com escopo de recurso (resource-scoped role bindings). Não é um motor de políticas ABAC, e é importante ser claro quanto a isso. O modelo responde a uma pergunta: quem pode fazer o quê, e onde?

• Um sujeito (subject) é a identidade que recebe acesso: um usuário, equipe, conta virtual ou agente.
• Um recurso (resource) é o item que está sendo acessado: uma conta de provedor de modelo, servidor MCP, agente, cluster, workspace, repositório ou secret group.
• Um papel (role) é um conjunto nomeado de ações permitidas.

Atribuir um papel a um sujeito para um recurso cria uma role binding. O acesso é gerenciado de forma independente da configuração do recurso, portanto você pode alterar quem tem acesso sem reimplantar nada.

As concessões são feitas a partir do próprio recurso — abra o menu de três pontos e selecione Access Control:

Em seguida, escolha um ou mais sujeitos e um papel. O painel lista as ações que cada papel inclui, para que você veja o que está concedendo antes de fazê-lo:

Os papéis oferecidos dependem do tipo de recurso: Manager e User em uma conta de provedor de modelo; MCP Server Manager, MCP Server User e MCP Server Approver em um servidor MCP; Agent Manager e Agent Access em um agente. Clusters, workspaces e secret groups têm, cada um, suas próprias camadas de admin, member e viewer.

Três escopos, não apenas um

Os papéis operam em três escopos, e mantê-los bem compreendidos é grande parte do segredo:

Admin e Read-Only Member não podem ser editados. Member pode — a linha de base que cada usuário recebe, que por padrão inclui apenas cluster:ReadCluster, environment:ListEnvironments, settings:ListSettings, user:ListUsers, repository:CreateRepository, secret-group:CreateSecretGroup e agent:CreateAgent. Ele não alcança nenhum modelo individual, servidor MCP ou workspace — esses vêm de vinculações de recursos ou de associação a equipes.

Os papéis de equipe são o mais próximo de uma condição de atributo aqui, e a semelhança é instrutiva. O Team Member carrega virtual-account:ReadVirtualAccount, com escopo para Contas Virtuais pertencentes a equipes às quais o usuário realmente pertence. A permissão é idêntica para todos; o conjunto de objetos que ela alcança difere por pessoa.

Isso é escopo por propriedade (ownership scoping), não ABAC: sem expressão de política, sem avaliação de atributo, apenas uma relação fixa entre uma equipe e o que ela possui. Ele cobre o caso comum que leva as pessoas em direção aos atributos e permanece legível.

Papéis customizados para permissões refinadas

Quando os papéis nativos do tenant forem muito amplos ou muito restritos, crie o seu próprio a partir do catálogo de permissões. Cada permissão segue a estrutura resource:Action, agrupada por tipo de recurso:

Uma regra governa quando usar isso: as permissões de papéis customizados aplicam-se a todos os recursos do tipo selecionado. Um papel customizado com mcp-server:ReadMcpServer alcança todos os servidores MCP, não apenas alguns escolhidos. Para um único recurso, use a página Access Control desse recurso. Inverter isso é como um papel destinado a um único servidor se torna silenciosamente um acesso de leitura a todo o tenant.

As restrições contextuais, nomeadas com precisão

O TrueFoundry adiciona sensibilidade ao contexto em quatro lugares. Nenhum deles é uma política de atributos, e cada um é inspecionável:

O segundo item faz a maior parte do trabalho que as pessoas esperam do ABAC. Quando um agente chama uma ferramenta para um usuário específico via per-user OAuth, o serviço upstream avalia as permissões reais desse usuário. Você não modelou as ACLs de repositório do GitHub em um motor de políticas; você delegou ao sistema que as possui, e essa cópia não fica desatualizada. O modelo de controle de acesso MCP é construído diretamente sobre isso.

Um limite: tokens de Conta Virtual fornecem a cada requisição acesso idêntico. Eles são adequados para chamadas serviço-a-serviço e inadequados onde permissões por usuário importam.

Um exemplo prático, de duas maneiras

Dois cenários reais da documentação mostram o modelo funcionando a partir de direções opostas.

Dar a um auditor acesso somente leitura. Atribua Read-Only Member em Access > Users. É um papel nativo do tenant, fornece acesso somente leitura entre os tipos de recursos suportados e não pode ser editado — o que é o ponto principal, pois um papel de auditoria que pode ser silenciosamente ampliado não é um papel de auditoria. Para um grupo de auditores, atribua-o a uma equipe para que novos integrantes o herdem. Se o auditor deve ver apenas recursos selecionados, ignore o papel de tenant completamente e conceda o papel de viewer ou access em cada recurso.

Permitir que as pessoas criem servidores MCP sem torná-las Admin. O instinto é conceder Admin, porque criar um servidor precisa de uma permissão que o Member não possui. Em vez disso, crie um papel customizado contendo exatamente mcp-server:CreateMcpServer:

Em seguida, atribua-o em Access > Users ou Access > Teams:

O comportamento é a parte interessante. Create MCP Server permite que alguém crie um novo servidor. Ele não concede acesso aos servidores existentes. Após criar um servidor, o proprietário concede a si mesmo MCP Server Manager a partir da própria página Access Control desse servidor.

A autoridade de criação e a autoridade de acesso são separadas, e nenhuma vaza para a outra. Uma política ABAC poderia expressar a mesma coisa em uma regra que você teria que ler com atenção para ter certeza. Aqui são duas linhas em duas tabelas. O padrão também se adapta para casos menores: para permitir que todos vejam os controles do gateway sem serem Admin, edite Member e adicione gateway-controls:ListGatewayControls.

Defina o escopo do seu primeiro agente no TrueFoundry

Gratuito para começar