A segurança de runtime para agentes da Arcjet leva o controle ao ciclo de ação da IA
A Arcjet lançou a segurança de runtime para agentes em 17 de setembro, adicionando controles em tempo real para agentes de IA depois que entram em produção. O produto mira uma lacuna entre monitorar um agente e interromper sua próxima ação. Essa distinção importa quando agentes podem enviar mensagens, atualizar bancos de dados, emitir reembolsos ou chamar ferramentas internas.
O lançamento da segurança de runtime para agentes da Arcjet ocorre enquanto fornecedores de segurança competem para controlar essa nova camada de execução. Gateways inspecionam tráfego, sistemas de identidade autenticam atores e plataformas de observabilidade registram atividades. A Arcjet, por sua vez, quer inserir verificações de políticas no caminho da aplicação, onde a ação proposta por um agente ainda pode ser bloqueada.
Essa arquitetura oferece aos desenvolvedores mais contexto para cada decisão. Ela também exige que coloquem código de aplicação das regras em torno de ações consequentes. A principal aposta da Arcjet é que organizações aceitarão esse trabalho de integração porque controles externos não conseguem enxergar detalhes suficientes da aplicação.
O produto combina descoberta de agentes, aplicação de regras no nível da ação e registros de auditoria. A Arcjet afirma que as equipes podem observar agentes por meio da telemetria existente e, depois, adicionar verificações preventivas por meio de kits de desenvolvimento de software e integrações com frameworks.
Portanto, o lançamento não é mais uma promessa genérica de tornar modelos mais seguros. É uma tentativa de definir onde começa a responsabilidade quando a saída de um modelo se transforma em uma operação real.
A segurança de runtime para agentes da Arcjet adiciona três camadas de controle
A Arcjet está combinando visibilidade, prevenção e evidências em um único fluxo de trabalho de produção.
A primeira camada é a observação. A Arcjet afirma que organizações podem enviar a atividade dos agentes por meio do OpenTelemetry, um padrão aberto para coleta de rastros, métricas e logs. Equipes que usam Claude também podem se conectar pela Compliance API da Anthropic.
Esse processo de ingestão cria um inventário de agentes e aplicações. A Arcjet então associa sessões individuais ao agente que as produziu. Investigadores de segurança podem revisar um fluxo de trabalho mais longo em vez de pesquisar prompts e chamadas de ferramentas desconectados.
A abordagem depende parcialmente do uso crescente de telemetria padronizada. O projeto OpenTelemetry vem desenvolvendo convenções de observabilidade de agentes para reportar tarefas de agentes, atividade de frameworks e interações com modelos.
Essa padronização pode reduzir o trabalho necessário para descobrir agentes em diferentes frameworks. No entanto, a observação por si só não impede uma operação insegura. Ela registra o que ocorreu e fornece contexto para análises posteriores.
A segunda camada é a aplicação de regras. A Arcjet insere uma decisão de política antes que um agente chame uma ferramenta, banco de dados, interface de programação de aplicações ou modelo. A aplicação recebe uma resposta tipada, como permitir, bloquear, ocultar ou reter para revisão.
Uma resposta tipada é um resultado estruturado que o código da aplicação pode processar de forma consistente. Ela permite que o fluxo de trabalho interrompa uma ação, solicite aprovação humana ou devolva uma explicação ao agente.
A Arcjet também oferece suporte a verificações após uma chamada. Essas verificações podem inspecionar um resultado antes que outra etapa do fluxo de trabalho o utilize. Isso cria controles tanto em torno da ação proposta quanto das informações retornadas por ela.
Segundo a empresa, as políticas disponíveis cobrem injeção de prompt, exposição de dados sensíveis, abuso de automação, limites de taxa e cotas de recursos. A injeção de prompt ocorre quando conteúdo não confiável manipula um modelo para seguir instruções hostis ou não intencionais.
A terceira camada é a auditoria. A Arcjet registra a decisão, a versão da política, o ator, as entradas e o contexto relacionado da execução. Esse registro busca mostrar o que um agente tentou fazer e por que o sistema permitiu ou rejeitou a ação.
O anúncio de lançamento corrigido da empresa descreve o produto por meio dessas três funções: observar, aplicar e auditar. O anúncio afirma que as políticas podem operar antes e depois de chamadas envolvendo modelos, ferramentas, bancos de dados e APIs.
Esse design aborda um problema operacional específico. Um agente de suporte pode ler um e-mail, consultar um banco de dados de clientes e preparar uma resposta. Cada etapa pode parecer inofensiva quando analisada isoladamente.
Ainda assim, a sequência combinada pode expor informações pessoais a um endereço adicionado por um invasor. A Arcjet tenta preservar as etapas anteriores e avaliar a mensagem de saída dentro desse histórico.
O fundador e diretor-executivo David Mytton disse ao SiliconANGLE que um resultado arriscado pode surgir ao longo de várias ações individualmente razoáveis. A cobertura original do lançamento também relatou integrações com vários dos principais frameworks de agentes.
Essas integrações incluem o Claude Agent SDK, OpenAI Agents SDK, LangChain, Mastra e o Agent Framework da Microsoft. A página mais ampla de produtos da Arcjet afirma oferecer suporte a 20 SDKs e integrações com frameworks.
Essa abrangência importa porque implantações de agentes raramente usam um único runtime comum. Organizações podem ter agentes web, workers de fila, assistentes de programação e fluxos de trabalho agendados operando por interfaces diferentes.
O produto da Arcjet tenta conectar esses ambientes por meio de um modelo de decisão compartilhado. A mudança mais importante não é a tela de inventário. É a capacidade de inserir uma decisão obrigatória antes que uma ação seja executada.
O limite de segurança está migrando do acesso para a ação
Um agente autenticado ainda pode tomar a ação errada com credenciais válidas.
O controle de acesso tradicional pergunta se uma identidade pode entrar em um sistema. Isso continua necessário, mas se torna incompleto quando o software pode interpretar objetivos e selecionar ações de forma autônoma.
Um funcionário pode autorizar um agente a usar uma plataforma de atendimento ao cliente. Essa permissão não significa automaticamente que o agente deva reembolsar todas as transações que encontrar. O valor permitido, a conta, o método de pagamento e a solicitação ao redor ainda importam.
O mesmo problema aparece em fluxos de trabalho de programação. Um agente de programação pode ter acesso legítimo ao repositório, mas não autoridade para expor segredos, alterar configurações de implantação ou executar comandos destrutivos.
O acesso permanente estabelece um limite externo. Ele não confirma que cada ação dentro desse limite reflita a intenção atual do usuário.
O Google descreveu uma mudança semelhante em seu framework Beyond Zero de 2026. A proposta avalia a autorização no nível de ações individuais sobre recursos específicos, em vez de conceder amplo acesso à aplicação.
A Arcjet busca uma versão mais restrita e implantável dessa direção. Ela verifica a ação usando o contexto disponível dentro da aplicação. Esse contexto pode incluir identidade, rota, nome da ferramenta, argumentos tipados, etapas anteriores e uso acumulado.
Considere um agente de contas a pagar que pode acessar um sistema de planejamento de recursos empresariais. Ler uma fatura e liberar um pagamento ocorrem dentro da mesma aplicação. Suas consequências diferem substancialmente.
Um gateway de rede pode reconhecer tráfego direcionado a essa aplicação. Ele pode não entender se a função subjacente lê um registro de fornecedor ou altera dados bancários.
Uma verificação no código pode inspecionar a função e seus argumentos. Ela pode aplicar uma política à leitura de uma fatura e outra à liberação de fundos.
Essa distinção explica o posicionamento da Arcjet contra planos de controle externos. Um gateway pode centralizar roteamento de modelos, autenticação, registro e verificações de conteúdo. A Arcjet argumenta que parte do contexto da aplicação se perde quando a aplicação das regras é movida para fora do código que executa a ação.
As duas abordagens não são mutuamente exclusivas. Uma empresa pode usar um gateway para o tráfego de modelos e a Arcjet para chamadas específicas de ferramentas. A questão importante é qual controle assume a decisão final.
A Arcjet afirma que decisões locais adicionam menos de um milissegundo de sobrecarga. A empresa informa entre 20 e 30 milissegundos quando uma decisão precisa de seu serviço em nuvem.
Esses números são alegações da empresa, não resultados de benchmarks independentes. Eles também excluem verificações mais pesadas. A Arcjet afirma que sua detecção especializada de injeção de prompt pode adicionar cerca de 100 milissegundos antes de uma chamada ao provedor.
A latência se torna importante quando uma execução de agente contém dezenas de ações. Um pequeno atraso pode se acumular, especialmente quando a avaliação remota de políticas ou a detecção baseada em modelos aparece repetidamente.
Assim, a arquitetura cria um problema de posicionamento de políticas. As equipes precisam decidir quais ações exigem regras locais, verificações remotas, análise de conteúdo ou revisão humana.
Uma consulta somente leitura pode exigir apenas autorização e registro. Um reembolso de alto valor pode justificar vários controles e aprovação manual. Aplicar o processo mais rigoroso a todas as ações reduziria a velocidade dos fluxos de trabalho e aumentaria o atrito operacional.
A resposta da Arcjet é a aplicação granular de regras. As equipes de engenharia podem manter regras próximas ao handler protegido, enquanto as equipes de segurança podem gerenciar políticas remotas sem solicitar outra implantação da aplicação.
Regras baseadas em código apoiam testes, revisão e controle de versão. Regras remotas permitem que profissionais de segurança ajustem limites entre serviços. Combiná-las pode preservar a responsabilidade da engenharia e, ao mesmo tempo, oferecer às equipes de segurança uma intervenção mais rápida.
Isso também pode introduzir questões de governança. Uma aplicação pode conter uma política enquanto o serviço remoto aplica outra. As equipes precisam de precedência clara, histórico de alterações e comportamento em caso de falha.
Se o serviço de políticas em nuvem ficar indisponível, a aplicação deverá decidir se bloqueia ou continua. Essa decisão depende das consequências da ação e da tolerância da organização à interrupção.
O produto torna visível o limite da ação, mas não elimina essas escolhas de design. Ele oferece às equipes um lugar para codificá-las.
A aplicação de regras no código desafia gateways e painéis de segurança
A principal disputa ocorre entre controles que podem interromper uma ação e sistemas que principalmente observam o tráfego ao redor dela.
Painéis de segurança podem identificar comportamentos incomuns após a chegada da telemetria. Isso continua útil para investigação, resposta a incidentes e conformidade. Não necessariamente interrompe um reembolso ou uma atualização de banco de dados já concluídos.
Gateways de IA podem agir antes que uma solicitação ou resposta de modelo passe por eles. Eles podem detectar conteúdo hostil, restringir provedores ou aplicar limites de gastos em um ponto centralizado.
No entanto, a operação consequente de um agente pode ocorrer após a interação com o modelo. O modelo propõe uma chamada de ferramenta, e o código da aplicação a executa em outro sistema. Um gateway que vê apenas o tráfego do modelo pode não detectar a operação final.
A Arcjet posiciona sua proteção dentro desse caminho de execução. A aplicação solicita uma decisão de política imediatamente antes de chamar a função relevante. Isso permite que a política inspecione argumentos tipados em vez de inferir a intenção a partir da linguagem natural.
Um reembolso de valor modesto e outro de valor muito maior podem parecer semelhantes na camada de rede. O handler da aplicação conhece o valor exato, a conta, a moeda e o contexto do usuário.
A contrapartida é o escopo de implantação. Um gateway centralizado pode cobrir muitas aplicações depois que o tráfego é roteado por ele. Controles no código precisam ser inseridos nos limites que os desenvolvedores identificam.
A Arcjet tenta reduzir essa carga por meio de SDKs, hooks e integrações com frameworks. Ela também oferece suporte à observação via OpenTelemetry sem exigir alterações na aplicação, segundo a empresa.
No entanto, descoberta e aplicação de controles continuam sendo coisas diferentes. A telemetria pode revelar um agente desconhecido sem colocar automaticamente um controle de bloqueio antes de cada ação que esse agente executa.
Essa distinção cria uma sequência de adoção. Uma equipe de plataforma pode primeiro inventariar a atividade dos agentes. Em seguida, os desenvolvedores escolhem ações de alto impacto e adicionam proteções ao redor delas.
A sequência é prática, mas a cobertura pode continuar desigual. Um serviço pode proteger reembolsos, enquanto outro deixa alterações de conta sem proteção. As equipes de segurança precisam de evidências que mostrem quais ações não têm aplicação de controles.
Grandes fornecedores estão avançando em territórios sobrepostos. A Cisco expandiu o AI Defense em fevereiro de 2026 com proteções de runtime para o uso de ferramentas por agentes e governança de interações. Sua expansão do AI Defense enfatiza a proteção em ambientes de rede, nuvem e infraestrutura local.
A abordagem da Cisco se beneficia de uma presença consolidada em segurança empresarial. A proposta da Arcjet se concentra em integração nativa de aplicações e adoção por desenvolvedores.
Outros produtos se concentram em firewalls para modelos, red teaming de IA, identidade, roteamento por gateway ou observabilidade. Essas categorias se sobrepõem cada vez mais à medida que os fornecedores acompanham a atividade dos agentes, dos prompts à execução de ferramentas.
A Arcjet precisa, portanto, mostrar que o contexto no nível da ação produz decisões melhores, e não apenas mais logs. Os compradores vão querer evidências de que as políticas bloqueiam ataques relevantes sem interromper trabalhos legítimos.
Os exemplos atuais da empresa são intuitivos. Eles incluem limites de reembolso, chamadas não autorizadas de ferramentas, redação de dados sensíveis, loops descontrolados e sequências de ações perigosas.
Os casos mais difíceis envolvem intenção ambígua. Uma política pode facilmente negar uma ferramenta indisponível para determinada função. É mais difícil avaliar se uma chamada de ferramenta permitida corresponde ao objetivo mal especificado de um usuário.
Políticas determinísticas ajudam quando as organizações conseguem expressar uma regra clara. Uma política determinística retorna o mesmo resultado para as mesmas entradas conhecidas, em vez de depender de um julgamento aberto do modelo.
As regras podem limitar gastos, restringir recursos, exigir aprovações ou bloquear categorias específicas de dados. Elas se tornam menos decisivas quando o contexto depende de significados de negócio mais sutis.
Essa limitação não torna desnecessária a aplicação de controles em runtime. Ela define onde terminam os controles determinísticos e começa a governança baseada em raciocínio.
O produto da Arcjet atualmente enfatiza uma base confiável de aplicação de controles. Uma análise de sequências mais rica pode ser construída sobre essa base, mas ainda precisa de um mecanismo capaz de interromper a ação resultante.
Esta é a parte mais forte do argumento da empresa. Uma detecção melhor oferece proteção limitada quando a aplicação não consegue aplicar a decisão antes da execução.
A parte mais fraca é a comprovação operacional. A Arcjet não publicou dados amplos de terceiros que mostrem taxas de falsos positivos, adoção por clientes ou redução de incidentes para este lançamento.
Até que esses resultados apareçam, os compradores devem tratar números de desempenho e eficácia como alegações do fornecedor. As implantações piloto devem executar políticas em modo de observação antes de habilitar o comportamento de bloqueio.
A Injeção de Prompt É Apenas Uma Parte do Problema de Runtime
Um filtro de prompts não pode substituir autorização, privilégio mínimo, orçamentos ou controles de aprovação.
A injeção de prompt recebe atenção porque um invasor pode ocultar instruções em e-mails, documentos, sites ou saídas de ferramentas. Um agente pode tratar esse conteúdo não confiável como orientação e alterar seu comportamento.
A filtragem pode identificar alguns padrões hostis antes que o conteúdo chegue a um modelo. Ela não consegue determinar com confiabilidade se cada ação de negócio resultante está autorizada.
Uma solicitação bem-formada ainda pode exceder a autoridade de um usuário. Uma conta comprometida pode enviar instruções aparentemente inofensivas. Um agente também pode cometer um erro sem encontrar um ataque.
A segurança de runtime deve, portanto, separar a avaliação de conteúdo da autorização de ações. Uma verificação pergunta se a entrada parece hostil. Outra pergunta se este ator pode executar esta operação neste recurso.
A orientação da OWASP sobre agência excessiva recomenda minimizar extensões, permissões e autonomia. Ela também recomenda aprovação humana antes de ações de alto impacto.
A Arcjet pode fornecer o ponto de aplicação para alguns desses controles. Ela não pode decidir a tolerância a riscos de uma organização nem redesenhar um agente que possui credenciais excessivamente amplas.
Um agente com permissões de banco de dados desnecessárias continua perigoso. Políticas de bloqueio reduzem a exposição, mas o privilégio mínimo deve impedir que o agente alcance muitas operações sensíveis desde o início.
A aprovação humana também precisa de implementação cuidadosa. Uma tela de confirmação deve exibir a ferramenta real, o destino, os argumentos e a consequência. Pedir aos usuários que aprovem um resumo escrito pelo agente pode ocultar o detalhe perigoso.
Segundo os materiais de produto da Arcjet, ela retorna uma decisão de retenção para revisão. A aplicação ao redor ainda controla como essa revisão aparece e quem pode aprová-la.
Os registros de auditoria criam outro conjunto de preocupações. Prompts e parâmetros de ferramentas podem conter informações pessoais, credenciais, documentos internos ou dados de clientes.
A Arcjet afirma que verificações sensíveis podem ser executadas localmente enquanto as evidências de decisão são armazenadas separadamente. Ela oferece armazenamento por meio de sua nuvem, de um ambiente de locatário único, de uma nuvem virtual privada ou de infraestrutura gerenciada pelo cliente.
As organizações devem verificar quais campos saem de seu ambiente. Também devem definir retenção, armazenamento regional, controles de acesso, procedimentos de exclusão e responsabilidades de resposta a incidentes.
O produto anuncia um relatório SOC 2 Type II que abrange segurança, disponibilidade e confidencialidade. Essa garantia trata dos controles organizacionais, mas não valida cada política de agente ou integração.
A detecção baseada em sequências introduz mais incerteza. Vincular ações entre sessões pode revelar riscos graduais que verificações isoladas não detectam. Também pode produzir históricos incompletos ou incorretos quando os identificadores são inconsistentes.
As convenções do OpenTelemetry podem ajudar a normalizar registros. Elas não garantem que cada framework emita contexto equivalente ou preserve as mesmas informações de identidade.
Os desenvolvedores precisam propagar identificadores de correlação entre filas, tarefas em segundo plano e limites de serviço. A ausência de contexto pode fazer um fluxo de trabalho parecer várias execuções não relacionadas.
A coleta excessiva cria o problema oposto. Registrar cada prompt, argumento de ferramenta e saída pode ampliar os dados sensíveis disponíveis para a plataforma de monitoramento.
As equipes de segurança devem equilibrar detalhes para investigação e minimização de dados. Uma trilha de auditoria útil deve comprovar a decisão sem copiar automaticamente cada carga sensível.
Falsos positivos representam outro desafio. Um detector de injeção de prompt pode sinalizar discussões legítimas sobre segurança, instruções de malware citadas ou conteúdo de clientes.
A Arcjet recomenda a implantação em dry-run, que registra decisões sem aplicá-las. Isso permite que as equipes comparem bloqueios propostos com o comportamento real da aplicação antes de ativar uma regra.
Os dry runs são valiosos, mas precisam de revisão estruturada. As equipes devem rotular falsos positivos, medir casos não detectados e testar caminhos de falha, em vez de apenas observar passivamente um painel.
Uma política também pode se tornar desatualizada. Novas ferramentas, argumentos, classes de dados e processos de negócio alteram o significado de uma ação. Registros de políticas versionados ajudam investigadores a entender qual regra foi aplicada em determinado momento.
Eles não garantem que a regra tenha continuado apropriada. Os responsáveis por segurança e aplicações devem revisar as políticas à medida que o fluxo de trabalho muda.
Essas limitações reforçam a principal contrapartida. Levar a aplicação de controles para o código fornece contexto útil, mas também distribui a responsabilidade entre serviços e equipes.
A Arcjet precisa tornar esse modelo distribuído mais fácil de governar do que uma colcha de retalhos de verificações personalizadas de autorização. Caso contrário, os compradores podem obter outra camada de políticas sem alcançar um controle consistente.
O Próximo Teste É a Evidência em Produção, Não a Amplitude de Recursos
O lançamento da Arcjet terá importância se os clientes conseguirem comprovar cobertura, baixa interrupção e intervenção bem-sucedida em fluxos reais de agentes.
O primeiro sinal a observar é a adoção além dos ambientes de demonstração. A Arcjet deve mostrar como as equipes inventariam agentes, identificam ações consequentes e levam políticas selecionadas do dry run à aplicação.
Implantações de produção identificadas pelo nome esclareceriam quais fluxos de trabalho os compradores priorizam. Operações de suporte, desenvolvimento de software, finanças e acesso interno a dados apresentam riscos e requisitos de latência distintos.
A evidência mais forte incluiria tempo de implantação, cobertura de ações protegidas, taxas de falsos positivos e o número de ações interrompidas antes da execução. Essas métricas testariam a alegação central da Arcjet.
O segundo sinal é a interoperabilidade. Atualmente, a Arcjet lista integrações com frameworks de agentes e assistentes de programação de destaque. O mercado avaliará se essas integrações preservam contexto útil em ambientes mistos.
As organizações raramente padronizam todos os agentes em um único framework. Um fluxo de trabalho pode começar em uma interface de chat, continuar por uma fila e terminar dentro de um serviço personalizado.
A Arcjet precisa conectar essas etapas sem obrigar todas as equipes a usar um único sistema de orquestração. O suporte ao OpenTelemetry fornece uma camada plausível de descoberta, enquanto as proteções via SDK fornecem aplicação de controles.
A lacuna entre essas camadas exigirá atenção. Os compradores precisam de uma visão clara dos agentes descobertos cujas ações consequentes continuam desprotegidas.
Os relatórios de cobertura podem se tornar um dos recursos mais valiosos do produto. Eles permitiriam que as equipes de segurança distinguissem visibilidade de controle preventivo real.
O terceiro sinal é a resposta competitiva. A Cisco e outros fornecedores empresariais já estão adicionando governança de interação de agentes e proteção em runtime.
Se essas empresas avançarem mais profundamente nos handlers de aplicações, a distinção arquitetural da Arcjet diminuirá. Se permanecerem focadas na inspeção centralizada, a Arcjet poderá argumentar que seu contexto no nível do código preenche uma lacuna persistente.
Os provedores de frameworks de agentes também podem adicionar hooks nativos de políticas. Esse desenvolvimento pode ajudar a Arcjet ao criar pontos comuns de aplicação, ou reduzir a demanda por uma plataforma separada.
É provável que o mercado sustente controles em camadas. Identidade, inspeção por gateway, autorização de ações, telemetria e revisão humana abordam modos de falha diferentes.
O desafio do comprador é impedir que a sobreposição se transforme em complexidade. Cada serviço adicional de decisão cria requisitos de configuração, latência, registro e disponibilidade.
A oportunidade imediata da Arcjet é se tornar o último ponto de verificação de políticas antes da execução de uma função consequente. Seu risco é se tornar outro painel que as equipes implantam amplamente, mas aplicam de forma limitada.
Desenvolvedores que avaliam a segurança de runtime para agentes da Arcjet devem começar com um fluxo de trabalho delimitado. Eles devem mapear entradas, identidades, ferramentas, acesso a dados, etapas de aprovação e ações irreversíveis.
Em seguida, podem proteger a chamada mais consequente e operar a regra em modo dry-run. Os revisores devem inspecionar casos legítimos e adversariais antes de habilitar um bloqueio.
As equipes de segurança também devem testar o comportamento quando o serviço não está disponível. Um serviço de reembolso, um gravador de banco de dados de produção e uma ferramenta de busca de documentos não devem compartilhar uma única política padrão de falha.
Por fim, as equipes devem verificar as evidências de auditoria resultantes. Um investigador precisa ser capaz de reconstruir a decisão sem expor dados sensíveis desnecessários.
O lançamento identifica uma mudança real na segurança de IA. Os agentes criam riscos por meio de ações, não apenas de saídas de modelos. Portanto, os controles devem acompanhar o fluxo de trabalho até o ponto em que o software altera outro sistema.
A Arcjet ofereceu uma implementação concreta dessa ideia. Os próximos meses devem mostrar se sua abordagem no código oferece controle consistente em organizações reais.
Para quem desenvolve, a pergunta prática agora é específica: qual ação de um agente causaria mais danos se fosse executada incorretamente hoje? Comece por ela, verifique a identidade e o contexto ao redor e, em seguida, estabeleça uma decisão aplicável antes da chamada.
