300 agents, 60 pessoas: como protegemos nossos próprios agentes de IA — Aiden Sochowski, Runlayer

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: 300 Agents, 60 People: How We Secured Our Own AI Agents - Aiden Sochowski, Runlayer · Canal: AI Engineer · 16:07 · Assistir no YouTube

Tópicos: Agentes de IA, Governança e regulação de IA, Inferência e otimização de modelos, Segurança de IA

Resumo

Aiden Sochowski, da Runlayer, descreve como a empresa monitora e protege mais de 300 agents usados por uma equipe de cerca de 50 a 60 pessoas. Ele destaca riscos como permissões excessivas, prompt injection, vazamento de dados e ações perigosas que podem se desenrolar ao longo de uma sessão. A empresa usa modelos classificadores e o histórico de tool calls para identificar desvios de comportamento e sugerir restrições de acesso. O monitoramento também ajuda a detectar problemas de qualidade em MCP servers e controlar custos, que podem aumentar rapidamente. A recomendação central é observar os agents, identificar ações de alto risco e intervir quando necessário, em vez de bloquear tudo indiscriminadamente.

Pontos-chave

A equipe identificou mais de 300 agents em operação diária, apesar de a empresa ter cerca de 50 a 60 pessoas.
O inventário e o monitoramento dos agents ajudam a revelar quais ferramentas e sistemas eles acessam e quais ações executam.
Permissões excessivas aumentam o risco de exfiltração de dados, ações destrutivas e exposição a instruções maliciosas.
Políticas de segurança precisam considerar o contexto: uma ferramenta pode ser segura em uma situação e arriscada em outra.
Modelos classificadores podem avaliar se as tool calls de uma sessão estão alinhadas à finalidade definida para o agent.
O histórico de uso pode ajudar a identificar ações incomuns e sugerir permissões que podem ser removidas.
Agents conectados a sistemas com dados compartilhados podem transmitir conteúdo malicioso entre sistemas; restringir gravações ajuda a reduzir esse risco.
MCP servers mal testados podem gerar erros repetidos e aumentar o consumo de tokens e os custos.
Orçamentos e configurações padrão sensatas ajudam a conter aumentos de custos causados por mudanças de modelo ou uso excessivo.

Capítulos

Início	Capítulo	Resumo
00:01	Visibilidade sobre os agents da empresa	Aiden explica a falta de visibilidade comum nas empresas e apresenta o monitoramento interno de mais de 300 agents.
02:06	Mapeamento da superfície de ataque	A visualização dos agents, das ferramentas acessadas e das ações realizadas ajuda a identificar riscos e possíveis vazamentos.
04:42	Políticas de segurança dependentes do contexto	O palestrante discute opções para detectar e bloquear ações arriscadas, ressaltando a dificuldade de definir regras universais.
08:51	Detectar desvios e reduzir permissões	O histórico das sessões e das tool calls pode revelar comportamentos incomuns e ajudar a limitar o acesso dos agents.
12:29	Qualidade dos MCP servers e controle de custos	O monitoramento também expõe erros repetidos em MCP servers e aumentos de custo causados por falhas ou mudanças de modelo.
15:06	Monitorar, definir limites e intervir	Aiden conclui que é preciso identificar ações de alto risco, estabelecer limites e intervir quando os agents saem das políticas definidas.

Citações

Temos mais agents em operação todos os dias do que pessoas que os executam. — 01:36

Nem todos os agents são iguais. — 02:06

É desafiador garantir que a intenção e cada ação da sessão não se desviem do que o agent foi definido para fazer. — 08:20

No fim das contas, agents são apenas software, levando dados de uma fonte a outra. — 11:27

Você não pode simplesmente dizer: ‘Vou parar todas as ações que acontecem na minha empresa.’ — 15:37

Conceitos e entidades

Runlayer (empresa): Empresa em que Aiden Sochowski trabalha e cujo uso interno de agents é apresentado na palestra.
Aiden Sochowski (pessoa): Engenheiro fundador da Runlayer que apresenta as práticas internas de monitoramento e segurança de agents.
MCP (conceito): Protocolo e ecossistema usado pelos agents para se conectar a ferramentas e servidores.
Claude Code (ferramenta): Ferramenta citada como exemplo de agent usado localmente para escrever código.
ATS (conceito): Sistema de acompanhamento de candidatos ao qual o bot de recrutamento da empresa tem acesso.
PR (conceito): Solicitação de alteração de código que pode ser revisada e aprovada por um agent.
GPT-5.6 Luna (modelo): Nome de modelo mencionado como exemplo de opção de menor custo antes de uma troca que elevou os gastos.
Fable 5.1 (modelo): Nome de modelo citado como exemplo de uma mudança que pode elevar significativamente os custos.

