RBAC ou ABAC para agentes de IA: como escolher

Um papel genérico pode abrir portas demais para um agente

Uma empresa cria o papel "agente comercial" e libera acesso ao CRM. O agente precisa preparar reuniões e registrar próximas ações. A permissão do papel também permite alterar valor, mover estágio, exportar contatos e enxergar carteiras de outros vendedores.

O nome do papel parece adequado. O conjunto de ações ficou amplo porque o sistema autorizou pelo cargo e ignorou objeto, carteira, estado, horário e consequência.

RBAC e ABAC são modelos de controle de acesso. RBAC concede permissões por papéis. ABAC decide com base em atributos da identidade, da ação, do recurso e do contexto. Ambos podem participar da arquitetura de agentes, mas resolvem partes diferentes do problema.

A escolha raramente precisa ser absoluta. Papéis ajudam a administrar responsabilidades estáveis. Atributos refinam decisões que variam por cliente, ambiente, classificação, valor ou estado da tarefa. O desenho deve chegar a uma política que a empresa consiga explicar, testar, revisar e interromper.

O que RBAC controla

RBAC significa controle de acesso baseado em papéis. A empresa associa permissões a papéis e atribui esses papéis a usuários, serviços ou agentes.

Um desenho simples poderia ter:

agente_preparador_comercial: lê oportunidades e cria briefings;
agente_continuidade_comercial: lê oportunidades e cria próximas ações;
agente_suporte_n1: consulta chamados e procedimentos;
agente_financeiro_leitura: consulta lançamentos autorizados;
aprovador_comercial: aprova condições dentro da alçada registrada.

O papel resume uma responsabilidade. Ele evita configurar cada permissão do zero para cada agente e facilita revisão quando várias identidades exercem a mesma função.

Onde RBAC funciona bem

RBAC costuma ser suficiente quando:

as responsabilidades são estáveis;
o número de papéis permanece administrável;
cada papel usa um conjunto claro de operações;
a separação entre áreas resolve boa parte do acesso;
o contexto muda pouco durante a execução;
os sistemas já possuem permissões por função;
a empresa precisa começar com uma base simples.

Um agente que apenas consulta uma base interna de procedimentos pode receber um papel de leitura delimitado. Se a coleção autorizada não varia por cliente ou caso, adicionar dezenas de condições dinâmicas apenas aumenta a manutenção.

O que ABAC controla

ABAC significa controle de acesso baseado em atributos. A decisão considera fatos sobre quatro elementos.

Identidade

Quem solicita a ação: agente, usuário, serviço, área, função, cliente vinculado, nível de treinamento ou ambiente de origem.

Ação

O que será feito: ler, preparar, criar tarefa, alterar campo, enviar mensagem, exportar, aprovar, excluir ou movimentar valor.

Recurso

Qual objeto será afetado: oportunidade, contrato, documento, cliente, pagamento, chamado, sistema, campo ou classe de dado.

Contexto

Em que condição a ação ocorre: ambiente, horário, localização, valor, estado do processo, aprovação, finalidade, risco, canal ou versão da política.

Uma política ABAC poderia permitir que um agente crie uma próxima ação quando a oportunidade está ativa, pertence à carteira do usuário que iniciou a tarefa, não possui tarefa aberta equivalente e a operação acontece no ambiente de produção autorizado.

A decisão usa fatos concretos. O modelo não deveria preencher identidade, carteira ou estado por interpretação livre. Esses atributos precisam vir de fontes autorizadas.

Comparação entre RBAC e ABAC

| Critério | RBAC | ABAC | |---|---|---| | base da decisão | papel atribuído à identidade | atributos de identidade, ação, recurso e contexto | | administração | simples com poucos papéis | exige política, dados e ponto de aplicação consistentes | | granularidade | boa por função | alta por objeto e condição | | mudança durante a tarefa | limitada | pode reavaliar estado e contexto | | risco comum | papel amplo ou proliferação de papéis | regras opacas, atributos ruins e conflitos de política | | auditoria | qual papel concedeu a permissão | quais fatos e regras produziram a decisão | | melhor uso | responsabilidades estáveis | acesso que varia por cliente, dado, ação, ambiente ou estado |

RBAC responde bem a "qual responsabilidade esta identidade exerce?". ABAC responde bem a "esta ação pode ocorrer sobre este objeto, neste contexto?".

Onde RBAC começa a falhar para agentes

