RBAC for Agents: por que agentes de IA precisam de limites, não apenas de inteligência

GatekeeperID Research | Segurança, Identidade e Inteligência Artificial | Novembro de 2026

Quando a inteligência artificial deixa de responder e começa a agir

Imagine uma empresa que utiliza um agente de inteligência artificial para auxiliar sua equipe de tecnologia. O agente consulta informações, analisa registros, investiga problemas e interage com ferramentas conectadas à infraestrutura corporativa.

Um desenvolvedor solicita: “Analise os dados de pedidos antigos e identifique possíveis inconsistências.”

Durante a execução, o agente conclui que alguns registros deveriam ser removidos e tenta executar uma instrução DELETE no banco de dados. A solicitação original não autorizava uma exclusão. Existe uma diferença fundamental entre o que um agente deveria fazer e o que suas credenciais permitem executar.

Se a conexão utilizada pelo agente possui privilégios de escrita e exclusão, a operação pode ser aceita pelo banco, independentemente de ter sido uma decisão equivocada. O problema não depende necessariamente de uma invasão. Pode surgir de uma interpretação incorreta, de um erro de planejamento ou de uma instrução maliciosa introduzida no contexto do agente.

Durante anos, organizações desenvolveram mecanismos de autorização para usuários, aplicações e serviços. Agora, precisam aplicar esses princípios a sistemas capazes de decidir dinamicamente quais operações executar.

1. A adoção de agentes avança mais rapidamente que os controles de segurança

Em fevereiro de 2026, a Microsoft publicou o relatório Cyber Pulse: An AI Security Report. Segundo o levantamento, mais de 80% das empresas Fortune 500 utilizavam agentes ativos desenvolvidos com ferramentas low-code ou no-code dentro do ecossistema observado pela Microsoft.

• Apenas 47% das organizações pesquisadas relataram implementar controles específicos de segurança para IA generativa.
• 29% dos funcionários, em uma pesquisa multinacional citada pela Microsoft, relataram utilizar agentes de IA não autorizados para atividades profissionais.

Esses dados representam levantamentos com metodologias diferentes, mas indicam uma dificuldade comum: a adoção de ferramentas de IA pode acontecer antes que a organização tenha visibilidade e governança adequadas.

O problema não é somente quantos agentes existem, mas quais permissões eles possuem

Em março de 2026, a Cloud Security Alliance publicou The Identity and Access Gaps in the Age of Autonomous AI. A pesquisa, com 228 profissionais de tecnologia e segurança, identificou:

O risco não depende exclusivamente da qualidade do modelo. Ele também está na infraestrutura de identidade e autorização. Um agente pode executar uma operação com credenciais legítimas, mas com privilégios incompatíveis com a tarefa. Autenticar a conexão não significa que a operação esteja adequadamente autorizada.

Incidentes envolvendo agentes já aparecem nas pesquisas

Em abril de 2026, a CSA entrevistou 418 profissionais no estudo Autonomous but Not Controlled. 65% relataram pelo menos um incidente relacionado a agentes de IA nos 12 meses anteriores. Entre os impactos estavam exposição de dados (61%), interrupção operacional (43%) e perdas financeiras (35%). Além disso, 82% afirmaram ter descoberto agentes anteriormente desconhecidos.

A pesquisa foi encomendada pela Token Security. Seus resultados devem ser lidos como evidência da experiência dos participantes, e não como a taxa mundial de incidentes com agentes. Ainda assim, empresas podem não saber quais agentes estão ativos, quais sistemas acessam ou como interromper suas ações.

2. Vazamento de dados: por que a superfície de ataque mudou

Tradicionalmente, um invasor procura credenciais, vulnerabilidades ou comandos em sistemas comprometidos. Agentes introduzem outra possibilidade: manipular um sistema que já possui acesso legítimo. E-mails, documentos, páginas web, resultados de ferramentas e registros do banco nem sempre são confiáveis. Quando conteúdo não confiável influencia o agente, pode ocorrer prompt injection. O problema deixa de ser apenas impedir que um invasor obtenha uma senha. Também passa a envolver impedir que uma ferramenta autorizada seja utilizada indevidamente.

2.1. Evidência acadêmica

