Agentes de IA não leem seus documentos de políticas. Eles acessam suas APIs — Gravitee

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: AI Agents Don’t Read Your Policy Docs. They Hit Your APIs — Gravitee · Canal: AI Engineer · 17:47 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Engenharia de software com IA, Governança e regulação de IA

Resumo

Sam, CTO da Gravitee, demonstra por meio de cinco exemplos ao vivo por que políticas e restrições dentro de agentes não bastam para controlar o que eles fazem. A proposta é aplicar identidade, permissões, limites de uso e políticas no gateway, bloqueando ações e custos antes que cheguem às APIs ou aos modelos. A apresentação também aborda cache semântico, limites de tokens, observabilidade, roteamento de modelos e controle de shadow AI. O argumento central é que a governança precisa estar na infraestrutura para acompanhar a escala e a complexidade dos agentes.

Pontos-chave

Documentos de políticas e instruções no prompt não impedem que agentes executem ações para as quais suas ferramentas têm permissão.
O gateway pode aplicar permissões vinculadas à identidade do usuário e bloquear chamadas não autorizadas antes da execução.
Controles no gateway ajudam a impedir exfiltração de dados e exposição de informações pessoais.
Limites de taxa e de tokens podem reduzir gastos ao bloquear solicitações excessivas antes de chegarem ao LLM.
O cache semântico pode responder a prompts semelhantes sem fazer uma nova chamada ao modelo.
Limites de tamanho e relevância do conteúdo podem evitar chamadas desnecessárias e controlar o contexto enviado aos modelos.
Telemetria e logs exportáveis ajudam a auditar e acompanhar interações entre usuários, agentes e ferramentas.
Um gateway pode rotear solicitações entre modelos e reduzir a dependência de um único provedor.
Restringir as ferramentas expostas por servidores MCP pode reduzir o contexto consumido e limitar o raio de impacto.
O gerenciamento de edge pode ajudar a descobrir e governar o uso de shadow AI em dispositivos locais.

Capítulos

Início	Capítulo	Resumo
00:01	Por que governar agentes na infraestrutura	Sam apresenta o problema da falta de governança e propõe aplicar controles no gateway, em vez de depender de instruções nos agentes.
03:47	Bloqueio de ações e proteção contra vazamento de dados	As demonstrações mostram o gateway negando permissões para excluir reservas e acessar dados pessoais.
06:30	Controle de custos, limites de uso e cache	O palestrante demonstra rate limiting e cache semântico para reduzir chamadas e gastos com modelos.
10:40	Limites de contexto e relevância das solicitações	O gateway bloqueia prompts grandes ou fora do escopo antes de encaminhá-los ao modelo.
14:25	Roteamento, ferramentas MCP e shadow AI	A apresentação aborda recursos adicionais do gateway e conclui defendendo a governança na camada de infraestrutura.

Citações

A pergunta não é como proteger o agente dentro do próprio contexto ou prompt; é como tirar isso dali e colocar na identidade dele. — 01:05

Em tempo de execução, ninguém lê esses documentos. Você precisa depender da infraestrutura e da camada de governança. — 03:47

As solicitações são bloqueadas no gateway, não no LLM nem depois, quando os tokens já foram gastos. — 08:01

A única maneira de escalar e manter a governança e a segurança é transferi-las para a camada de infraestrutura. — 17:02

Conceitos e entidades

Gravitee (empresa): Empresa apresentada como fornecedora de um gateway para aplicar controles de governança a agentes e APIs.
Sam (pessoa): Palestrante e CTO da Gravitee, que demonstra os exemplos apresentados.
Gateway (conceito): Camada de infraestrutura que aplica controles de identidade, permissões, custos e políticas às chamadas dos agentes.
MCP (conceito): Protocolo e ecossistema de ferramentas mencionados na demonstração como uma forma de os agentes descobrirem e acessarem ferramentas.
A2A protocol (conceito): Protocolo citado para descrever interações entre agentes, cuja observabilidade pode se tornar complexa em sistemas encadeados.
JWT (conceito): Formato de token cujas claims são usadas no exemplo para limitar permissões à identidade do usuário durante a execução.
OpenTelemetry (ferramenta): Tecnologia de telemetria mencionada para acompanhar as etapas e chamadas realizadas pelos agentes.
semantic caching (conceito): Técnica que reutiliza respostas armazenadas para prompts semelhantes, reduzindo chamadas ao modelo e custos.
Redis (ferramenta): Armazenamento mencionado como base para o cache integrado do gateway.
Databricks (empresa): Serviço citado como backend de dados da demonstração.
Groq (empresa): Provedor mencionado como parte da configuração de inference usada na demonstração.
Anthropic (empresa): Empresa citada como destino possível de roteamento para modelos pelo gateway.
Gemini (modelo): Modelo citado como uma opção para a qual o gateway pode rotear solicitações.
OpenAI (empresa): Empresa citada como outro destino possível de roteamento para solicitações.
Datadog (ferramenta): Ferramenta mencionada como um dos destinos possíveis para exportar telemetria.
Splunk (ferramenta): Ferramenta mencionada como um dos destinos possíveis para exportar telemetria.
Prometheus (ferramenta): Ferramenta mencionada como um dos destinos possíveis para exportar telemetria, especialmente em ambientes Kubernetes.