O papel mistura leitura e consequência

"Agente de CRM" pode incluir consulta, escrita, exportação e exclusão. O papel descreve o sistema, mas não delimita o trabalho.

Prefira papéis ligados a responsabilidades e operações. "Preparar reunião" oferece uma fronteira melhor do que "acessar CRM".

O catálogo de ferramentas para agentes de IA ajuda a quebrar um sistema em capacidades como consultar oportunidade, criar tarefa ou preparar rascunho.

O acesso varia por cliente ou carteira

Dois agentes comerciais podem usar as mesmas ferramentas e continuar restritos a conjuntos diferentes de contas. Criar um papel para cada carteira produz proliferação. Usar atributo de carteira permite manter o papel e restringir o objeto.

O estado do processo muda a autoridade

Um agente pode editar um rascunho e ficar proibido depois que a proposta foi aprovada. O papel permanece igual, mas o estado do objeto mudou.

O ambiente muda o risco

A mesma identidade pode testar escrita em homologação e operar somente leitura em produção. Criar versões de todos os papéis por ambiente funciona por um tempo, até combinações de área, cliente, dado e ambiente multiplicarem o catálogo.

A ação depende de alçada ou aprovação

Valor, desconto, classificação do dado e aprovação vigente pedem contexto. Um papel pode indicar quem possui autoridade, enquanto atributos confirmam se aquela unidade está dentro da faixa autorizada.

Onde ABAC cria problemas

ABAC permite precisão, mas cobra qualidade de arquitetura.

Atributos sem fonte confiável

Se cliente, carteira, classificacao ou aprovacao vêm de texto interpretado pelo agente, a política parece rigorosa e continua vulnerável.

Cada atributo crítico precisa de:

nome e significado;
tipo e valores permitidos;
fonte oficial;
regra de atualização;
validade;
tratamento de ausência ou conflito;
responsável pela correção.

Políticas difíceis de explicar

Dezenas de condições sobrepostas podem produzir permissões inesperadas. A decisão deve retornar regra, versão, fatos usados e motivo legível.

Conflitos entre regras

Uma política permite leitura por função. Outra bloqueia pela classificação. Uma terceira libera por aprovação emergencial. A empresa precisa definir precedência. Bloqueios objetivos de segurança costumam prevalecer sobre permissões amplas.

Dependência de um motor central

Se toda ação consulta um serviço de autorização, indisponibilidade e latência entram no processo. O comportamento de falha precisa ser definido por classe. Ações sensíveis geralmente bloqueiam. Leituras internas de baixo impacto podem usar uma política local curta e versionada, quando isso foi aprovado.

Falsa sensação de menor privilégio

Uma regra detalhada na frente de uma ferramenta administrativa continua frágil se existe outra rota que chama a mesma credencial sem política. O ponto de aplicação deve cobrir todos os caminhos equivalentes.

O modelo híbrido costuma ser o mais operável

Uma combinação prática usa RBAC para responsabilidade estável e ABAC para restrição dinâmica.

Considere um agente de continuidade comercial.

Papel

O papel continuidade_comercial permite consultar oportunidades, ler atividades, criar uma próxima ação e preparar uma mensagem. Ele não permite alterar preço, marcar negócio como ganho ou enviar comunicação externa.

Atributos

A criação da tarefa só segue quando:

a oportunidade pertence à carteira autorizada;
o negócio está ativo;
existe compromisso registrado;
a data está dentro de uma janela válida;
não há tarefa aberta equivalente;
o usuário ou processo iniciador foi identificado;
o ambiente é produção;
a política está vigente.

Consequência

Enviar a mensagem exige outra capacidade, política específica e, conforme o caso, aprovação. A separação evita que um papel de acompanhamento herde autoridade de comunicação.

O papel reduz complexidade administrativa. Os atributos preservam contexto e objeto. A ferramenta confirma o efeito no CRM.

Modele a autorização por unidade de trabalho

A pergunta "o agente pode usar o CRM?" é larga demais. Comece por uma unidade de trabalho observável.

Exemplo: criar próxima ação para uma oportunidade ativa.

Registre:

identidade humana ou evento que iniciou a tarefa;
agente e papel operacional;
ação solicitada;
oportunidade afetada;
carteira e cliente;
estado atual;
campos necessários;
restrições de duplicidade;
aprovação aplicável;
ferramenta executora;
confirmação esperada;
evidência que ficará disponível.