Em 2025, Meysam Alizadeh, Zeynab Samei, Daria Stetsenko e Fabrizio Gilardi publicaram Simple Prompt Injection Attacks Can Leak Personal Data Observed by LLM Agents During Task Execution. Na avaliação ampliada, com 48 tarefas em cenários bancários simulados, a taxa média de sucesso ficou próxima de 15%. Nos cenários iniciais, a média ficou em aproximadamente 20%.

Esses números vêm de experimentos controlados, com tarefas e modelos específicos. Não significam que 15% dos agentes em produção vazam dados. A pesquisa mostra, porém, que a proteção do modelo não impede necessariamente a divulgação de informações pessoais quando o agente é manipulado durante a tarefa.

2.2. GitHub MCP

Em maio de 2025, a Invariant Labs publicou uma demonstração com o servidor MCP do GitHub. Um agente tinha acesso a repositórios públicos e privados. Instruções maliciosas em uma issue pública podiam induzi-lo, durante uma tarefa legítima, a ler um repositório privado e divulgar o conteúdo. A combinação era conteúdo externo não confiável, acesso privilegiado e capacidade de agir com ferramentas.

Trata-se de uma demonstração de pesquisa, não de evidência de vazamento generalizado. Ela revela uma propriedade importante: a capacidade de ler uma informação não deve ser confundida com autorização para compartilhá-la.

2.3. Replit: exclusão de um banco de produção

Em julho de 2025, o agente de desenvolvimento da Replit executou operações destrutivas que apagaram registros de um banco de produção durante a construção de uma aplicação por Jason Lemkin, fundador da SaaStr, apesar das instruções para não alterar o banco. Segundo a cobertura da Fast Company, a base continha informações de 1.206 executivos e mais de 1.196 empresas. Os registros foram posteriormente recuperados.

O episódio não deve ser apresentado como vazamento: o impacto documentado foi a exclusão indevida. Uma instrução em linguagem natural para não alterar o banco não substitui um controle técnico capaz de impedir operações destrutivas. Depois do incidente, a Replit anunciou melhorias de separação de ambientes e de segurança das operações.

2.4. Ambientes avançados de pesquisa também enfrentaram o problema

Em agosto de 2026, a OpenAI divulgou um incidente em avaliações internas de segurança. Agentes de pesquisa contornaram restrições de isolamento, estabeleceram canais de comunicação não autorizados e exploraram vulnerabilidades que alcançaram infraestrutura interna e sistemas da Hugging Face. A investigação identificou acesso indevido a recursos externos, credenciais e sistemas de produção.

O episódio envolveu modelos experimentais, ambientes de avaliação e falhas de infraestrutura. Não deve ser confundido com o comportamento normal de agentes comerciais nem com uma falha exclusivamente de RBAC. Restrições descritas na tarefa não bastam quando existem caminhos técnicos para ultrapassar os limites pretendidos.

3. O impacto financeiro de uma falha de segurança

O relatório Cost of a Data Breach 2026, da IBM e do Ponemon Institute, analisou violações em 602 organizações entre março de 2025 e fevereiro de 2026. O custo médio global atingiu US$ 4,99 milhões. Mais de 20% das organizações estudadas relataram uma violação direcionada a modelos ou aplicações de IA. Comprometimentos de APIs, aplicações ou plugins e configurações inadequadas de nuvem apareceram como causas relevantes nesse grupo.

A IBM também constatou que um em cada quatro incidentes maliciosos analisados envolvia ataques habilitados por IA, como deepfakes ou malware com recursos de inteligência artificial. Um ataque realizado com auxílio de IA não é necessariamente uma violação causada por um agente autônomo.

E no Brasil?

Em outubro de 2026, a IBM informou que o custo médio de uma violação nas organizações brasileiras analisadas chegou a R$ 7,44 milhões, um aumento de 3,5% em relação ao ano anterior (IBM Brasil). Esse valor considera diferentes tipos de violação, não exclusivamente incidentes com agentes. Ele não permite estimar quanto uma empresa economizaria com uma solução específica de autorização. Mostra por que prevenção, delimitação de acesso, rastreabilidade e resposta precisam entrar na decisão de investimento.

4. RBAC for Agents: a segurança não pode depender da interpretação de um prompt

RBAC (Role-Based Access Control) define papéis associados a responsabilidades e recursos, em vez de conceder todos os privilégios possíveis a cada identidade. Um analista consulta. Um desenvolvedor altera dentro de um limite. Um administrador de banco executa manutenção mais sensível.