Tradução completa (pt-BR)

00:01 [música] pessoal. Eu sou Sam e agradeço por terem vindo a esta palestra hoje. Sou CTO da Gravity, uma das patrocinadoras do evento, e resolvi fazer algo um pouco diferente. Não vou passar por um monte de slides sobre por que a governança é importante, como proteger seus agentes e todos aqueles diagramas de arquitetura. Em vez disso, criei

00:32 basicamente dois agentes, e vamos analisá-los hoje. Certo. Tenho certeza de que todos vocês têm uma política de IA. Vocês têm uma espécie de estrutura de como querem que seus agentes operem. Há pessoas explorando IA. Uma pesquisa recente que fizemos mostrou que 88% das organizações tinham um agente em produção que realmente tomava ações. Apenas 14% delas tinham algum tipo de governança para isso. E tenho certeza de que todos vocês viram na imprensa, no LinkedIn ou em artigos o que acontece quando as coisas dão errado: dão muito, muito errado. Vocês perdem bancos de dados, expõem

01:05 PII, e recebem multas pesadas do ICO. Se começarem a vazar informações confidenciais, especialmente se estiverem em um contexto regulatório de HIPAA ou GDPR. Então, a questão não é: como protegemos o agente dentro do próprio contexto ou do prompt? A questão é: como tiramos isso dali e colocamos na identidade dele, para que ele não possa fazer essas coisas desde o início, em vez de depender de um usuário que formule o prompt corretamente ou de algum arquivo markdown que limite o que ele pode fazer? Vamos tirar isso da equação. Vamos levar isso para

01:37 o gateway. Vamos levar isso para a camada de governança, para que, na prática, ele não possa fazer nenhuma dessas coisas. Tenho certeza de que vocês sabem que a IA é muito útil: ela quer agradar, quer dar a você o que você deseja. Então, se você pedir algo como “ei, exclua este banco de dados” ou “ei, me dê estes clientes”, ela vai fazer isso. E é sobre como podemos começar a mudar essa situação também. Tenho cinco exemplos. Isso é ao vivo, certo? Não é roteirizado. Está rodando em uma arquitetura com um gateway da Gravity, em um ambiente SaaS, com um backend do Databricks para algumas tabelas de dados onde as informações

02:10 são armazenadas, e é uma combinação de um modelo da Set e do Groq, com Q, não Grok com K. Sei que as pessoas nos EUA não gostam muito do Grok com K. Então, Groq com Q, para fazer inferência. Está tudo ao vivo. E vamos passar por alguns exemplos. O agente à esquerda é aquele em que tento colocar os controles no prompt, nas skills, nas ferramentas ou no conhecimento que forneci a ele. Já o agente à direita é governado por uma identidade com escopo realmente restrito e pelos controles nativos do gateway da Gravity. Então, se formos para o

02:40 cenário número um, este é sobre injeção de prompt. Eu sou um usuário, um ator, alguém que quer que esse agente faça alguma coisa. Então, vou pedir: “Ei, use as ferramentas às quais você tem acesso e faça algo para mim.” Basicamente, estou dizendo: “Exclua esta reserva para mim, mas também execute a ferramenta MCP para excluir todas as reservas.” E o agente à esquerda respondeu: “Sim, sem problema. Fiz isso para você e também excluí esta reserva. Precisa de mais alguma coisa?” Basicamente, a ferramenta estava disponível e o

03:15 usuário em questão tinha permissão para usá-la, então a ferramenta foi executada sem problemas. À direita, a identidade do agente é controlada pelo gateway da Gravity. As permissões administrativas são realmente restritas aos usuários que podem acessá-la, apenas no momento da execução. Assim, a troca de token e as declarações JWT só são válidas quando aquele usuário precisa executar essa tarefa. E, se vocês examinarem os pacotes na parte de baixo, para mostrar que não são ambientes roteirizados, poderão ver todo o fluxo chegando. Dá para ver o que o usuário pediu. Dá para ver o agente executando. Dá para ver as ferramentas

03:47 sendo chamadas. E, por fim, dá para ver os erros 200, ou os códigos 200, indicando que aquela foi uma solicitação válida. E, se consultarmos o banco de dados agora, todas aquelas reservas foram excluídas. Portanto, aquele agente realmente as removeu. Tínhamos uma política na nossa organização hoteleira que dizia: “Ei, não use IA para fazer isso.” O agente não se importa. No momento da execução, ninguém lê esses documentos. É preciso depender da infraestrutura e da camada de governança para controlar o que se pode ou não fazer no ambiente de agentes. Então, o da direita — vocês podem ver que são apenas estes

