O eBPF pode oferecer uma camada adicional de observabilidade, segurança e controle para aplicações que utilizam modelos de IA. Ao atuar no nível do kernel, a tecnologia pode ajudar equipes a monitorar chamadas, controlar o consumo, aplicar políticas e restringir determinadas ações sem alterar diretamente o código da aplicação.
IA está acelerando o desenvolvimento, mas criando novos problemas em produção
A inteligência artificial está aumentando a velocidade com que software é criado. Desenvolvedores conseguem gerar funcionalidades, integrações e serviços em poucos minutos com a ajuda de assistentes e agentes de IA.
O problema é que velocidade não garante compreensão.
Leia também
Web Summit Rio 2026 define datas e confirma palestrantes de peso no Riocentro
À medida que mais código é criado com auxílio de modelos de IA, equipes podem acabar colocando em produção componentes que poucos profissionais realmente entendem. Um pull request pode funcionar, os testes podem passar e a funcionalidade pode ser entregue, mas ainda assim ninguém da equipe conhecer profundamente o comportamento daquele código.
Isso cria um novo desafio para engenharia de software: quem será responsável por entender, monitorar e controlar sistemas criados cada vez mais rapidamente?
A situação se torna ainda mais complexa com a chegada dos agentes autônomos.
Diferentemente de um assistente que apenas sugere código, um agente pode receber permissões para executar comandos, acessar APIs, modificar arquivos, consultar bancos de dados e interagir com infraestrutura.
Se esse agente interpretar incorretamente uma instrução, uma ação aparentemente simples pode gerar consequências importantes.
Por isso, controlar apenas o código da aplicação pode não ser suficiente.
É nesse cenário que o eBPF começa a ganhar espaço como uma possível camada de observabilidade e controle para aplicações e agentes de IA.
O que é eBPF e por que ele interessa às equipes de IA
eBPF, sigla para Extended Berkeley Packet Filter, é uma tecnologia do Linux que permite executar programas controlados dentro do kernel.
Inicialmente associado à filtragem e observação de pacotes de rede, o eBPF evoluiu e passou a ser utilizado em diferentes áreas, incluindo:
observabilidade;
segurança;
monitoramento de rede;
análise de performance;
controle de tráfego;
aplicação de políticas no nível do sistema.
A principal característica é que esses programas podem observar ou reagir a determinados eventos sem exigir alterações no código-fonte da aplicação monitorada.
Isso é especialmente interessante para ambientes modernos baseados em containers e Kubernetes.
Uma aplicação pode fazer uma chamada para um modelo de IA utilizando uma API externa. Essa comunicação normalmente passa pela infraestrutura de rede do sistema.
Dependendo da arquitetura adotada, uma camada baseada em eBPF pode observar esse tráfego e aplicar determinadas políticas antes ou durante a comunicação.
O problema das chamadas de IA espalhadas pela infraestrutura
Muitas aplicações modernas fazem chamadas para modelos de linguagem diretamente a partir de seus serviços.
Um container pode enviar uma requisição HTTP contendo informações como:
modelo escolhido;
prompt enviado ao modelo;
contexto da conversa;
limites de geração;
configurações da chamada.
A resposta também pode incluir dados importantes, como o conteúdo gerado e informações sobre utilização.
O problema é que essas integrações podem estar distribuídas por diferentes aplicações e serviços.
Um desenvolvedor pode escolher um modelo mais caro.
Outro serviço pode enviar um volume inesperado de requisições.
Um agente pode consumir recursos acima do planejado.
Em ambientes maiores, descobrir exatamente quem está utilizando qual modelo e quanto isso está custando pode se tornar um desafio operacional.
A proposta discutida por Dan Finneran, da Isovalent, empresa pertencente à Cisco, é utilizar a capacidade de observação e controle do eBPF como parte da infraestrutura que governa essas interações.
Um AI Gateway sem alterar o código da aplicação
Uma das ideias mais interessantes dessa abordagem é a possibilidade de implementar determinadas políticas fora da aplicação.
Em vez de modificar cada serviço individualmente, uma camada de infraestrutura poderia observar as conexões relacionadas às APIs de IA.
Dependendo da implementação, isso permitiria centralizar regras como:
limites de consumo;
restrições sobre modelos;
políticas de acesso;
monitoramento de chamadas;
bloqueio de determinados destinos;
auditoria de interações.
Na prática, isso aproxima o conceito de um AI Gateway de tecnologias que já são utilizadas para controlar APIs e tráfego de rede.
A diferença é que, nesse caso, o objetivo seria governar especificamente as interações entre aplicações, agentes e serviços de inteligência artificial.
Controle de custos pode ser um dos principais usos
Um dos maiores desafios para empresas que utilizam IA em escala é a previsibilidade de custos.
Uma aplicação pode parecer barata durante os testes, mas apresentar um comportamento completamente diferente em produção.
Um loop mal configurado, uma sequência inesperada de chamadas ou o uso de um modelo mais caro pode aumentar rapidamente o consumo.
Uma camada centralizada de observabilidade pode ajudar a identificar padrões como:
serviços que realizam chamadas excessivas;
modelos utilizados fora da política definida;
crescimento inesperado no volume de requisições;
aplicações com comportamento diferente do esperado.
Além da observação, uma arquitetura de controle pode permitir a aplicação de limites definidos pela equipe.
O objetivo não é substituir o controle implementado no código, mas adicionar uma camada independente de governança.
Isso é particularmente importante em ambientes onde múltiplas equipes desenvolvem serviços de forma descentralizada.
Trocar modelos sem modificar cada aplicação
Outro cenário discutido é a possibilidade de centralizar a escolha de modelos.
Imagine uma organização com dezenas de aplicações utilizando APIs de IA.
Algumas utilizam modelos mais caros, enquanto outras poderiam funcionar adequadamente com opções menores ou especializadas.
Sem uma camada de abstração, alterar essa estratégia pode exigir mudanças em diversos repositórios.
Uma infraestrutura de AI Gateway pode ajudar a separar a lógica da aplicação da política de utilização dos modelos.
Isso não significa que qualquer implementação baseada em eBPF possa automaticamente interpretar e modificar todo tipo de tráfego de aplicação. Existem limitações técnicas relacionadas a protocolos, criptografia, arquitetura e segurança.
Mas o princípio é importante: políticas de infraestrutura podem reduzir a dependência de alterações individuais em cada serviço.
Segurança para agentes de IA exige mais do que um bom prompt
O crescimento dos agentes de IA também está mudando a forma como equipes precisam pensar em segurança.
Um agente pode ter acesso a ferramentas.
Essas ferramentas podem permitir ações como:
executar comandos;
alterar arquivos;
consultar bancos de dados;
acessar APIs;
modificar infraestrutura.
O risco não depende apenas da capacidade do modelo.
Também depende das permissões concedidas ao agente.
Uma instrução mal interpretada ou uma tentativa de prompt injection pode fazer com que um agente tente utilizar ferramentas além do comportamento originalmente esperado.
Por isso, controles externos ao próprio modelo se tornam importantes.
Uma arquitetura baseada em políticas pode restringir quais destinos de rede um agente pode acessar ou limitar determinados tipos de comunicação.
A ideia central é simples: não depender apenas do agente para decidir o que ele pode ou não fazer.
eBPF adiciona uma camada de controle abaixo da aplicação
Tradicionalmente, muitas políticas são implementadas diretamente na aplicação ou em componentes externos, como proxies, gateways e sidecars.
Essas soluções continuam importantes, mas podem aumentar a complexidade da arquitetura.
O eBPF oferece outra possibilidade ao permitir observação e aplicação de determinados controles no nível do sistema operacional.
Em ambientes baseados em Kubernetes, isso pode ser especialmente relevante.
Uma infraestrutura pode aplicar políticas sobre workloads sem exigir que cada container implemente a mesma lógica.
Entre os possíveis benefícios estão:
menor dependência de alterações no código da aplicação;
políticas centralizadas;
observabilidade compartilhada;
controle mais próximo da infraestrutura;
possibilidade de atualização de determinados programas e políticas sem modificar cada serviço individualmente.
A utilização prática depende da tecnologia adotada e do tipo de tráfego que precisa ser observado ou controlado.
Por isso, o eBPF não deve ser visto como uma solução mágica para todos os problemas de segurança em IA.
Ele é mais uma camada dentro de uma estratégia de defesa.
O papel do Cilium nessa arquitetura
O ecossistema do eBPF já possui ferramentas consolidadas para ambientes cloud native.
O Cilium é um dos principais exemplos, utilizando eBPF para implementar funcionalidades relacionadas a rede, segurança e observabilidade em ambientes Kubernetes.
Essa base tecnológica torna possível explorar novas formas de controlar como workloads se comunicam com serviços externos.
Para aplicações que dependem de APIs de IA, isso pode abrir espaço para políticas específicas.
Por exemplo, uma organização pode definir quais workloads possuem autorização para acessar determinados endpoints.
Também pode criar mecanismos de observabilidade capazes de identificar padrões anormais de comunicação.
A evolução desse tipo de arquitetura está relacionada ao surgimento de uma nova camada de infraestrutura voltada especificamente para aplicações de IA.
AI Gateways estão se tornando uma nova camada da infraestrutura
Assim como APIs tradicionais passaram a utilizar gateways para autenticação, controle de tráfego e aplicação de políticas, aplicações de IA começam a gerar a necessidade de uma camada semelhante.
Um AI Gateway pode atuar como ponto de controle entre aplicações e modelos.
Essa camada pode concentrar funcionalidades como:
autenticação;
roteamento entre modelos;
observabilidade;
controle de custos;
políticas de segurança;
registro de chamadas;
governança de acesso.
O eBPF não é a única tecnologia capaz de participar dessa arquitetura.
Proxies, gateways tradicionais e plataformas especializadas também podem cumprir funções semelhantes.
O diferencial do eBPF está na possibilidade de integrar determinados controles diretamente à infraestrutura do sistema.
Comparação entre abordagens tradicionais e uma camada baseada em eBPF
Característica | Abordagem tradicional | Possível abordagem com eBPF |
|---|---|---|
Aplicação de políticas | Implementada no código ou em proxies | Pode ser aplicada na camada de infraestrutura |
Alterações nas aplicações | Pode exigir mudanças em vários serviços | Determinadas políticas podem ser externas à aplicação |
Observabilidade | Dependente de instrumentação e logs | Pode observar eventos no nível do sistema |
Controle de rede | Normalmente concentrado em proxies e gateways | Pode utilizar hooks e políticas integradas ao kernel |
Atualização de regras | Depende da arquitetura utilizada | Pode permitir atualização dinâmica de determinados programas e políticas |
Arraste para o lado para ver toda a tabela.
O maior desafio será governar sistemas que ninguém entende completamente
A discussão sobre eBPF e IA revela um problema maior.
À medida que a inteligência artificial acelera a produção de software, as empresas podem enfrentar uma quantidade crescente de sistemas, integrações e agentes que operam mais rapidamente do que a capacidade humana de acompanhar cada detalhe.
Isso não significa que o código gerado por IA seja necessariamente inseguro.
O problema está na velocidade e na escala.
Quanto mais sistemas são criados, mais difícil se torna garantir que todos sigam as mesmas políticas.
Nesse cenário, controles implementados exclusivamente dentro de cada aplicação podem não ser suficientes.
As organizações precisarão combinar diferentes camadas.
Boas práticas de desenvolvimento continuam sendo necessárias.
Revisão de código continua sendo importante.
Controle de identidade e permissões será essencial para agentes.
Observabilidade precisará acompanhar novas interações entre aplicações e modelos.
E a infraestrutura pode assumir um papel maior na aplicação dessas regras.
eBPF não substitui a segurança da aplicação, mas pode fortalecer a arquitetura
A principal conclusão não é que todas as empresas precisam colocar um programa eBPF entre suas aplicações e modelos de IA.
A tecnologia exige conhecimento especializado e deve ser utilizada considerando as limitações da arquitetura.
Além disso, criptografia, protocolos, privacidade e performance precisam ser avaliados antes de qualquer implementação.
O ponto mais relevante é outro.
A inteligência artificial está criando novas superfícies de ataque e novos desafios operacionais. Agentes podem tomar decisões, utilizar ferramentas e interagir com sistemas externos.
Por isso, confiar exclusivamente em instruções enviadas ao modelo não é uma estratégia suficiente.
Será necessário combinar:
controle de identidade;
privilégio mínimo;
sandboxing;
políticas de rede;
observabilidade;
validação humana;
limites de execução.
O eBPF pode se tornar uma peça importante dessa arquitetura justamente porque oferece uma forma de observar e controlar determinados comportamentos abaixo da camada da aplicação.
Para equipes de DevOps, SRE, segurança e plataforma, a evolução dos AI Gateways pode representar uma nova etapa da infraestrutura cloud native.
No futuro, gerenciar aplicações de IA pode exigir não apenas saber qual modelo está sendo utilizado, mas também entender quem está fazendo a chamada, qual agente iniciou a ação, quais permissões estavam disponíveis e quais políticas deveriam impedir um comportamento inesperado.
Nesse cenário, tecnologias capazes de oferecer visibilidade e controle em tempo real podem deixar de ser apenas ferramentas avançadas de infraestrutura e passar a ocupar um papel central na governança da IA em produção.