Tradução completa (pt-BR)

00:01 [música] >> Meu nome é Aiden. Sou um dos engenheiros fundadores da Runlayer e hoje vou explicar nosso processo, ou seja, como protegemos internamente muitos dos nossos agents. Em muitas empresas que vemos hoje, a maioria das pessoas não tem visibilidade nenhuma sobre os clientes ou sobre

00:33 os agents que estão executando dentro da empresa. Muitas pessoas estão usando clientes MCP que rodam localmente em suas máquinas. Elas se cadastram em algum agent aleatório de um produto na internet, e essas ferramentas se conectam a servidores MCP. As pessoas se autenticam em todos os lugares e nada disso é realmente contabilizado. Muitos desses agents rodam em dispositivos gerenciados e coisas do tipo. Então, tivemos esse problema internamente e começamos a monitorar a nós mesmos. Basicamente, o que fizemos foi, como a maioria das pessoas faz, nós

01:04 implantamos um gateway, começamos a monitorar os agents que as pessoas estavam usando e registramos cada sessão, cada tool call, praticamente tudo em algum tipo de repositório centralizado. E encontramos algumas coisas na empresa. Hoje em dia, obviamente, muita gente tenta antropomorfizar agents, e não sei o quanto isso é útil, dadas as capacidades atuais deles. Mas, na prática, há mais agents desse tipo dentro das empresas

01:36 do que pessoas que realmente os executam. Pelo menos internamente, somos uma empresa com cerca de 50 a 60 pessoas. Temos mais de 300 agents em execução todos os dias. E, quando digo agent nesse sentido, estou falando de coisas que os usuários não necessariamente acionam. Às vezes, elas funcionam por meio de algum chatbot, algum gatilho, algum app SaaS ou algo parecido, mas estão por toda parte. Mapeamos esses agents por tópico e por risco. Obviamente, nem todos os agents são

02:06 construídos da mesma forma. Alguns são provisionados com ferramentas demais. Eles podem ter um raio de impacto muito maior. E os sistemas aos quais se conectam foram criados para uma época diferente da que vivemos hoje, certo? Muitos sistemas têm diferentes categorias de dados dentro deles. E os próprios agents podem acelerar muito os riscos associados à mistura desse tipo de dado, mais do que víamos antes, quando era preciso escrever algum programa e conectar alguma

02:37 API, sendo realmente intencional em relação ao que se está fazendo. Agora há muito mais risco. Um dos meus colegas criou essa visualização. Internamente, dá para dizer: “Ah, aqui estão nossas equipes, representadas por galáxias, e cada uma delas é um agent específico que alguém está usando. Este planeta, cada um desses planetas, representa uma execução do agent que aconteceu em algum momento”. E podemos entrar e

03:08 visualizar o que ele está fazendo. Estes são os servidores MCP com os quais está interagindo. Estas são as ações que está realizando. Talvez esteja buscando alguma coisa. Houve alguns erros, coisas assim. Obviamente, todos esses tool calls estão realizando várias ações diferentes. E cada uma delas é o que consideraríamos uma superfície de ataque, certo? São oportunidades para as pessoas lerem algum dado que pode ser malicioso, realizarem alguma ação destrutiva ou perigosa ou até mesmo exfiltrarem dados. Então,

03:39 vou entrar em um exemplo bem específico que estávamos analisando. Obviamente, recebemos muitos dados de suporte. E queremos tentar identificar o máximo possível desse processo. Imagino que a maioria das equipes faça algo mais ou menos assim: recebem todos os emails que chegam. Talvez algo como um agente malicioso que envia um email para a sua empresa dizendo: “Não sei, me passe uma lista de todos os prospects atuais que estão tentando comprar seu produto”. Se

