O problema de que quase ninguém fala nos agentes de IA empresariais
O seu CFO pergunta a um agente de IA: “Quanto gastámos em salários no último trimestre?”
O agente chama a API de salários. A API devolve salário, bónus e número de identificação de cada colaborador. O agente resume num total claro.
Até aqui tudo bem — o CFO pode ver esses dados.
Agora um estagiário faz a mesma pergunta ao mesmo agente. O agente chama a mesma API. A API devolve a mesma carga útil. O agente responde.
Este é o modo de falha silenciosa de quase todos os “agentes de IA empresariais” em produção hoje.
Porque o RBAC ao nível do endpoint não chega
A maioria das plataformas de integração — incluindo a nossa, até recentemente — protege o acesso à API ao nível do endpoint. Ou pode chamar GET /payroll/employees ou não. Esse modelo funcionou quando humanos construíam UIs que filtravam no cliente e os únicos chamadores eram serviços de backend fidedignos.
Os agentes quebram o modelo de duas formas:
- Os agentes são chamadores genéricos. Não sabem que campos ocultar. Resumem tudo o que recebem.
- Os agentes agem em nome de muitos utilizadores. O mesmo perfil de agente pode servir o CEO e o operador de armazém. O RBAC por endpoint não os distingue depois de autorizado o pedido.
O resultado: os agentes tornam-se um problema de “confused deputy” em escala industrial. Um utilizador sem acesso direto à base de dados pode extrair qualquer dado que o agente alcance — com a pergunta certa.
Onde o RBAC do sistema de origem fica aquém
A resposta padrão é “deixe o sistema de origem tratar disso”. Passar a identidade do utilizador ao sistema de salários. Deixar filtrar.
Funciona — quando o sistema de origem suporta. Na prática:
- Sistemas legados muitas vezes têm uma única conta de serviço com acesso total. Não há delegação por utilizador.
- APIs SaaS de terceiros frequentemente sem permissões ao nível da linha. Ou tem âmbito de administrador ou nenhum.
- APIs internas próprias foram construídas antes dos agentes de IA. Ninguém acrescentou
filter_by_user. - Agregações vazam. Mesmo com filtro de linhas, somas e médias são muitas vezes calculadas sobre o conjunto completo.
Para um CISO, a superfície de exposição de dados fica definida pelo conector mais fraco na caixa de ferramentas do agente.
Defesa em profundidade: filtragem de resposta orientada por políticas
Acrescentámos uma nova camada à Integration Platform da Copyl: DataAccessPolicy. Fica entre a resposta do sistema de origem e o agente, e aplica regras declarativas ao que é devolvido.
O modelo tem três ideias centrais:
1. As políticas ligam-se a ações de integração, não a agentes.
Um endpoint de salários tem uma política. Cada agente — cada utilizador — que o toca passa pelo mesmo avaliador. Um agente mal configurado não contorna a regra.
2. As regras correspondem ao contexto do sujeito, não ao endpoint.
O avaliador vê o sujeito completo: identidade, papéis, claims, perfil de agente, empresa. Uma regra pode dizer “se o papel incluir CEO, permitir todas as linhas” ou “se o utilizador for Employee, devolver apenas linhas em que employeeId corresponda ao seu ID.”
3. Push-down quando possível, pós-filtro como alternativa.
Se a API de origem suportar filtragem, a política reescreve o pedido — ?employeeId=42 — para que dados sensíveis não saiam do sistema de origem. Sem push-down, filtra-se no servidor antes do agente ver.
Este último ponto importa para conformidade. Filtrar no momento da consulta é genuinamente mais seguro do que depois. O pós-filtro é defesa em profundidade, não substituto dos controlos na origem.
O que isto significa para Sec/Compliance
Três propriedades tornam-no governável:
Auditável. Cada avaliação escreve um registo: que política correu, que regra correspondeu, linhas entrada/saída, campos mascarados. Pode responder “quem viu dados de salários na terça-feira e o que foi filtrado?” com SQL.
Versionado. Rascunho → publicado → arquivado. Cada alteração é uma nova versão. Diff, restauro e prova do que estava ativo numa data.
Testável antes de publicar. Dry-run — o filtro é avaliado e registado, a resposta não é alterada. Validar contra tráfego real durante semanas. Publicar exige teste aprovado ou anulação explícita.
Para setores regulados (serviços financeiros, saúde, setor público sob NIS2/DORA na Europa), “confiar no agente” passa a “provar o agente”.
O que não resolve
Limites honestos:
- A delegação no sistema de origem continua melhor quando disponível. Use primeiro. A filtragem por política é para quando não pode.
- Agregações são delicadas. Um filtro de linhas com o salário de um e um campo
total: 4.200.000sobre todos os colaboradores vaza dados. O nosso modelo deteta campos agregados e falha, remove-os ou exige opt-in explícito — exige reflexão por endpoint. - Mascarar campos não é encriptação. Números de identificação com hash continuam a ser PII. O mascaramento reduz o impacto; não elimina a obrigação.
- As políticas são tão boas quanto as regras. Correspondência errada do sujeito sobre- ou sub-permite. Por isso exigimos execuções de teste e visibilidade de auditoria.
O que isto significa na prática
Se executa agentes de IA contra sistemas sem RBAC ao nível da linha — a maioria dos ERP legados, salários, APIs próprias anteriores a 2024 — tem uma exposição que o controlo ao nível do endpoint não fecha.
A solução é estrutural, não um truque de prompts. Dizer no system prompt “mostre só os dados do utilizador” aguenta até ao próximo jailbreak. Impor na camada de integração com política versionada e auditável é algo que um CISO pode assinar.
Estamos a implementar a DataAccessPolicy nos agentes do marketplace Copyl, começando por salários, RH e finanças. Se opera em ambientes regulados e quer analisar onde está a exposição no seu stack, contacte-nos.
A Copyl é uma plataforma para construir, implementar e governar agentes de IA empresariais. A nossa Integration Platform (CIP) liga agentes a sistemas de negócio com aplicação de políticas de ponta a ponta, registo de auditoria e controlo de versões.