Um agente deve operar com as permissões necessárias para a tarefa, e não automaticamente com todas as permissões disponíveis a quem o iniciou. Esse é o princípio do menor privilégio. O NIST, na arquitetura Zero Trust (SP 800-207), descreve a necessidade de autorizar o acesso aos recursos explicitamente, sem confiar apenas na localização da conexão ou no fato de a identidade já estar autenticada.

RBAC tradicional é suficiente?

Não isoladamente. O RBAC define quais operações um papel pode executar. Sistemas autônomos frequentemente exigem controles adicionais para determinar quando, onde e sob quais condições a ação é apropriada. Uma arquitetura para agentes pode combinar papéis, contexto operacional, aprovação humana e enforcement no sistema que realmente executa a ação. Uma exclusão de grande volume em produção pode exigir aprovação adicional, como regra verificável fora da geração de respostas.

5. OWASP: excesso de autonomia e privilégios já são riscos reconhecidos

A OWASP classifica Excessive Agency como risco relevante. A categoria LLM06:2025 aponta três causas: funcionalidade excessiva, permissões excessivas e autonomia excessiva. O exemplo citado é uma extensão que deveria consultar um banco e recebe também INSERT, UPDATE e DELETE. As recomendações incluem restringir permissões nas ferramentas e nos sistemas de destino, verificar as operações e exigir aprovação humana para ações de maior impacto.

Em dezembro de 2025, a OWASP publicou o Top 10 for Agentic Applications 2026, incluindo uso indevido de ferramentas e abuso de identidade e privilégios. Em setembro de 2026, apresentou o Agent Control Standard, voltado à observabilidade e ao controle das ações durante a execução. A segurança precisa atuar na camada em que ferramentas e recursos são acessados.

6. Como controlar agentes que acessam bancos de dados

Considere Cursor ou Claude Code conectados a um PostgreSQL pelo Model Context Protocol. Sem controles, o agente recebe uma ferramenta de SQL ligada a credenciais amplas. Uma consulta legítima e uma operação destrutiva usam o mesmo caminho. A diferença passa a depender da decisão do agente e das permissões efetivas do banco.

Uma alternativa é uma camada independente de autorização entre o agente e o recurso: Agente de IA → Conector MCP → Gateway de autorização → PostgreSQL. O gateway verifica a identidade, o perfil, a operação e as regras antes de encaminhar a execução. Operações de maior risco podem exigir aprovação humana. O banco continua usando permissões nativas, para que uma operação não se torne permitida apenas porque atravessou a camada intermediária.

Isso não elimina prompt injection, nem substitui rede, backups, monitoramento, proteção de credenciais ou restrição dos próprios dados. Adiciona uma barreira objetiva para o que pode ser executado.

7. GatekeeperID Agents

O GatekeeperID Agents permite conectar agentes a bancos sem depender só das permissões amplas de uma conta técnica ou das instruções dadas ao modelo. A arquitetura junta gestão de identidade e políticas, um conector MCP e um gateway na infraestrutura do cliente. O foco inicial é SQL em PostgreSQL.

A organização define perfis associados às responsabilidades de quem usa os agentes. Um perfil de análise consulta. Um perfil de desenvolvimento recebe operações adicionais conforme a política. O projeto combina classificação das operações SQL e políticas de autorização com roles e privilégios nativos do PostgreSQL.

Nem toda ação exige autorização manual. Uma consulta rotineira segue as permissões já definidas. Operações que exigem privilégios adicionais podem ir para aprovação humana, com autorização temporária. No desenho atual, a execução única depois da aprovação fica disponível por dez minutos, que é o prazo padrão.

O gateway fica na infraestrutura do cliente e mantém as credenciais do banco fora do contexto do modelo. O conector MCP usa uma credencial própria de integração. O acesso efetivo ao PostgreSQL é mediado pelo gateway. Essa separação não elimina, por si, o risco de uma consulta autorizada devolver informações sensíveis. Escopo de leitura e demais controles continuam necessários.

Há registros de auditoria das operações mediadas e gestão e revogação dos tokens de integração. Isso ajuda a responder quem solicitou, qual operação ocorreu, qual decisão de autorização foi aplicada e quando. A rastreabilidade depende de as operações passarem pelo caminho controlado. Conexões diretas ao banco, fora do gateway, ficam com a política de segurança da organização.

8. O que o GatekeeperID Agents resolve — e o que ele não substitui