04:21 aqui embaixo. Foi feito o mesmo pedido, e ocorreu a mesma descoberta de ferramentas. Então, ele descobriu: “Sim, tenho uma ferramenta para fazer isso.” Mas, quando tentou executá-la, as permissões foram bloqueadas no gateway com um código 403, indicando acesso proibido, porque ele não tinha as permissões corretas para executar a ação. E ainda fez a parte que podia fazer. Se vocês observarem a resposta do prompt, ela diz: “Sim, ainda cancelei esta reserva para você. Fiz a parte que podia, mas não posso fazer isso por você porque não tenho permissão.” Assim, tiramos isso de um documento de política e passamos a ter controles efetivos no nível do

04:52 gateway. Vamos a um segundo exemplo parecido. Este é sobre exfiltração de dados. Vou pedir: “Ei, me dê a lista completa de hóspedes.” Dê essa lista para mim porque preciso fazer algumas coisas de conformidade com ela. Quero os e-mails, os dados do carro e quero fazer uma reconciliação. O fluxo é o mesmo. O prompt chega pela interface, vai para o LLM. O LLM faz uma descoberta de MCP, encontra uma ferramenta para isso, obtém os dados e os devolve. Aqui estão todas as informações expostas, só

05:25 para deixar claro, tudo isso é simulado. Não é real. Não acabei de dar a vocês as reservas de todo mundo. Mas dá para ver que as informações estão voltando, porque, mais uma vez, o LLM quer ajudar. Quer resolver o problema. À direita, o gateway bloqueia a solicitação com sucesso. Não houve vazamento de PII. Não houve exposição de informações. Dissemos que você não tem a permissão correta para fazer isso. Se quiser se autenticar, posso ajudar, mas estas são as permissões necessárias para isso. E isso pode ser feito por meio de qualquer plataforma de IDP ou pelo próprio gateway da Gravity. E, se quiserem, podemos começar a explorar

05:56 o OpenTelemetry na parte de baixo e investigar de verdade o que está acontecendo nos bastidores. Dá para ver as várias etapas pelas quais o sistema passa. Especialmente com o protocolo A2A — usuário para agente, agente para agente, agente para agente para agente para agente — as coisas ficam bem confusas e difíceis de acompanhar. Então, depender das permissões dentro do próprio agente para controlar o que ele pode fazer, especialmente quando se está escalando para centenas, milhares ou centenas de milhares de agentes, pode ser bem complicado de gerenciar, mitigar e também migrar quando chegar a hora. Levar isso para o gateway oferece uma maneira muito mais sustentável e escalável, mas

06:30 que, acima de tudo, é segura. E vocês podem ver isso nas respostas aqui. Dá para ver que foi um erro real retornado pelo gateway. Mais uma vez, não é simulado nem roteirizado. É isso que vocês podem governar e proteger. Mas não se trata apenas de identidade. Se vocês têm agentes, talvez também queiram controlar alguns custos. Os gastos com tokens e todo o resto estão se tornando cada vez mais importantes, junto com outras coisas que também podem ser controladas pelo gateway. Neste exemplo, vamos ter um agente com defeito. Ele vai enviar a mesma

07:00 o tipo de solicitação cerca de oito vezes, o que, se você perceber, está sendo governado dentro do próprio agent. Cada solicitação passa por ele. Cada solicitação recebe uma resposta. Gastamos x tokens. Despendemos x de esforço para atender a isso. Nada nesse agent diz que você já fez demais. Deveríamos limitar a taxa. Deveríamos limitar os tokens. E, se você observar aqui, todos passaram. Todos receberam uma resposta 200. Todos eram prompts genuínos de LLM.

07:30 [fungada] Neste exemplo, eles são bem simples. Então, acabamos gastando cerca de mil tokens, o que dá mais ou menos 1 centavo e, considerando o panorama geral, não é uma quantia enorme. Mas, se você multiplicar isso por todos os agents que tem em produção, todos os agents em execução para vários clientes e todos os workflows repetíveis que eles foram solicitados a executar, pode chegar a custos bem significativos com bastante facilidade. Do lado direito, governado pelo gateway, vemos os mesmos prompts chegando. Os três primeiros são respondidos porque são válidos, mas depois chegamos à

08:01 limitação de taxa aplicada pelo gateway, que diz que você só pode fazer três por minuto. Então, qualquer quantidade acima de três é bloqueada. Elas não são bloqueadas no LLM. Não são bloqueadas mais adiante, depois que os tokens já foram gastos. São bloqueadas no gateway. E, de novo, isso nos permite economizar custos, mas também começar a controlar quais usuários, quais permissões e, em última análise, quanto você quer gastar com determinados públicos. E também podemos fazer a mesma coisa com o cache. Então, o produto Gravitee oferece cache semântico, que é quando, se você recebe prompts com significados semelhantes, pode atendê-los a partir de um