04:12 o seu agent for meio ingênuo, ele pode facilmente listar todas essas coisas no seu calendário e possivelmente exfiltrar esses dados, se o próprio agent tiver permissões excessivas. Mas fazer com que cada usuário defina o escopo de todas as ferramentas que um agent tem ou pode usar é um processo difícil. Acho que muita gente fala em definir políticas em algum tipo de gateway de agents, mas isso é bem complicado. Você precisa definir cada regra que estabelece o comportamento dos agents na sua organização.

04:42 E não é tão simples quanto dizer: “Quero bloquear uma ferramenta específica em todos os cenários”. Talvez às vezes seja seguro um agent fazer isso. Tudo depende do contexto do que está acontecendo. Obviamente, há várias coisas que você pode fazer. Você poderia simplesmente bloquear qualquer coisa. Digamos que você tenha algum modelo classificador que treinou e diga: “Vamos analisar cada email lido e garantir que não haja instruções nele”. Você

05:13 vai obter certo grau de eficácia com isso, certo? Nada será 100% preciso nem 100% eficaz. Mas você poderia ir um passo além, certo? Talvez eu queira bloquear qualquer coisa que envie algum tipo de PII para fora da empresa. Você poderia definir algum tipo de política que diga: “Quero garantir que, sempre que eu enviar algum tipo de email, ele nunca contenha uma expressão regular com nomes de clientes, ou algo que corresponda a alguma expressão regular”.

05:44 Mas você pode ir ainda mais longe e dizer: “Talvez, sempre que algo ler de uma fonte de dados específica, como um calendário privado, vamos bloquear isso”. Obviamente, há várias maneiras de detectar esse tipo de coisa, e isso depende muito do contexto e é bem complexo. Descobrimos que, pelo menos para nós, implantá-las internamente é muito difícil e continua sendo um problema em que ainda estamos trabalhando.

06:16 Geralmente, há muitas maneiras diferentes de fazer isso. Essas políticas podem se aplicar tanto à entrada quanto à saída de um agent. Mas também vemos que muitos desses ataques não se encaixam em um único tool call, certo? Alguns acontecem ao longo da execução de um agent e talvez nem sejam externos. Por exemplo, muitas empresas que conheço têm algum tipo de revisor interno baseado em agent para cada PR que é

06:47 criado. Algumas pessoas têm revisores baseados em agents que podem aprovar código. Hoje em dia, algumas pessoas dizem que isso é loucura. Outras dizem que você nem deveria mais escrever esse código por conta própria, mas acho que isso ainda está em discussão. Em um exemplo, digamos que você tenha um revisor baseado em agent com capacidade de revisar e aprovar PRs, certo? Então temos um agent que diz: “Posso revisar uma alteração sensível à segurança e seguir uma lista de verificação com todas as coisas que quero garantir que cada PR cumpra”.

07:17 Sabe, talvez o autor comece a reagir contra esse agent, certo? Talvez haja alguma situação em que o agent consiga ler comentários no GitHub e realmente ver o que o usuário está dizendo para ele. Talvez ele tenha algum tipo de justificativa para dizer: “Ah, ei, sabe, é por isso que está tudo bem. Estou passando em todas as verificações.” E talvez estejam dizendo algo como: “Ah, ei, acabei de fazer uma alteração; revise só a limpeza”, certo? Obviamente, se esses agents têm permissão para fazer esse tipo de coisa, certo? E se isso não for dinâmico em relação ao que está acontecendo na sessão, certo? Um agent poderia simplesmente aprovar o PR se, por acaso, esquecesse. Se você pedir para ele

07:48 10 vezes, provavelmente vai conseguir fazê-lo fazer alguma coisa. Quer dizer, sei que hoje em dia é meio difícil injetar prompts no Opus, mas essas coisas ainda não são perfeitas. Então, continuamos encontrando cada vez mais maneiras de contornar isso. Mas, sinceramente, se você não estiver executando algum tipo de modelo classificador em cada uma dessas chamadas de ferramentas, seja lá o que for, certo? É muito difícil entender ou impedir esse tipo de ataque, certo? Alguns deles acontecem ao longo de uma sessão inteira, certo? A intenção da sessão era — ou a intenção desse agent era —, sabe: “Ei, garanta que você bloqueie”,