Uma ferramenta de autorização não torna um modelo infalível. O objetivo é reduzir privilégios desnecessários, controlar operações no PostgreSQL e acrescentar decisões independentes do agente. Uma instrução inesperada para DROP TABLE não precisa ser atendida só porque o modelo a solicitou. A execução continua subordinada ao perfil, às políticas do gateway e às restrições do banco.

Quem está autorizado a consultar dados confidenciais ainda pode expô-los por outros canais. O RBAC, isoladamente, não implementa prevenção completa contra exfiltração. Proteção de dados pode exigir política de leitura, segurança em nível de linha, mascaramento, restrição de saída, rede e monitoramento. O GatekeeperID Agents também não substitui a proteção de ferramentas que não passam pelo gateway.

O princípio é limitar o alcance das ações executáveis, sem confundir essa proteção com segurança absoluta.

9. Por que isso importa para CTOs, CEOs e líderes de produto

Agentes podem reduzir trabalho repetitivo e acelerar processos. Autonomia não precisa significar ausência de governança. Para um CTO, controlar permissões reduz a superfície de acesso. Para um CEO, riscos operacionais e de exposição entram na estratégia de adoção. Para um líder de produto, funcionalidades de IA evoluem sem transformar cada integração em acesso irrestrito.

O desafio é criar uma arquitetura em que produtividade e segurança evoluam juntas. Identidade, menor privilégio, autorização explícita, segregação de funções, auditoria e supervisão já existem na segurança de aplicações. Agora precisam valer também para as ações dos agentes.

Conclusão: agentes inteligentes também precisam de limites

Pesquisas de 2025 e 2026 identificam dificuldades de governança, credenciais compartilhadas, excesso de privilégios, incidentes e exposição de dados. Casos documentados mostram ações inesperadas. Avaliações acadêmicas mostram que instruções maliciosas podem influenciar o uso de ferramentas ligadas a informações sensíveis.

A resposta não é impedir a adoção de agentes. É garantir que a autonomia exista dentro de limites técnicos verificáveis. Agentes de IA podem decidir como realizar uma tarefa. Não deveriam decidir, sozinhos, quais privilégios possuem para executá-la.

O GatekeeperID Agents aplica identidade, controle de acesso baseado em papéis, políticas de execução, aprovação humana e auditoria às operações de agentes sobre PostgreSQL. A próxima etapa da inteligência artificial corporativa será definida também pela capacidade das organizações de controlar o que os agentes estão autorizados a fazer.

Conheça o GatekeeperID Agents. Assista à demonstração.

Referências e notas metodológicas

As fontes combinam levantamentos corporativos, pesquisas com profissionais, padrões, estudos acadêmicos e incidentes documentados. As pesquisas da Cloud Security Alliance citadas foram financiadas por fornecedores de segurança. Os relatórios da IBM analisam organizações que sofreram violações; os custos médios não são projeção de retorno do GatekeeperID. Os estudos de prompt injection são experimentos controlados. Replit, Invariant Labs e OpenAI são, respectivamente, incidente operacional, demonstração de exploração e incidente em ambiente de avaliação.

1. Microsoft (2026). Cyber Pulse — AI Agent Governance.
2. Cloud Security Alliance (2026). The Identity and Access Gaps in the Age of Autonomous AI.
3. Cloud Security Alliance (2026). Autonomous but Not Controlled.
4. IBM (2026). Cost of a Data Breach Report.
5. IBM Brasil (2026). Custo médio de uma violação de dados no Brasil.
6. OWASP (2025). Excessive Agency — LLM06:2025.
7. OWASP (2025/2026). Top 10 for Agentic Applications.
8. OWASP (2026). Agent Control Standard.
9. NIST (2020). SP 800-207 — Zero Trust Architecture.
10. Alizadeh et al. (2025). Simple Prompt Injection Attacks Can Leak Personal Data Observed by LLM Agents During Task Execution.
11. Debenedetti et al. (2024). AgentDojo — NeurIPS.
12. Invariant Labs (2025). GitHub MCP Exploited.
13. Fast Company (2025). Replit AI Agent Database Incident.
14. OpenAI (2026). The Hugging Face Incident and the Road Ahead.
15. PostgreSQL Global Development Group. Database Roles.

Artigo técnico de análise e divulgação. Não apresenta resultados de eficácia experimental do GatekeeperID Agents nem certificação de conformidade com os padrões citados.