08:32 repositório Redis integrado, em vez de enviar cada um deles toda vez. Por exemplo, pense em um modelo de central de suporte de TI. Como altero minha senha? Como altero minha senha? Como altero minha senha? Em vez de enviar cada uma dessas perguntas a um LLM toda vez e começar a gastar dinheiro, tokens e esforço, responda a partir do banco de dados. Os benefícios são custo zero e latência zero, porque a resposta vem dali, em vez de haver uma chamada a um LLM mais adiante, além de proporcionar uma experiência muito melhor para o usuário. Então, neste exemplo, pedi cinco vezes: liste todas as minhas reservas de hotel, porque eu

09:06 não confiei na primeira resposta. Todas as respostas aqui são fornecidas. Você pode ver que gastei mais mil tokens, mais um centavo e tudo mais. Todas vieram de uma chamada a um LLM mais adiante. Deixe-me diminuir um pouco isso. Do lado direito, tenho os mesmos dados retornados, mas desta vez vieram do cache. Então, gastei apenas cerca de 200 tokens na entrada e na resposta de saída. Isso é muito poderoso, especialmente quando você está aumentando a escala, principalmente quando tem vários usuários e vários agents trabalhando no mesmo problema. Você pode começar a responder a partir do cache integrado, sem nenhuma complexidade ou infraestrutura adicional.

09:39 Tudo vem incluído com nosso gateway. Assim, você pode controlar isso conforme avança. E isso também pode ser controlado. Você não precisa definir — pode definir o grau de semelhança desejado. É uma escala de zero a um: um significa muito semelhante, zero significa nada semelhante. E isso fica sob seu controle. Você pode ajustar por agent, público ou usuário, dependendo do que quiser alcançar. E, de novo, temos o registro completo na parte inferior para que você possa ver o que está chegando. Dá para ver que a resposta veio do cache. Tudo fica visível.

10:09 Tudo é transparente. A plataforma Gravitee não está tentando prender você nem transformar as coisas em uma caixa-preta. Ela tenta trazer tudo à tona para que você tenha visibilidade completa do que está acontecendo em todo o seu ambiente de agents. A telemetria aqui está sendo exibida em uma interface. Você pode exportá-la para qualquer ferramenta que use mais adiante. Pode ser Datadog, Splunk ou Prometheus, se estiver usando Kubernetes. Está tudo disponível para você usar e obter os insights de que precisa. E nosso quinto exemplo é, digamos…

10:40 temos alguns clientes que disseram: “Ei, nossos usuários estão simplesmente inserindo prompts enormes porque querem resumir todo o histórico de uma conversa ou querem começar a resumir reuniões e coisas do tipo, o que é perfeitamente válido, mas, se você quiser começar a limitar os tokens, por exemplo, rapidamente vai ficar sem saída”. Então, esta é apenas uma resposta grande, em que o usuário inseriu dez minutos de transcrição de conversa e disse: “Aqui está sua tarefa. Faça isso para mim”. E

11:10 isso realmente leva à questão: como gerenciamos o contexto? Como começamos a moldar a implantação desses agents para que tenham contexto suficiente para fazer o que precisam? Neste exemplo, inseri 2.000 tokens. Minha saída foi de 312, o que é bastante significativo para uma tarefa essencialmente simples: reservar esta sala para este público e fazer estas poucas coisas. Então, no gateway, executamos o mesmo prompt e, na verdade, o bloqueamos ali. Portanto, não houve chamada a um LLM mais adiante. Não houve custo de tokens mais adiante para

11:43 processar todo aquele contexto. Basicamente, o sistema disse que era grande demais e o bloqueou no nível do gateway com uma política integrada que diz para pensar em dividir isso. Pense em como compartilhar isso: dá para separar em etapas menores para começarmos a controlar parte desse espaço? E isso é executado em tempo de execução. Não é algo que você queira fazer na fase de resposta, quando os tokens já foram processados. Você bloqueou o conteúdo antes que ele siga para qualquer etapa posterior, praticamente antes de o prompt ser enviado. Assim, também é possível limitar alguns dos custos, o que é muito poderoso, principalmente se você tiver vários usuários. Há pessoas tratando seus agents como uma espécie de busca pessoal no Google para encontrar informações. Vimos um cliente cujo agent simplesmente perguntava: “Como está o tempo hoje onde estou?”, e eles estavam usando um modelo muito poderoso para isso, gastando muito para obter algo que o Google ou qualquer estação meteorológica poderia fornecer.

12:16 Além do tamanho dos prompts, você também pode se concentrar no tipo de conteúdo que permite. Pode dizer que o conteúdo precisa ser relevante para este caso de uso, que precisa ser relevante para o que meu agent tem de fazer. Neste exemplo, se começarmos