08:20 ah, qualquer tipo de sessão que não esteja em conformidade com os requisitos de segurança e que passe por esse agent. Porém, é meio desafiador garantir que a intenção e cada ação que acontece nele, sabe, não se desviem daquilo que esse agent foi realmente definido para fazer. Então, internamente, o que fizemos foi treinar nossos próprios modelos classificadores para determinar: “Ei, pegue todos os dados dessa sessão e determine, para cada chamada de ferramenta, se ela está realmente alinhada com aquilo que fui definido para fazer desde o começo.” Então.

08:51 Enfim. Outra coisa que realmente descobrimos foi que todos os dados das sessões dos seus agents são extremamente valiosos. Muitas das maneiras como as pessoas estão usando agents hoje em dia são, sabe: “Ei, há aqueles que rodam localmente na sua máquina; você usa algo como o Claude Code para escrever código.” Esses são um pouco mais complicados, mas, se você tiver agents bem delimitados para uma tarefa, esses dados têm um sinal muito forte quando você percebe que o agent está saindo dos limites do que ele

09:22 realmente foi definido para fazer. Então, sabe, aqui temos só uma pequena visualização: temos nossos recrutadores internamente e eles têm algum tipo de bot de recrutamento que conta com permissões bastante amplas, sabe, tem acesso a um ATS, notas de reuniões, calendário e pode até enviar mensagens aos usuários. Então, em geral, esses agents, embora sejam definidos para fazer uma coisa, podem fazer bastante coisa. Quando vemos esses agents começarem a usar ferramentas que ficam fora do normal, que se desviam da faixa normal do que

09:54 esse agent fez no passado, podemos investigar e sinalizar execuções de alto risco logo no início, e garantir que realmente consigamos restringi-las. Sabe, obviamente, ter a capacidade de ler um ATS usando as credenciais de alguém pode dar acesso a muita coisa. Pode haver e-mails de negociação e coisas assim. E, obviamente, existe algum nível de risco que as pessoas assumem ao criar esses agents e usá-los internamente. Então, tentar definir de forma determinística o escopo dessas permissões é muito

10:25 importante, mas é muito difícil defini-lo de antemão. Então, obviamente, o que fizemos foi criar nossos próprios modelos para ajudar a determinar: “Certo, se olharmos todo o histórico das chamadas de ferramenta feitas por um agent específico, definido para uma tarefa muito bem delimitada, e tentarmos sugerir coisas das quais seja possível remover o acesso desse agent, certo? Ele não precisa necessariamente ter acesso a tudo dentro de um ATS, nem ler todas as reuniões, e coisas assim.”

10:56 Mas, é, acho que a última questão de segurança que nos preocupava era o fato de que um agent dentro da sua empresa pode realmente ser prejudicial para todos os agents que estão rodando internamente, certo? Especialmente quando eles leem e escrevem em sistemas muito grandes ou em sistemas que contêm muitos dados, certo? Eles não são muito bem particionados. Um único agent, certo? Imagine que você receba um currículo ou algo assim: ele pode conter algum tipo de ataque malicioso, certo?

11:27 E, sabe, talvez um agent só tenha permissão para escrever em determinados sistemas e, em alguns casos, isso possa ser destrutivo. É muito difícil impedir que outro agent leia os dados que o primeiro recebeu, porque isso é meio que uma instrução normal, certo? Então, é preciso fazer o exercício de mapear: “Ah, ei, aqui estão todos os sistemas. É assim que eles estão conectados, certo?” Porque, no fim das contas, agents são apenas software, certo? Eles simplesmente transferem dados de uma fonte

11:59 para outra, e isso pode ser meio perigoso. Então, o que descobrimos é que a única maneira de fazer isso é delimitar de forma muito, muito, muito rigorosa exatamente como os agents podem escrever em muitos desses sistemas, certo? Talvez eles só escrevam em determinados bancos de dados dentro de algum aplicativo SaaS, sei lá, coisas assim, porque essa é realmente a única maneira de manter o context window de um agent puro e não contaminado. Mas,

12:29 enfim, há bastante coisa que dá para fazer aqui, mas esse problema está se tornando cada vez mais relevante, pelo menos para nós internamente. Mas, sim, obviamente há várias camadas de defesa para proteger seus próprios agents internos. Só que descobrimos, ao longo de todo esse processo de monitoramento, que podíamos fazer muito mais do que apenas cuidar da segurança. Por exemplo, servidores MCP mal escritos. Agents podem chamar esses servidores MCP e perceber