Esse contrato permite decidir quais controles cabem em papel, atributo, regra da ferramenta ou aprovação humana.

Separe autenticação, autorização e decisão de negócio

Os conceitos se encontram na mesma execução e não deveriam ser confundidos.

Autenticação confirma a identidade

A credencial prova qual agente, usuário ou serviço está chamando. O artigo sobre identidade e credenciais para agentes de IA cobre contas próprias, tokens curtos, rotação e revogação.

Autorização controla o acesso

RBAC e ABAC avaliam se aquela identidade pode executar a ação sobre o recurso nas condições presentes.

Decisão de negócio aplica critérios do processo

Uma proposta pode estar tecnicamente autorizada e continuar fora da política comercial. Um pagamento pode ser acessível ao agente e continuar dependente de conferência e alçada.

Parte dessas regras pode usar o mesmo motor de políticas. A empresa ainda deve distinguir o motivo da decisão, o dono e a evidência. Permissão de acesso não transfere autoridade sobre preço, contrato, pessoa ou dinheiro.

Atributos importantes para agentes de IA

Atributos da identidade

identificador do agente;
função operacional;
versão;
dono;
ambiente;
área;
cliente ou tenant permitido;
usuário delegante;
estado ativo ou suspenso.

Atributos da ação

operação solicitada;
efeito esperado;
reversibilidade;
volume;
custo estimado;
necessidade de comunicação externa;
ferramenta e versão.

Atributos do recurso

identificador oficial;
tipo;
proprietário;
cliente;
classificação de dado;
estado;
vigência;
valor;
sistema que possui autoridade.

Atributos do contexto

horário;
ambiente;
finalidade;
aprovação e validade;
canal;
risco;
sessão;
evento iniciador;
política vigente;
sinal de incidente.

Não colete atributos por completude. Cada um deve participar de uma decisão conhecida. Campo sem uso aumenta integração, exposição e chance de divergência.

O ponto de aplicação precisa impedir a ação

Uma política consultada apenas para gerar alerta não controla acesso. A decisão precisa ficar antes da consequência.

Um fluxo pode funcionar assim:

a solicitação chega com identidade autenticada;
o agente interpreta o trabalho dentro do papel recebido;
o sistema resolve recurso e atributos em fontes autorizadas;
a política avalia papel, ação, objeto e contexto;
a decisão permite, reduz, encaminha ou bloqueia;
a ferramenta recebe somente o comando autorizado;
o destino confirma o efeito;
política, ação e resultado compartilham o mesmo identificador.

A policy as code para agentes de IA oferece uma forma de versionar, testar e auditar essa decisão fora do modelo.

Reavalie acesso durante tarefas longas

Um agente pode iniciar a execução com permissão válida e continuar trabalhando depois que o contexto mudou. A pessoa perde acesso, o contrato vence, o incidente suspende escritas ou o caso muda de responsável.

Não dependa somente da autorização obtida no início. Reavalie antes de ações materiais, depois de pausas, na retomada de checkpoints e quando a execução atravessar uma nova fronteira de dado ou sistema.

Credenciais curtas reduzem a janela, mas não substituem a verificação de contexto. Um token ainda válido pode carregar uma autoridade que o processo já revogou.

O guia de Zero Trust para agentes de IA aprofunda verificação contínua por identidade, ação, objeto e efeito.

Teste políticas sem depender do comportamento do modelo

A primeira bateria deve chamar o componente de autorização com fatos controlados.

Inclua casos como:

papel correto e objeto permitido;
papel correto e carteira errada;
papel ausente;
ação fora do papel;
recurso sem proprietário;
dado acima da classificação permitida;
aprovação ausente, expirada ou usada em outro objeto;
ambiente incorreto;
estado alterado desde a leitura;
agente suspenso;
usuário delegante sem autoridade;
regra em conflito;
atributo ausente;
serviço de política indisponível;
tentativa por uma rota antiga.

Depois teste o fluxo completo. O agente pode escolher outra ferramenta, enviar identificador incorreto ou tentar concluir por um conector genérico. O critério final é simples: a consequência proibida chegou ao destino?

Migre sem interromper a operação

1. Inventarie acessos atuais

Liste agentes, identidades, papéis, ferramentas, credenciais, objetos e donos. Marque contas compartilhadas e permissões administrativas.

2. Quebre papéis por responsabilidade