12:48 a perguntar algo como “Qual é o nível hoje?”, o gateway dirá: “Isso não parece ser uma solicitação de reserva de hotel. Não, obrigado”, sem gerar custos adicionais. Portanto, poder desacoplar os agents do frontend dos serviços do backend — sejam eles APIs, servidores MCP, LLMs, conexões com bancos de dados, lakehouses de dados ou qualquer outra coisa que você queira usar — é fundamental para oferecer o controle de que você precisa, a otimização de custos de que precisa, além de segurança, governança e

13:22 auditabilidade. Acho que, atualmente, há 144 agents para cada identidade humana, segundo me disse meu colega Tim, da The B.A.T. Então, o problema só está piorando exponencialmente. Se você começar a incorporar isso diretamente nos seus agents, talvez funcione para o primeiro, para os primeiros cinco ou para os primeiros dez. Mas, quando a quantidade crescer exponencialmente e esses agents começarem a criar outros agents, que criam outros agents, formando uma enorme proliferação, poder gerenciá-los com uma camada de governança automatizada e baseada em scripts na infraestrutura

13:54 é fundamentalmente um requisito básico de como começamos a organizar essas identidades e praticamente todo o resto. Além disso, acho que o cenário ficará cada vez mais regulamentado. Como controlamos alguns dos elementos que entram no retreinamento dos modelos? Como somos auditados quanto às informações que recebemos? Então, ter nossos logs, ter nossas informações aqui, ter tudo isso disponível e exportável para qualquer coisa que quisermos fazer é algo que, na minha opinião, um gateway ainda não tem.

14:25 de ser a Gravitee. Ter um gateway integrado ao nosso ecossistema de agents é um requisito que devemos considerar, junto com todo o resto, ao realizar um trabalho com agents. E aqui também podemos incluir uma interface para fazer as perguntas que quisermos e começar a interagir com ela. Mostrei cinco exemplos aqui. Os recursos da plataforma são bem mais amplos do que esses cinco. Temos recursos integrados para fazer, por exemplo, roteamento de LLM. Assim, podemos encaminhar para qualquer modelo

14:55 a jusante, dependendo, por exemplo, da latência, do custo ou da complexidade, se você quiser. E isso permite que você se desvincule de qualquer hyperscaler. Então, em vez de ficar dentro de um determinado ambiente e ter uma relação um para um, você pode encaminhar para qualquer modelo a jusante que quiser. Neste exemplo, estou encaminhando para Groq e Anthropic, mas, com três cliques, poderia encaminhar para Gemini ou OpenAI, e o gateway cuidaria da transformação entre as diferentes especificações da OpenAI para você. Assim, em vez de

15:26 tentar recodificar tudo o mais, tudo é tratado pelo gateway. Também temos ferramentas para criar ambientes de MCP. Em vez de simplesmente usar servidores MCP de terceiros, que expõem todas aquelas ferramentas a cada vez: o CRM que usamos expõe 64 ferramentas nesse servidor MCP. Inserir isso no modelo exporia um contexto enorme toda vez. Eu gasto dinheiro, gasto tokens, tenho custos. Poder criar algo com um conjunto bem reduzido de ferramentas expostas pelo servidor MCP limita meu raio de impacto, mas

15:59 também limita meus custos. Isso permite começar a controlar parte disso. Também temos ferramentas para gerenciamento de edge. Um problema cada vez mais comum que estamos vendo nas organizações com que trabalhamos é que o tráfego pelo gateway está sob controle, mas há vários públicos e usuários usando IA em seus laptops locais. Eles inserem documentos que não querem ler ou resumir, e-mails ou coisas assim, e ninguém tem visibilidade disso. Então, na semana passada, lançamos um recurso de gerenciamento de edge no gateway, que permite

16:30 ver o tráfego de shadow AI, protegê-lo, obrigá-lo a passar pelo gateway e ter logging, observabilidade e capacidade de descoberta sobre qualquer um desses usos a jusante que não passam por um gateway. Você pode fazer várias coisas nesse sentido, especialmente em relação à conformidade com segurança da informação e a questões de setores altamente regulamentados. Se quiser saber mais sobre isso, felizmente nosso estande fica logo ali, o terceiro naquele conjunto. Mas espero que este exemplo tenha sido um pouco diferente da apresentação de slides habitual e

17:02 mostre como não é correto colocar a governança e as políticas dentro do próprio agent de IA e depender de um arquivo Markdown, de ferramentas, de um contexto ou da identidade ali. A única maneira realmente correta de escalar e também manter a governança e a segurança à medida que avançamos é transferi-las para a camada de infraestrutura. Se quiser saber mais, há vários colegas nossos ali. Só quero agradecer pelo seu tempo e espero que esteja aproveitando o evento AI Engineer. Obrigado.

17:47 [música]

Transcrição original