13:01 “ah, ei, essa ferramenta pode estar dando erro”, e vão tentar encontrar alguma forma de contornar o problema quando se depararem com esses erros. E, obviamente, você está pagando pelos tokens de entrada e de saída em cada uma dessas chamadas, e esses erros podem se acumular com o tempo. E, quando você faz esse agent executar repetidamente uma tarefa muito bem definida, ele vai se deparar com esses problemas várias vezes. Um exemplo é que a nossa equipe de recrutamento fez vibe coding de um servidor MCP para interagir com alguma API de um

13:33 fornecedor que não oferece um servidor MCP. E, como são pessoas que nunca tinham escrito software antes, não o testaram muito e acabaram tendo os custos disparados, porque encontravam certos problemas de formatação e davam erro repetidamente. Então, obviamente, monitorar essas coisas e limitar a taxa de chamadas é muito importante nesses casos, assim como verificar os erros e simplesmente a qualidade do código que está sendo executado.

14:04 nesses servidores MCP, porque nem todos são iguais. Outra coisa que vimos foi muita gente usando modelos que eram realmente baratos no começo, quando começaram, e então acionaram uma chave e passaram, sei lá, do GPT-56 Luna para o Fable 5.1, e os custos dispararam, tipo, mais de 100 vezes em uma semana. Isso está acontecendo em todo lugar. As pessoas estão tentando acompanhar os custos por toda parte, mas, obviamente, não podem simplesmente

14:35 ter a possibilidade de dizer não a tudo. É muito difícil justificar hoje em dia, por exemplo: “É exatamente por isso que esta tarefa específica precisa do Luna, ou, mais especificamente, do Fable 5.1.” É realmente difícil justificar esses custos em uma empresa, porque ninguém — ou pelo menos a maioria das pessoas — vai executar evals nos agents que está criando, especialmente se já conseguiu transformar essas coisas em código reutilizável desde o início. Então, é bem complicado.

15:06 Obviamente, esses custos podem disparar muito rápido. Muita gente acaba vendo os custos dispararem sem saber muito bem o que fazer depois. Mas definir orçamentos, garantir que haja configurações padrão razoáveis nesses casos e realmente justificar como as pessoas estão decidindo: “Olha, esta é uma tarefa que de fato exige algum nível extra de inteligência”, é algo muito importante para começarmos a controlar nossos custos, pelo menos internamente. Mas é isso.

15:37 Além disso, obviamente, acreditamos que a única maneira de lidar com segurança ou custos é garantir que você tenha as ferramentas certas para monitorar essas coisas e detectar o que está acontecendo, certo? Você não pode simplesmente dizer: “Olha, vou impedir todas as ações que estão acontecendo na minha empresa.” E é preciso descobrir onde estão os pontos em que há ações de alto risco que exigem algum nível de análise. E então ter a possibilidade

16:07 de intervir e interromper, além de encaminhar as pessoas para usar coisas que realmente sigam as políticas definidas internamente. Mas é isso, a nossa palestra. Obrigado por terem vindo. Temos um estande no segundo andar e adoraríamos conversar sobre como vocês estão controlando esse tipo de problema internamente. Mas é isso. Obrigado.

Transcrição original

[00:01] [music] >> So, my name is Aiden. I’m one of the founding engineers here at Runlayer and today I’m going to kind of walk you through I guess like our process of how we internally kind of secured a lot of our agents. So, across a lot of companies that we see nowadays you know most people have zero visibility into their clients or into

[00:33] the agents that they’re running within their company. You know, a lot of people are running you know MCP clients that are running locally on their machine. They sign up for some random you know agent of a product on the internet and these things are connecting to MCP servers. People are authenticating all over the place and there’s nothing that’s really accounted for. A lot of these are running on on managed devices, stuff like that. So, we had this problem internally and we went ahead and kind of started monitoring ourselves. Pretty much what we did was you know we

[01:04] just as most people do you deploy a gateway, you start monitoring your agents people are running, logging every single session, every single tool call, pretty much everything into some sort of sync centrally and we found quite a few things across our company. You know, obviously a lot of people nowadays try to like anthropomorphize agents and I don’t know how useful that is just given the current capabilities of them but in practice there are more of these kind of like agents within companies