Separe consulta, preparação, registro reversível, comunicação e transação sensível. Evite reproduzir o organograma inteiro quando a responsabilidade operacional pede outro recorte.

3. Identifique condições dinâmicas

Procure decisões que variam por cliente, carteira, ambiente, estado, classificação, valor, horário ou aprovação. Essas condições são candidatas a atributos.

4. Defina fontes dos atributos

Não implemente regra antes de saber de onde cada fato vem e como será atualizado.

5. Rode a política em sombra

Compare a decisão candidata com o fluxo atual sem bloquear ações. Classifique divergências e corrija regra, dado ou processo.

6. Aplique primeiro em ações estreitas

Comece por uma operação com baixo impacto ou por um bloqueio objetivo conhecido. Observe falsos bloqueios, ausência de atributo, latência e bypass.

7. Reduza permissões antigas

Depois que a nova rota foi validada, remova papéis amplos, conectores genéricos e credenciais que permitam contornar a política.

8. Institua revisão periódica

Cruze papéis atribuídos, atributos vigentes, uso real, negações, exceções e agentes desativados. Acesso sem função, dono ou atividade deve ser retirado.

Métricas que revelam a qualidade da autorização

Acompanhe:

decisões por papel, ação e política;
permissões e negações;
redução de escopo;
pedidos de aprovação;
atributos ausentes ou conflitantes;
falsos bloqueios;
ações indevidas que passaram;
tentativas por objeto ou cliente errado;
papéis sem uso;
papéis com permissões administrativas;
agentes com combinações incomuns de papéis;
latência e indisponibilidade da política;
rotas sem evento de autorização;
decisões sem confirmação de efeito;
tempo para revogar um agente;
exceções vencidas.

Muitas negações podem indicar proteção ativa ou um processo mal modelado. Poucas negações podem indicar entrada melhor ou ausência de cobertura. Compare decisões com volume, casos de teste e efeitos reais.

Erros comuns

Criar um papel por combinação

Papéis por área, cliente, ambiente, projeto e nível de dado multiplicam rapidamente. Use papel para responsabilidade estável e atributo para variação contextual.

Transformar todo campo em atributo

Uma política com dezenas de fatos difíceis de manter produz falhas por ausência e divergência. Comece pelas condições que realmente mudam a decisão.

Pedir ao modelo que decida o acesso

O modelo pode reunir contexto e propor uma ação. A autorização precisa ocorrer num componente capaz de aplicar regras e impedir a chamada.

Manter credencial ampla atrás da política

Se a ferramenta executa com conta administrativa, qualquer bypass amplia o dano. Reduza também a permissão no sistema de destino.

Ignorar o objeto

Autorizar a ação sem confirmar cliente, conta, contrato ou ambiente permite que um agente correto opere sobre o alvo errado.

Conceder exceção sem validade

Acesso emergencial deve ter escopo, objeto, motivo, aprovador e expiração. Exceção permanente vira outra política, só que menos visível.

Checklist de escolha

As responsabilidades estáveis podem ser representadas por poucos papéis?
Cada papel descreve um trabalho ou apenas um sistema inteiro?
Leitura, preparação, escrita e transação estão separadas?
O acesso varia por cliente, carteira, ambiente, dado ou estado?
Atributos críticos possuem fonte oficial e validade?
A política distingue identidade, ação, recurso e contexto?
Bloqueios prevalecem sobre permissões amplas quando necessário?
A decisão retorna regra, versão e motivo?
O ponto de aplicação fica antes da ferramenta?
O sistema de destino também aplica menor privilégio?
Tarefas longas reavaliam autorização antes de novas consequências?
Exceções possuem aprovador, escopo e expiração?
Testes cobrem ausência, conflito, bypass e indisponibilidade?
A empresa consegue revogar um agente sem afetar os demais?
Existe revisão de papéis, atributos e uso real?

Use papéis para organizar e atributos para limitar

RBAC oferece uma base legível para responsabilidades estáveis. ABAC refina decisões que dependem do objeto e do contexto. A combinação tende a funcionar bem quando os papéis permanecem poucos, os atributos vêm de fontes confiáveis e a política fica no caminho técnico da ação.

Comece por uma unidade de trabalho, não pelo acesso ao sistema inteiro. Defina quem age, qual operação pode executar, sobre qual objeto, em que condição e com qual evidência. Esse recorte reduz permissões amplas sem transformar a autorização num labirinto que ninguém consegue manter.