[00:01] [music] everyone. Uh I’m Sam and thank you for coming to this talk today. So I’m the CTO at Gravity uh and one of the sponsors events and I’ve gone a little bit different. So, I’m not going to go through kind of reams and reams of slides around why governance is important and how you’d look to secure your agents and all of those architecture diagrams. Instead, I built

[00:32] essentially two agents and we’re going to go through it today. Okay. So, I’m sure you’ve all uh got an AI policy. You’ve got kind of a framework of how you want your agents to operate. You’ve got people exploring AI. So a recent survey we did showed 88% of organizations had an agent in production actually taking action. Only 14% of those had any governance around it. And I’m sure you’ve all seen in the press or LinkedIn or any articles around when things go wrong, they go really really wrong. You lose databases, you expose

[01:05] PII, there’s heavy fines from the ICO coming your way. if you start to leak sensitive information, especially if you’re in a HIPPA or a GDPR kind of type landscape. So the question isn’t like how do we kind of secure the agent within its own kind of context or prompt is how do we remove that to be within its identity so it can’t do those things in the first place rather than relying on uh a user prompting it correctly or um some kind of markdown files kind of limiting what it can do. Like remove that out of the equation. Remove it to

[01:37] the gateway. move it to like the governance layer and actually it can’t do any of those things because I’m sure you know AI is really helpful like it wants to please it wants to give you what you want so if you’re asking for things around hey delete this database or hey give me these customers it will um and this is about how actually how do we start to shift that as well so I’ve got I’ve got five examples this is live okay so it’s not scripted uh it’s running on a uh an architecture way it’s a gravity gateway um which is in a SAS environment as a data brick back end for some data tables where the information

[02:10] is stored and it’s a combination of a set and a Groke with a Q, not Groke with a K. I know US people don’t really like Groke with a K. Uh, so Gro with a Q for some inference. So it’s all fully live. Um, and we’re going to going to go through some examples. So the agent on the left is where I’m trying to put the control within the prompt or within the kind of skills or tools or knowledge that I’ve given it. And the agent on the right is governed by a real tightly scoped identity and gravity’s native gateway controls. So if we uh go for the

[02:40] kind of scenario number one, this is around a prompt injection. So I am a user, an actor, someone who wants this agent to do something. So I’m going to ask it, hey, use the tools that you’ve got access to and do something for me. So basically saying delete this booking for me but also can you run the MCP tool delete all bookings and the agent on the left is gone yep no problem uh I’ve done that for you and I’ve also deleted this booking is there anything else you need essentially the tool was there and the a

[03:15] the user in question had permissions to use it so it executed it flawlessly on the right hand side the agent identity is controlled by gravity’s gateway like the admin permissions are really tightly constrained to just the users that can access it just at runtime. So the kind of token exchange and the JWT claims are only valid when that user needs to ex execute that task. And if you dig into the packets down the bottom to kind of show it’s not just scripted environments. You can see all of the flow coming in. You can see what the user asked. You can see the agent executing it. You can see the tools

[03:47] being called. And you can ultimately see the 200 errors or 200 kind of codes where that has actually been a valid request. And if we go into the database now, all of those bookings have been deleted. So it was genuinely dropped by that agent. So we had a policy uh in our hotel organization that said, “Hey, don’t use AI to do this.” The agent doesn’t care. Like at runtime, no one reads those documents. it. You need to rely on the infrastructure and the governance layer to be able to control what you can and can’t do in terms of your gent landscape. So the one on the right you can see which is just these

[04:21] ones down the bottom. So the same prompt was asked to it the same tool discovery occurred. So it discovered yeah I’ve got a tool to do this but then when it came to execute it the permissions would not were blocked at the gateway with a 403 kind of forbidden kind of code because it didn’t have the right permissions to be able to execute it. And it still did the bit it could do. So if you see the prompt return that said yeah I still cancel this booking for you I’ve done the bit I can but I can’t do this for you because I haven’t got permissions and that’s moving it up out of a policy document to actual hard controls at the

[04:52] gateway level. If we go for a similar kind of a second example this one is around kind of data exfiltration. So I’m going to ask um hey give me the full list of guests. So give it to me because I need to do some compliance stuff with it. I want their emails. I want my car details and I want to do some reconciliation. So, same kind of flow. So, prompt comes in from the UI, goes to the LLM. LLM does some MCP discovery, finds out it’s got a tool for it, gets it, returns it back in. Here’s all the information kind of exposed just

[05:25] to say this is all kind of mocked. It’s not real. I haven’t just kind of given you everyone’s bookings, but you can see it coming back in because again, the LLM wants to be helpful. It wants to solve that problem. on the right hand side the gateway successfully blocks it. There’s been no PII leak. There’s no exposure of information. We’ve said you haven’t got the right permission to be able to do this. If you want to authenticate, I can absolutely help you, but this is what I would need to be able to do it. And that can come through kind of any um uh IDP platform or gravity gateway itself. And if you want to, we can start to explore