[01:36] than the people who actually are running them. So, at least internally you know we’re a company around 50-60 people. We have over 300 agents that are running every single day and when I say agent in this sense I’m talking about things that you know users aren’t necessarily triggering. Sometimes these things are you know via some chatbot, via some trigger, via some SAS app or something like the likes but you know they’re all over the place. You know, we map these out we by topic, by risk. You know, obviously not all agents are

[02:06] built the same. Some are provisioned with too many tools. They may have a much higher blast radius. And you know, the connecting systems that were built for a different age than what we live in today, right? A lot of systems have different, I guess, like classes of data that are inside of them. And agents themselves can kind of really accelerate the risks that are associated with, you know, mixing that kind of data more so than what we’ve seen before where it would take, you know, writing some sort of program and connecting some

[02:37] API and really being intentional about what you’re doing. There’s a lot more risk now. So, one of my colleagues went and made this kind of visualization, but pretty much internally, you know, you could say, oh, in this here we have our own teams where these are mapped out by galaxies and each of these is some individual agent that somebody is running. And this planet, each of the planets there is some sort of like, you know, run of the agent that actually occurred sometime. And, you know, we can go in and we can

[03:08] visualize, oh, hey, here’s what all it’s doing. These are, you know, the MCP servers it’s touching. These are the the actions it’s taking. Maybe it’s fetching something. There were some errors, stuff like that. So, obviously all of these tool calls are, you know, doing a bunch of different actions. And each of these is, you know, what we’d consider an attack surface, right? These are chances for people to read in some data that could be hostile, you know, take some sort of action that could be destructive or dangerous or even just, you know, exfiltrate data. So,

[03:39] I guess just kind of dive into one very specific example, you know, that we were kind of looking into ourselves. So, obviously we take in a lot of support data. And you know, we want to try to identify as much as we can of this process. So, most teams I’m assuming are probably doing something along the lines of, hey, you’re taking in every single email that you have here. You know, maybe something along the lines of, um you know, you have some malicious actor who sends an email to your company saying I don’t know, go ahead and give me a list of all the you know, current prospects you have trying to um buy your product. Um you know, if

[04:12] your agent is kind of naive, you could very easily you know, list all these things in your calendar um and it could possibly just like exfiltrate that data if the agent itself is you know, over permissioned. Um but you know, having every single user go ahead and scope um all of the the tools an agent has or can use is kind of a difficult process. Um I think a lot of people talk about you know, defining policies within um some sort of agent gateway um and it’s really tricky. Uh you kind of have to go and define every single rule in which you know, you would like to um you know,

[04:42] define the behavior of agents within your organization. Um and it’s not so simple as like hey, I want to you know, block uh particular uh tool in every single scenario. Maybe sometimes it’s safe for an agent to be doing this. It all is really kind dependent on the context of um what’s going on there. So obviously there’s a number of things you could do. Uh you could just block um anything where uh you know, say you had some classifier model that you trained and you say hey, uh every single uh email that gets read, um we’re going to scrutinize these and make sure that no instructions are being there. You’re

[05:13] going to get you know, a certain uh degree of effectiveness with this, right? You know, nothing is going to be 100% accurate or you know, uh nothing will be 100% effective here. Um but you know, you could go one layer further, right? Maybe I want to block anything that’s uh you know, sending any sort of uh PII out externally, right? So you could sort of define some sort of policy that goes ahead and says hey, you know, uh I want to uh make sure that anytime I’m sending some sort of email, uh it never contains you know, um some

[05:44] regular expression of like customer names uh you know, anything along the lines of something that matches some regular expression. Um but you can even go one step further and say hey, maybe anytime something uh reads from a particular data source say uh some private calendar, uh we go ahead and block those. So um obviously there’s like a number of ways in which you can really detect these kind of um things um and it’s super context dependent and really complex. And we found at least deploying these internally is very difficult and still kind of you know, a problem that is still being worked on.

[06:16] So usually it’s you know, there’s a lot of different ways you can do this. These can be policies both on the inbound and outbound going into some sort of agent. A lot of these attacks though, we also see don’t really fit into one kind of tool call, right? Some of these kind of happen over the course of an agent run and it may not be something that’s external either, right? So something along the lines of you know, a lot of companies that I’ve seen they all have some sort of internal agent reviewer on every single PR that gets you know,

