Considere um cenário hipotético: um agente em uma fábrica de IA recupera um documento. Escondida nele, há uma instrução que o usuário nunca pretendeu que o agente executasse. O agente a segue: abre uma conexão, chama uma ferramenta por meio do Model Context Protocol (MCP), obtém um registro que ninguém solicitou e o envia para um destino que ninguém autorizou. O mecanismo de proteção que deveria ter detectado isso era um sidecar no mesmo contêiner, então o agente o desativou primeiro. O log estava sob o controle do agente, portanto o evento nunca foi registrado. Tempo decorrido: menos de um segundo. Ninguém percebeu, porque nada no caminho era capaz de detectar o ocorrido.
Essa não é uma falha incomum. É o que acontece por padrão sempre que os controles ficam ao lado do agente, no mesmo domínio de confiança, onde um agente comprometido ou induzido ao erro pode desativá-los, contorná-los ou adulterar as evidências. Em termos simples: o agente não pode fiscalizar a si mesmo.
A F5 Application Delivery and Security Platform entrega e protege todos os aplicativos e APIs. Os agentes de IA são o próximo passo e se comportam de maneira diferente: um agente chama modelos, aciona ferramentas via MCP, conversa com outros agentes e acessa APIs dentro e fora da fábrica. Para gerar valor, os agentes precisam de acesso controlado a modelos, ferramentas, APIs e dados além de seu sandbox, e essas interações devem permanecer sujeitas a políticas aplicáveis. A Arquitetura de Referência NVIDIA OpenShell, que a NVIDIA está apresentando na NVIDIA GTC Berlin, foi desenvolvida exatamente com esse propósito. Ela distribui as permissões de execução do agente, a aplicação de controles por hardware e a inferência em três camadas de hardware NVIDIA, além de abrir espaço para parceiros no caminho entre elas. A maneira mais clara de mostrar quem faz o quê é acompanhar uma solicitação desde sua saída do sandbox.
O que a arquitetura de referência NVIDIA OpenShell faz
A arquitetura de referência parte da premissa de que o agente não é confiável e, por isso, separa o hardware de forma correspondente.
Na Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros, o NVIDIA OpenShell é executado em CPUs NVIDIA Vera e controla as permissões do agente durante a execução. Seu supervisor avalia solicitações de saída, aplica controles granulares ao tráfego HTTP, GraphQL e MCP configurado, protege credenciais e registra cada decisão de política. O agente é executado em um ambiente isolado. O supervisor que o controla, não.
NVIDIA Sentry adiciona uma camada independente de monitoramento e aplicação de políticas baseada em hardware nas DPUs NVIDIA BlueField-4, em um domínio de segurança isolado que o agente não pode acessar nem modificar: detecção de ameaças, inspeção de solicitações e respostas, governança de agentes e contenção em questão de milissegundos. O NVIDIA Sentry é uma camada opcional e, nos sistemas NVIDIA Vera Rubin, fica no caminho de acesso aos modelos.
A infraestrutura NVIDIA Vera Rubin NVL72 executa os modelos que os agentes acionam. Assim, a arquitetura já decide se um agente pode agir e monitora o que ele faz a partir de uma infraestrutura à qual o agente não tem acesso. A F5 complementa esses controles com inspeção de conteúdo desenvolvida para o tráfego de IA, red teaming e entrega de aplicações, com base em nossa colaboração com a NVIDIA na área de cibersegurança de agentes.
O que o OpenShell e o NVIDIA Sentry decidem
O OpenShell sabe qual agente fez uma solicitação, sob qual política e se o destino e o método são permitidos. Para oferecer proteção adicional, o NVIDIA Sentry é executado no NVIDIA BlueField-4 usando o NVIDIA DOCA para monitorar agentes de forma independente, aplicar políticas diretamente no silício e colocar agentes em quarentena em questão de milissegundos. Juntos, eles garantem que a decisão sobre se o agente pode agir seja tomada fora do controle do próprio agente. Esse é o objetivo do projeto.
Permissões em tempo de execução, monitoramento comportamental e inspeção de conteúdo específica para IA oferecem camadas complementares de proteção. A F5 acrescenta a inspeção de prompts compatíveis, respostas de modelos e chamadas de ferramentas para detectar injeção de prompts, jailbreaks e exposição de dados confidenciais, complementando a governança em tempo de execução do OpenShell, bem como o monitoramento comportamental contínuo e a aplicação de políticas com isolamento por hardware do NVIDIA Sentry.
A F5 inspeciona o que o agente envia e recebe
F5 AI Guardrails inspeciona o tráfego compatível encaminhado a ele pelo caminho de aplicação de políticas, incluindo prompts, respostas do modelo e chamadas de ferramentas transmitidas por protocolos controlados pelo OpenShell. Ele faz três coisas com o que encontra. Bloqueia injeções de prompt, jailbreaks e chamadas de ferramentas que não estejam em conformidade com a política. Oculta dados confidenciais antes que eles saiam. Registra cada decisão no histórico da sessão para fins de auditoria. Seus veredictos e dados de telemetria ficam disponíveis para o OpenShell e o NVIDIA Sentry, de modo que uma solicitação bloqueada possa resultar em uma decisão no nível do agente, podendo chegar à contenção, de acordo com a política do operador. Como a interceptação ocorre no caminho de aplicação de políticas, e não dentro do contêiner do agente, o agente não pode desativar o Guardrails nem contorná-lo. Não há nenhum sidecar que possa ser desativado.
F5 AI Red Team mantém as proteções sob constante avaliação. Ele ataca os agentes e modelos pelo mesmo caminho que um usuário utilizaria, sejam eles privados ou públicos, e suas descobertas são incorporadas às políticas de proteção, para que as defesas acompanhem a evolução dos agentes que governam.
Governar um agente também significa comprovar o que ele fez. O plano de controle da F5 mantém o registro da sessão: usuário, contexto do prompt, chamadas de ferramentas e parâmetros aprovados. O OpenShell mantém suas decisões de política. O NVIDIA Sentry mantém o registro do sistema: acesso a arquivos, chamadas de kernel e métricas de pacotes da DPU. Quando correlacionados, esses registros fornecem uma linha do tempo única do que o modelo pretendia, do que o agente tentou fazer e do que ele de fato fez, com base em fontes que o agente não podia alterar.
O plano de controle da F5 AI Security Platform e o AI Red Team são executados dentro da fábrica, no lado do servidor. Os modelos de inferência de produção que os agentes acionam são executados no NVIDIA Vera Rubin NVL72, e o AI Red Team também usa recursos de GPU para testes de segurança. O AI Guardrails requer apenas uma CPU Arm, portanto pode ser executado no NVIDIA Vera e no BlueField-4. As duas arquiteturas de referência abaixo mostram onde cada componente se encaixa.
Duas arquiteturas de referência da F5 no NVIDIA OpenShell
Distribuídos pelas três camadas da NVIDIA: AI Guardrails no Vera, aplicados à estrutura do agente dentro do OpenShell; AI Guardrails novamente no NVIDIA BlueField-4, fora do raio de impacto do agente, junto ao plano de dados quando a fábrica precisar; e o plano de controle e o AI Red Team no Vera Rubin NVL72, junto aos modelos. Isso resulta em duas arquiteturas de referência. Ambas são baseadas na Arquitetura de Referência do NVIDIA OpenShell, usam a mesma política e o mesmo plano de controle, e a diferença está no que é inserido no caminho do agente.
Arquitetura de referência 1: F5 AI Guardrails com NVIDIA OpenShell e NVIDIA Sentry
Para o operador que executa a stack da NVIDIA conforme projetada. O F5 AI Guardrails é executado em dois locais sob uma única política: no NVIDIA Vera, aplicado à estrutura do agente dentro do OpenShell, e na DPU BlueField-4 integrada ao NVIDIA Sentry, onde o agente não consegue alcançá-lo. O primeiro intercepta o que o agente envia no momento do envio. O segundo é aquele que o agente não consegue desativar. O Guardrails bloqueia, oculta e audita o tráfego compatível roteado para ele e, no BlueField, seus veredictos ficam disponíveis para o NVIDIA Sentry conter o agente imediatamente. Nenhum hardware adicional é necessário. Um NVIDIA Cloud Partner que padroniza sua operação com base na stack da NVIDIA obtém inspeção de conteúdo sem precisar alterar mais nada.
Para maior escalabilidade e entrega de nível empresarial. F5 BIG-IP Next for Kubernetes é executado na DPU NVIDIA BlueField-4 junto com o NVIDIA Sentry, ou na CPU do host, como plano de dados da fábrica, enquanto o F5 AI Guardrails é executado dentro dele sob a mesma política. O NVIDIA Sentry realiza a aplicação básica das políticas; o BIG-IP Next for Kubernetes transporta o tráfego. O BIG-IP Next for Kubernetes roteia e balanceia a carga do tráfego de agentes e aplicações entre instâncias de modelos no Vera Rubin NVL72, integrando-se ao NVIDIA Dynamo. Ele isola locatários, dimensiona e protege conexões do Model Context Protocol (MCP), controla o uso de tokens por locatário e oferece ao operador uma visão unificada de locatários e modelos. O BIG-IP Next for Kubernetes também aplica as políticas de saída externa do operador ao tráfego roteado por ele, complementando os controles de acesso em tempo de execução do OpenShell e a aplicação de políticas de infraestrutura do NVIDIA Sentry.
A escolha cabe ao operador. Leve o AI Guardrails para o OpenShell e o NVIDIA Sentry ou adicione o BIG-IP Next for Kubernetes com o AI Guardrails integrado. A política e o plano de controle são os mesmos em ambos. A segunda opção adiciona isolamento de tenants, controle de saída e gerenciamento de tráfego para toda a fábrica.
Um número, mantido separado da arquitetura de segurança porque foi medido separadamente. Nos testes realizados pelo The Tolly Group com o BIG-IP Next for Kubernetes em DPUs NVIDIA BlueField-3 (relatório nº 226104, publicado em março de 2026), o BIG-IP Next for Kubernetes apresentou uma taxa de transferência de tokens 40% maior do que a referência testada, com o caminho de dados transferido das CPUs do host. Essa é uma medição isolada do plano de dados do BIG-IP Next for Kubernetes. Ela não inclui as funções de inspeção descritas aqui. Em IA, desempenho é economia.
Segurança que permanece na fábrica
Em uma implantação totalmente auto-hospedada, o processamento de segurança e os registros de auditoria da F5 permanecem no ambiente do operador: o plano de controle e a Red Team no lado do servidor, junto aos modelos, e a inspeção no Vera e no BlueField-4. O acesso a modelos e serviços externos continua sendo regido pela política corporativa; os destinos públicos estão no diagrama por um motivo. Manter todos os prompts e respostas dentro da fábrica de IA também exige destinos hospedados localmente e restrições à saída externa. A arquitetura torna isso possível. A política do operador determina se isso acontece, e o BIG-IP Next for Kubernetes aplica essa política de saída.
A era dos agentes não criou exatamente um novo requisito de segurança, mas transferiu o ponto de controle mais importante para o tráfego de saída do agente, em uma infraestrutura que ele não pode manipular. A F5 passou três décadas trabalhando exatamente nesse tipo de caminho. Na Arquitetura de Referência NVIDIA OpenShell, esse é um caminho que o agente não consegue contornar por meio de argumentação.
Para saber mais, recomendo que você acesse nossas páginas sobre F5 AI Security Platform, F5 AI Guardrails, F5 AI Red Team, e F5 BIG-IP Next for Kubernetes.
Sobre o autor
Kunal Anand lidera a organização de produtos da F5 como Chief Product Officer. Responsável pela visão, estratégia e execução de produtos, ele garante o desenvolvimento de soluções inovadoras que resolvem desafios críticos e proporcionam experiências excepcionais aos clientes. Em sua função anterior como Chief Technology and AI Officer, Kunal definiu a estratégia e a visão de tecnologia e IA da empresa. Antes da F5, Kunal exerceu simultaneamente os cargos de Chief Technology Officer e Chief Information Security Officer na Imperva. Sua trajetória na Imperva começou em 2018, com a aquisição da Prevoty, uma startup de segurança de aplicações que ele cofundou em 2013. Antes de ingressar na Prevoty, foi Diretor de Tecnologia na BBC Worldwide. Kunal tem um amplo histórico de inovação e conhecimento técnico especializado, além de ter ocupado cargos de liderança em equipes de segurança, dados, tecnologia e engenharia na Gravity, MySpace e no Laboratório de Propulsão a Jato da NASA. Kunal tem mais de 15 anos de experiência em IA e aprendizado de máquina, abrangendo treinamento de modelos, uso de algoritmos baseados em IA para aprimorar produtos e projeto e implementação de arquiteturas de IA. Kunal é bacharel em Ciência da Computação pelo Babson College.
Mais publicações de Kunal AnandPublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...