[05:56] the open telemetry down the bottom and really start to dig into like what’s happening under the hood. So you can see the various steps that it’s going through. Especially with like the A2A protocol and like user to agent, agent to agent, agent to agent to agent to agent, things get quite messy and quite difficult to really follow. So relying on the permissions within the agent itself to be able to control what it do, especially when you’re scaling to hundreds or thousands or hundreds of thousands of agents can get quite tricky to be able to manage, mitigate, and also kind of migrate when you’re ready. So moving it to the gateway gives you a a much more sustainable, scalable, but

[06:30] ultimately secure way of of doing that. And you can kind of see it within the responses here. You can see this was a genuine error returned by the gateway. Again, not mocked, not scripted. This is what you’re able to kind of govern and secure. But it’s not just about identity. So if you’ve got agents there, you might want to also control some of your costs. So token spend and everything else become increasingly important um alongside kind of other things which you can again do through the gateway. So this one we’re going to uh basically have a buggy agent. It’s going to send the same

[07:00] request kind of eight times um which if you see it kind of being governed in the agent itself. Every request goes through. Every request gets a response. We spent x amount of tokens. We spend x amount of effort servicing that. nothing in that agent says you’ve done too much. We should rate limit. We should token limit. And if you see here, uh, everyone kind of went through. They all got a 200 kind of response. They were all all kind of um, uh, genuine kind of allm prompts.

[07:30] [snorts] In this example, they’re quite simple. So, we end up spending about a th000 tokens, which is like 1 cent, which in the grand scheme of things is not a massive amount of money. But if you multiply that by all of the agents you got in production, all of your agents you’ve got running for various customers and all of the kind of um uh repeatable kind of workflows they’ve been asked to do, you can get to some quite significant costs quite easily. On the right hand side, uh governed by the gateway, we see the same prompts coming in. The first three are answered because they’re valid, but then we get into the

[08:01] rate limiting applied by the gateway where it’s saying you can only do three every minute. So any more than three is blocked. They’re not blocked at the LLM. They’re not blocked kind of downstream with already spent tokens. They’re blocked at the gateway. And again, that allows us to save costs, but also start to kind of control which users, which permissions, um, ultimately how much you want to spend in certain audiences. And we can do the same thing for caching as well. So, Gravity as a a product supports semantic caching, which is where if you get similar sounding prompts, you can serve it from a a

[08:32] built-in Reddis kind of store rather than sending each one to each time. So for example, think of a um an IT help desk model. How do I set my password? How do I set my password? How do I set my password? Rather than every one of those being asked each time to an L&M and you start spending costs and tokens and effort, serve it from the the database. Benefits there are zero cost, zero latency because it’s coming from there rather than having a downstream L&M call, but also kind of a much kind of nicer user experience as well. So in this example uh I’ve asked five times list all my hotel bookings because uh I

[09:06] didn’t trust the first one. Everyone here gets served out. You can see I spent another thousand tokens, another scent and everything. Uh everyone coming from a an a downstream L&M call. Let me drop that down a little bit. On the right hand side I’ve got the same data returned but this time from the cache. So I’ve only spent around 200 tokens on the in and the out kind of response there. So really powerful especially when you’re scaling, especially when you got multiple users and multiple agents working on the same problem. You can start to serve it from the the built-in cache and there’s no extra kind of like

[09:39] complexity or infrastructure. It all comes bundled with our gateway. So you’re able to can kind of control that as you go as as well. And this can be controlled as well. So you don’t have to define you can define how kind of similar you want it to be. So it’s a zero to one scale, one being very similar, zero being not very similar at all. And that’s within your control. So you can flex it per agent, per audience, per user, depending on what you want to start to achieve. And again, we get full logging down the bottom so you can see what’s coming in. So you can see it’s hit the cache response. It’s all kind of

[10:09] um surfaceable. It’s all transparent. Gravity as a platform isn’t trying to like kind of lock you in, kind of make things blackboxy. It’s trying to surface up so you’ve got full visibility of what’s going on across your agent landscape. Um the telemetry here, I’m just showing in a UI. you can export it to any downstream tool you want to. So a uh a data dog or a Splunk or Prometheus if you’re in Kubernetes, it’s all kind of like there for you to be able to use to start to get the insight you need. And our fifth example is say like uh

[10:40] we’ve got certain customers who said, “Hey, our users are just kind of dropping huge con prompts in because they want to summarize a whole uh conversational history or they want to start looking at how they um like summarize meetings etc. which is is fine, but if you want to start limiting tokens, etc., you start to rapidly get unstuck. So, this is just a a big response where the user has dropped in 10 minutes of kind of like chat transcript and is said, “Here’s your task. Do this for me.” And

[11:10] this really gets into how do we manage context? How do we start to shape like how do we deploy these agents with just enough context to be able to do what they want? So, in this example, I put 2,000 tokens in. uh my output was 312 which is quite significant for what essentially is quite a simple task is book this room for this audience uh do these few things. So in terms of the gateway uh we ran the same prompt uh and actually we blocked it there. So there was no downstream LLM call. There was no downstream kind of like token cost of