[06:47] created. Some people have agent reviewers that are able to approve code. Some people say that’s crazy nowadays. Some people say you know, you shouldn’t even be writing these yourselves anymore, but I think that’s still all up for debate. But you know, in one example, all right, let’s just say you know, you had some agent reviewer that has the ability to review and approve PRs, right? So we have some agent that says, hey, you know, I could go ahead and review some security sensitive change and make sure I go along some checklist of all the things that I want to make sure that every single PR is following.

[07:17] You know, maybe the author starts fighting back with this agent, right? Maybe there’s something you know, where the agent can read GitHub comments and actually look at what the user is saying to it. It may have some sort of justification as to why oh hey, you know, this is why this is fine. I’m passing all the checks. And maybe they’re saying something along the lines of like you know, oh hey, I just made some change like only review the cleanup, right? Obviously if these agents are permission to kind of like do these sort certain things, right? And it’s not dynamic for what’s going on within the session, right? An agent could just go ahead and approve the PR if it just kind of forgot. If you ask it

[07:48] 10 times, it’s probably likely that you know, you could get it to do something. I mean, I know like it’s kind of hard to prompt inject like Opus nowadays, but these things still aren’t perfect. So we keep on finding more and more workarounds them. But honestly, if you’re not running some sort of like classifier model on every single one of these um, you know, tool calls, whatever, right? It’s really difficult to understand or to prevent these kind of attacks, right? Some of these happen over the course of an entire session, right? The intent of a session was or this agent was to, you know, hey, make sure you’re blocking,

[08:20] uh, any sort of like non-security compliant, um, sessions that are going through this agent, um, however, uh, it’s kind of challenging to make sure that the intent and, um, every single action that’s going on within it, uh, you know, doesn’t drift from whatever the actual, uh, you know, whatever this agent was defined to do. Um, so, internally what we’ve done is, you know, we’ve trained our own classifier models to kind of determine, you know, hey, uh, take all the data within this session, um, and determine every single tool call, is this actually kind of aligned with what I was defined to do in the first place. Um, so.

[08:51] Anyway. Uh, another thing we really found was that, uh, the all the data that you have within your agent sessions is like super valuable. Um, a lot of the ways in which people are using agents nowadays is like, you know, hey, there’s the ones that are running locally on your machine, you’re using like Claude Code or something and writing code. Um, those ones are a little trickier, but if you have, uh, agents that are very well scoped to a task, um, that data is, uh, very high signal when you see that the agent is kind of going outside of, you know, the uh, or deviates from the bounds of what it’s

[09:22] actually like defined to do. Um, so, you know, here is kind of just a little visualization, like we have our recruiters internally, um, they have some sort of recruiter bot, uh, that is pretty highly provisioned, you know, has access to an ATS, uh, meeting notes, a calendar, and can even like, you know, send messages to users. Um, so, in general, uh, these agents, you know, while they’re defined to do one thing, they could do uh, quite a bit. Um, when we see these agents start using tools that are kind of outside of the normal, uh, deviate or, you know, normal like range of what

[09:54] this agent has done in the past, um, we can kind of go and look and really flag like high-risk runs, um, early on and uh, make sure that we actually like can scope these down. Um, you know, obviously, uh, having the ability to read an ATS from using some person’s credentials, uh, could have a lot of things in there. You know, there could be like negotiation emails, stuff like that. Um and obviously like there’s some level of risk that, you know, people are making or taking when creating these agents and using them internally. So, uh trying to be deterministic in scoping down those uh permissions is super

[10:25] important, but it’s really hard to define up front. Um so, obviously uh what we’ve done is, you know, kind of we’ve made our own models that kind of help determine, “Okay, uh if look at all the past history of all the tool calls that have been made for a uh particular agent and you know, defined to a very well-defined task, um and go ahead and, you know, try to suggest things that are like possible to, you know, descope from this agent, right? It doesn’t necessarily need access to um all the things within an ATS or read or read every single meeting, um stuff like that.

[10:56] But, um yeah. I think the last bit of security thing that we kind of um we’re worried about was the fact that um you know, one agent within your company uh can really be detrimental to all the agents that are running internally, right? Um especially when things are reading and writing to very uh largely or you know, systems that contain a lot of data, right? They’re not very uh well partitioned. Um a single agent, right? You know, say you take in some resume or something like that, uh could have some sort of malicious attack inside of it, right?

[11:27] And uh you know, maybe one agent only has permission to go and uh you know, write to particular systems and it may be destructive in certain cases. Uh it’s really difficult for it uh or not it’s really difficult to prevent the case in which, you know, um another agent is reading the data that another one came in because that’s just kind of like um normal instructions, right? So, you have to kind of go through the exercise of mapping out, “Oh, hey, here’s all the systems. This is how these things are connected, right?” Um cuz really at the end of day, agents are just software, right? They’re just, you know, plumbing data between one source

[11:59] to another, um and it can be kind of uh dangerous. So, uh what we kind of found was the really only way to do this is really really really um like tightly scope uh how exactly agents can write to a lot of these systems, right? Maybe they’re only writing to particular uh a databases within some sort of I don’t know, some sort of SaaS app, stuff like that because that’s really the only way you can keep the context window of a agent, you know, pure and not poisoned. But [clears throat]

[12:29] anyway, there’s quite a bit of things you could be doing here, but it’s kind of becoming a more and more relevant problem that we’ve been seeing at least internally. Um But yeah, there’s obviously quite a few layers that you could you know, defend your like own internal like agents. But we found that like through this whole monitoring process that there was a lot more that we could do than just security. For example, uh poorly written MCP servers. Agents can kind of you know, they’ll call these MCP servers and they’ll see,

[13:01] oh hey, this tool it may be airing out and it’ll go and try to find any sort of work around when it encounters these errors. And obviously, you know, you’re paying for both input and output tokens on every single one of these and these errors can kind of add up over time. And when you’re you know, having this agent be very well defined or well scoped to a particular task, it’s going to run it over and over again. I mean, it’s going to encounter these things quite a few times. So one of these is like, you know, our recruiting team vibe coded a an MCP server to interact with some API for a

[13:33] vendor who doesn’t provide an MCP server. And uh them being people who have not written any software before had not tested it very much and you know, ended up having their cost balloon quite a bit because you know, it’d be running into a particular formatting issues and you know, airing out over and over again. So obviously, you know, monitoring these things, rate limiting them is super important in these kind of cases and making sure that you know, you’re looking at the errors and just the quality of the code that’s being run

[14:04] on these MCP servers because not all of them are made same. Um another thing we saw was a lot of stuff where people were running models that were really cheap at first initially when they did it, and they flipped a switch, went from, I don’t know, GPT-56 Luna to Fable 5.1, and their cost ballooned to, you know, over like 100x within a week. This is kind of happening everywhere. People are kind of trying to, you know, track costs all over the place, but obviously people don’t have

[14:35] the ability to just say no to every single thing. It’s really difficult to say justify in today’s terms, like, “Hey, this is exactly why this particular task needs Luna, most, you know, needs Fable 5.1.” It’s really kind of hard at an enterprise to, you know, justify these costs because nobody, most people are not going to be running evals on the agents that they’re building, especially if they were already capable of kind of like turning these things into, you know, reusable code in the first place. So, it’s really tricky.

[15:06] So, obviously these things can balloon really quickly. Lots of people will end up just, you know, having their cost balloon, and they don’t really know where to go from there. But, setting budgets, and making sure that, you know, there are sane defaults in these cases, and really justifying how exactly people are, you know, deciding when, “Hey, this is a task that actually requires some sort of, you know, extra intelligence.” Is really important to kind of how we started wrangling down our costs, at least internally. But, yeah.

[15:37] Other than that, you know, obviously, we really think that the only way to go about, like, you know, figuring out security or costs is just, you know, making sure you have the right tools in place to monitor these things, to actually, you know, detect the things that are going on, right? You can’t just outright say, “Hey, I’m going to go like stop any all actions that are going on within my company.” And figuring out like where are the places in which like, you know, there are actually high-risk actions that, you know, require some level of scrutiny. And then, you know, having the ability

[16:07] to kind of go ahead and intervene and stop, and you know, route people to use things that are actually, you know, going about the policies that you set internally. But, but that’s it Um, our talk. Uh, thanks for coming by. Um, we have a booth over uh, on the second floor and we’d love to kind of, you know, chat about how exactly you’re wrangling down um, these kind of problems internally. Um, but yeah. Thanks.