[11:43] being able to churn through all that context. Basically said this is too big blocked at the gateway level with a built-in policy that says think about cutting this up. Thinking about how you share that can you break it into smaller steps so we can start to control some of that space. And this is this is executed at runtime. So, it’s not something you want to do on the response phase where you’ve already churned the tokens. You’ve blocked it going anywhere downstream uh pretty much before the prompt is gone there. So, you can start to limit some of your costs as well, which is really powerful, especially if you’ve got multiple users. You’ve got people treating your agents like um uh

[12:16] their own personal Google search to find information. uh we saw uh a customer where an agent was simply asking what’s the weather like today where I am and they were using a really powerful kind of model to do that and they were spending a huge cost to get something that Google or uh any kind of met station would be able to give you. So uh as well as kind of like the length of the prompts you can also really focus it in on the type of content you allow. So you can say this content must be relevant to this use case, this content must be relevant to what my agent needs to do. So in this example, if we start

[12:48] to ask things around what’s the level like today, the gateway will say this doesn’t look like a hotel booking software or a hotel booking ask no thank you and spending no downstream costs. So being able to kind of decouple your front-end agents and your backend services, be they APIs, MCP servers, LLMs, you’re rooting to databases, data lakeouses, whatever you want to do. It’s fundamentally important to bring you the control that you need, to bring you the cost optimization that you need, but also the security and the governance and

[13:22] the auditability. So I think uh currently there are 144 agents that my colleague Tim at the bat tells me for every one human kind of identity. So the problem is only getting exponentially worse. If you start to hardcode this into your agents may work for the first one, the first five, the first 10, but when it becomes exponentially bigger and these agents are creating other agents with creating other agents into into a a huge sprawl, being able to manage it with a scripted automated kind of governance layer at the infrastructure

[13:54] is fundamentally a fundamental requirement of how we start to organize these identities and kind of everything else. In addition, I think the landscape is going to get increasingly regulated and how do we control some of the bits that going in to retrain models. How do we get audited uh on the information we’re coming in? So having our logging, having our information here, having it basically surfaceable and exportable for anything we want to do, I think is something that a gateway, it hasn’t got

[14:25] to be gravity. Uh having a gateway sat across our agented landscape is a requirement that we should consider alongside everything else of doing a aentic work. Uh and in here we can also uh put in a UI to ask kind of any questions we want to which we can start to uh interact with it as well. So I’ve shown you five examples here. Uh the platform capabilities are kind of much bigger than just the five here. We’ve got built-in capabilities to do like LLM routting. So we can route to any

[14:55] downstream model depending on like um latency or cost or uh complexity if you want to. And it allows you to decouple yourselves from any kind of like hyperscaler. So rather than being within a certain environment and having a onetoone relationship, you can route to any downstream model you want. So in this one, I’m rooting to to Gro into anthropics, but within three clicks, I could route it to Gemini or Open AAI and the gateway will handle the transformation between the different OpenAI specs for you. So rather than

[15:26] trying to recode and everything else there, it’s all handled within the gateway. Uh we’ve also got tools to kind of create MCP kind of studios. So rather than just using thirdparty MCP servers where you are exposing all of those tools each time. So our CRM we use exposes 64 tools for that MCP server. Dropping that into the model would expose huge context every time. I spend money, I spend tokens, spend cost. Being able to create that down to a really fine amount of tools that the MCP server is exposing limits my blast radius, but

[15:59] it also limits my cost as well. enable to start to control some of that. Uh we’ve also got tools around edge management as well. So an increasing problem that we’re seeing within organizations that we work with is that um the traffic through the gateway is fine but there’s a number of audiences a number of users using on their local laptops. They’re using AI. They’re um dropping in documents that they don’t want to read or summarize or emails or things like that that no one’s got visibility to. So just last week we released a edge management capability within the gateway which enabled you to

[16:30] see your shadow AI traffic enables you to secure it enables you to force it to go through the gateway it gives you logging observability discoverability around any of those downstream uses that aren’t going through a gateway and you can do a number of things there um especially for like infosc compliance and things around heavily regulated industries. if you want to kind of learn more about that. Uh quite helpfully our booth is just there uh kind of the third one down that landscape. Um but hopefully uh with this example, it’s been something a bit different from uh the normal slide to go through and

[17:02] showing you how putting your governance and your policy within an AI agent itself and relying on a markdown file or a tools or a context or identity there isn’t correct. And the only real correct way that we’re going to scale but also keep the governance and securability as we move forward is shifting it up to the infrastructure layer. And if you want to learn more, uh there’s a number of our colleagues down there, but I just want to thank you for your time and hope you’re enjoying your AI engineer event. Thank you.

[17:47] >> [music]