Li os prompts dos agentes de segurança da Cursor para você não precisar

Este é o prompt — na íntegra:

You are a security reviewer for pull requests.
Goal: Detect and clearly explain real vulnerabilities introduced or exposed by this PR. Review only added or modified code unless unchanged code is required to prove exploitability.
1. Inspect the PR diff and surrounding code paths.
2. For every candidate issue, trace attacker-controlled input to the real sink.
3. Verify whether existing controls already block exploitation: auth or permission checks, schema validation or type constraints, framework escaping, ORM parameterization, allowlists or bounded constants.
4. Report only medium, high, or critical findings with a plausible attack path and concrete code evidence.
Prioritize: injection risks, authn or authz bypasses, permission-boundary mistakes, secret leakage or insecure logging, SSRF, XSS, request forgery, path traversal, and unsafe deserialization, dependency or supply-chain risk introduced by the change.

Ele é a base da automação Agentic Security Review da Cursor, que já analisa mais de 3.000 PRs internos por semana e detecta mais de 200 vulnerabilidades reais. Uma atribuição de função, um objetivo, uma metodologia em quatro etapas e uma lista de prioridades. Nada de estruturas elaboradas de cadeia de pensamento. Nada de páginas de exemplos few-shot. Nada de esquemas complexos de saída em JSON.

Se você me dissesse, há dois anos, que um prompt tão conciso poderia operar nessa escala e gerar resultados capazes de bloquear o CI, eu teria ficado cético. Fomos condicionados a pensar que criar prompts para IA exige engenharia elaborada: páginas de instruções, exemplos cuidadosamente elaborados e especificações detalhadas de saída. Os modelos de código aberto da Cursor sugerem que, para revisão de segurança, uma definição clara de função e uma metodologia estruturada talvez sejam tudo de que você precisa.

Isso é um sinal impressionante de onde os modelos de ponta estão hoje. O modelo já “sabe” como é uma injeção de SQL, como funcionam os desvios de autenticação e o que significa desserialização insegura. Ele só precisa de uma estrutura para aplicar esse conhecimento de forma sistemática. Se os modelos conseguem fazer tanto com tão poucas instruções hoje, a evolução nos próximos seis a doze meses é realmente empolgante.

É claro que o prompt é apenas a ponta do iceberg. A verdadeira conquista de engenharia aqui não são as 15 linhas de instruções, mas tudo o que está por baixo: o servidor MCP personalizado que gerencia a persistência e a deduplicação, o pipeline de implantação gerenciado com Terraform, a orquestração por webhooks que sabe quando acionar cada agente e o gerenciamento de estado que permite aos agentes comparar descobertas entre execuções. O prompt é simples porque a infraestrutura ao redor não é. Essa é uma distinção importante e, na verdade, a parte mais interessante da história: a Cursor não apenas escreveu prompts engenhosos; criou uma plataforma de orquestração de agentes pronta para produção e, depois, colocou prompts simples sobre ela.

Mas, antes de nos empolgarmos, vamos analisar o panorama completo do que a Cursor criou, o que impressiona em cada parte e onde estão as lacunas. Para isso, ajuda ter uma estrutura para pensar sobre segurança em ambientes de desenvolvimento agentivo.

As três dimensões da segurança agentiva

Na Snyk, pensamos na proteção do desenvolvimento agentivo em três dimensões: o código gerado pelos agentes, a cadeia de suprimentos da qual os agentes dependem e o comportamento dos próprios agentes. A dimensão do código é aquela em que a maioria das pessoas se concentra: a IA está escrevendo código seguro? Estamos detectando vulnerabilidades antes que ele seja lançado? A dimensão da cadeia de suprimentos é mais recente e menos óbvia: servidores MCP, modelos de automação, habilidades de agentes e plugins são componentes dos quais seus agentes dependem e trazem os mesmos riscos que qualquer dependência de terceiros. A dimensão do comportamento é a mais complexa: os agentes estão atuando dentro do escopo previsto? Estão tomando decisões que não deveriam? Você consegue acompanhar o que eles realmente fazem na sua organização?

Os agentes de segurança da Cursor atuam principalmente na primeira dimensão, detectando vulnerabilidades no código. Esse trabalho é valioso e necessário. Mas, como você verá no passo a passo abaixo, as outras duas dimensões são igualmente importantes, especialmente em escala empresarial. E as organizações que obtêm os melhores resultados, como a Labelbox, que eliminou um acúmulo de vulnerabilidades de vários anos usando Cursor e Snyk em conjunto, são aquelas que abordam as três dimensões.

Os quatro agentes: pontos fortes e lacunas

Hoje, Travis McPeak publicou uma publicação no blog detalhando como a equipe de segurança da Cursor criou quatro agentes autônomos de segurança com base no Cursor Automations (a plataforma de agentes em nuvem da empresa) e disponibilizou os modelos como código aberto para qualquer pessoa usar. O ritmo de PRs aumentou cinco vezes em nove meses, e a análise estática tradicional não conseguia acompanhar. Por isso, eles criaram agentes capazes de dar conta do recado.

Todo o sistema se apoia em uma base que merece destaque: um servidor MCP (Model Context Protocol) personalizado, implantado como uma função Lambda sem servidor. Ele oferece rastreamento de estado persistente, uma camada de deduplicação baseada no Gemini Flash 2.5 (para que agentes diferentes não registrem a mesma descoberta com palavras distintas) e formatação consistente das mensagens no Slack, com opções para descartar ou adiar alertas. Tudo é gerenciado com Terraform. Engenharia sólida.

Veja cada agente, junto com o que considero realmente impressionante e o que uma equipe de segurança corporativa deve levar em conta.

Agentic Security Review: o guardião dos PRs

O que faz: analisa cada pull request com base no modelo de ameaças específico da Cursor. Publica descobertas em um canal privado do Slack, comenta diretamente nos PRs e pode bloquear o pipeline de CI quando encontra problemas de segurança. Seu principal diferencial em relação a um bot de revisão de uso geral, como o Cursor’s Bugbot, é permitir ajustes de prompt específicos para segurança sem bloquear o processo por cada detalhe de qualidade de código.

O que impressiona: os resultados falam por si. Nos últimos dois meses, esse agente analisou milhares de PRs e impediu que centenas de problemas chegassem à produção. E, como mostrei acima, o prompt que viabiliza tudo isso é incrivelmente conciso. Para um revisor baseado em LLM, a relação entre sinal e ruído é realmente surpreendente.

O que considerar: LLMs podem apontar com convicção uma “injeção de SQL crítica” em uma consulta parametrizada perfeitamente segura, porque o modelo interpretou errado o fluxo de dados. Também podem deixar passar uma vulnerabilidade real porque perdem o foco ao analisar uma base de código extensa. Em segurança, os dois tipos de falha custam caro: falsos positivos prejudicam a confiança dos desenvolvedores, enquanto falsos negativos deixam vulnerabilidades reais em produção. Quando sua camada de detecção é inteiramente probabilística, você aceita os dois riscos. O princípio aqui é simples: o agente não pode corrigir a própria prova. Você precisa de uma camada de validação independente para confirmar o que o LLM encontrou. Por isso, é importante complementar a revisão com LLM com uma análise SAST determinística, como o Snyk Code. O mecanismo determinístico detecta padrões conhecidos com precisão mecânica; o LLM encontra bugs lógicos novos, que atravessam vários arquivos e passam despercebidos por ferramentas baseadas em regras. Você precisa dos dois.

Outro ponto que vale destacar: observe o final do modelo de prompt.

Post a short Slack summary with the overall outcome and the top findings, if any.
Do not push changes or open fix PRs from this workflow.

O agente de revisão explicitamente não envia correções. Ele encontra, relata e bloqueia, mas uma pessoa ainda decide o que fazer. Até a própria equipe de segurança da Cursor mantém a participação humana no uso das ferramentas internas. Isso mostra em que ponto a segurança autônoma com IA realmente está hoje: é um poderoso acelerador, não um substituto para o julgamento humano. Pelo menos por enquanto.

Vuln Hunter: análise da base de código existente

O que faz: em vez de acompanhar a entrada de código novo, o Vuln Hunter analisa a base de código existente. Ele divide o repositório em segmentos lógicos, busca vulnerabilidades em cada um e a equipe de segurança faz a triagem das descobertas pelo Slack. Muitas vezes, ela usa @Cursor diretamente no Slack para gerar PRs com correções.

O que impressiona: direcionar o raciocínio de LLMs para código legado é uma boa ideia. É aí que a IA se destaca: entendendo bases de código complexas e sem documentação e identificando vulnerabilidades que regras estáticas não detectariam. Bugs lógicos que atravessam arquivos, padrões de controle de acesso mal implementados e desvios de autenticação escondidos em código de anos atrás. Os scanners tradicionais têm dificuldade nesse cenário porque precisam encontrar padrões bem definidos.

O que considerar: este é o agente com maior probabilidade de gerar falsos positivos em escala. Analisar uma base de código inteira — em vez de um diff de PR específico — significa trabalhar com um contexto muito maior, o que torna real o risco de o LLM perder o foco. O BaxBench, um benchmark da ETH Zurich, da UC Berkeley e do INSAIT, constatou que 62% das soluções geradas até pelos melhores modelos estão incorretas ou contêm vulnerabilidades de segurança. Quando o modelo analisa bases de código grandes e complexas, o princípio de que “o agente não pode corrigir a própria prova” vale ainda mais: você precisa de uma validação determinística que confirme ou conteste o que o LLM encontrou antes de alguém investir tempo em uma correção.

Anybump: correção automatizada de dependências

O que faz: resolve uma das tarefas mais tediosas da segurança de aplicações: corrigir dependências. Ele executa uma análise de alcançabilidade para filtrar vulnerabilidades que realmente causam impacto, rastreia caminhos de código, executa testes, verifica se algo foi afetado e abre um PR quando os testes passam. Tudo automatizado, com o pipeline de implantação canário da Cursor como etapa final de segurança.

Este é o núcleo do prompt:

You are a dependency-vulnerability remediation automation.
Goal: When a new Linear issue describes a vulnerable dependency, determine whether it can be upgraded safely and open a PR only when confidence is high.
Decision rule: Create PR only when upgrade is clearly safe; otherwise do not make changes.

O que impressiona: isso resolve um problema que toda equipe de segurança conhece muito bem. A correção de dependências exige tanto tempo que muitas equipes acabam desistindo e transferindo a tarefa para a engenharia, onde ela fica acumulada por meses (ou anos). Automatizar a análise de alcançabilidade, os testes e a criação de PRs é uma melhoria real no fluxo de trabalho.

O que considerar: o Anybump resolve a parte mais difícil do gerenciamento de dependências: aplicar a correção, testá-la e incluí-la em um PR. Mas o trabalho não termina aí. Não há geração de SBOM, verificação de conformidade de licenças nem trilha de auditoria para a equipe de compliance. Isso não é tanto uma limitação do agente, mas uma categoria de problema completamente diferente. A aplicação automatizada de correções e a análise de composição de software corporativa se sobrepõem, mas não são a mesma coisa. Se você atua em um setor regulado ou distribui software sob contratos com clientes que exigem conformidade, ainda precisará dessa infraestrutura mais abrangente, além da automação.

Se você tem uma startup com um repositório, talvez o Anybump seja tudo de que precisa. Se opera em escala empresarial — com centenas de repositórios, em setores regulados ou com contratos de clientes que exigem certificações de conformidade específicas —, precisa saber exatamente o que está no seu software, quais licenças está usando e ser capaz de comprovar isso. Essa é a diferença entre a aplicação automatizada de correções e a análise de composição de software de nível corporativo: elas se sobrepõem, mas resolvem problemas fundamentalmente diferentes.

Invariant Sentinel: detecção de desvios de conformidade

O que faz: é executado diariamente para verificar desvios em relação a um conjunto de propriedades de segurança e conformidade. Ele inicia subagentes para cada segmento lógico do repositório, compara o estado atual com execuções anteriores usando a memória da automação e alerta a equipe de segurança quando algo muda.

O que impressiona: o gerenciamento de estado é inteligente. Usar o recurso de memória da automação para comparar execuções permite que o agente detecte mudanças na postura de segurança, e não apenas retratos de um único momento. A capacidade de escrever e executar código de validação junto com a análise acrescenta um rigor que o raciocínio puro de LLM não teria.

O que considerar: detectar desvios de conformidade é valioso, mas a governança de conformidade é um desafio mais amplo. O Invariant Sentinel avisa quando algo mudou, mas não impõe políticas como código em centenas de repositórios, não gera relatórios de conformidade para auditorias nem oferece ao seu CISO um painel com a evolução dos riscos ao longo do tempo. Esses são recursos de plataforma que vão além do que um único agente pode oferecer.

Isso ainda é CI, e a segurança não deve começar pelo CI

O ponto que pode passar despercebido ao analisar os diagramas de arquitetura e a orquestração dos agentes é que, no fundo, o que a Cursor criou é uma camada de CI bastante sofisticada. Os agentes são acionados por webhooks do GitHub quando PRs são abertos ou recebem novos commits. Eles analisam diffs, publicam comentários, bloqueiam pipelines e abrem PRs com correções. Isso é, fundamentalmente, o mesmo ponto de controle em que as ferramentas de segurança tradicionais atuam há anos — só que agora ele é mais inteligente, porque a análise é feita por um LLM, e não por um mecanismo de regras baseado em expressões regulares.

E olha, isso é uma melhoria de verdade — não há dúvida. Mas o CI ainda é o lugar errado para começar a cuidar da segurança.

Por que o CI chega tarde demais para a segurança

Pense bem: se você usa o Cursor para escrever código na IDE e o código vulnerável chega a um PR antes de alguém detectá-lo, você já perdeu tempo. O desenvolvedor precisa voltar a se concentrar no código que escreveu, o ciclo de revisão do PR aumenta a latência e, se a verificação do CI bloquear o processo, agora ele precisa voltar, entender o alerta, corrigir o problema, enviar as alterações novamente e esperar outro ciclo de revisão. É melhor do que descobrir a vulnerabilidade em produção, claro, mas ainda é o modelo de “analisar e abrir um ticket”, só que comprimido no cronograma do PR.

Como é, na prática, antecipar a segurança

O ideal é que as ferramentas de segurança funcionem diretamente na IDE, iniciando análises e correções assim que um novo código é introduzido. Assim, o código vulnerável nem chega a ser incluído em um commit. O histórico do Git permanece limpo. Seus PRs não ficam bloqueados, porque os problemas de segurança são detectados e corrigidos durante o desenvolvimento, antes mesmo de o desenvolvedor preparar as alterações. E você reduz drasticamente a necessidade de revisões humanas caras, porque, se a vulnerabilidade nem chega a um PR, ninguém precisa fazer a triagem e nenhum pipeline fica bloqueado às 16h30 de uma sexta-feira.

Segurança que começa na IDE vs. segurança que começa no CI

Com o Snyk Studio, é exatamente assim que funciona. As barreiras de segurança interceptam o código inseguro antes mesmo de o desenvolvedor aceitar a sugestão da IA. O assistente de IA executa snyk_code_scan em tempo real no código novo e, se encontrar problemas de segurança, corrige tudo ali mesmo, durante o desenvolvimento. Funciona diretamente no Cursor e em todos os principais assistentes de programação com IA. Sem bloqueios no pipeline de CI, mudanças de contexto ou histórico do Git desorganizado.

Por que a segurança em camadas é necessária

Agora imagine usar os dois: o Snyk Studio na camada da IDE, detectando a grande maioria dos problemas no momento em que surgem, e os agentes de segurança do Cursor na camada do CI, como uma rede de proteção para o que passar despercebido. Você conta com defesa em profundidade: a maior parte do trabalho é feita silenciosamente na IDE, enquanto as revisões humanas mais caras ficam reservadas para casos realmente complexos. Considerando o que o BaxBench revela sobre a insegurança do código gerado por IA (62% das soluções dos principais modelos contêm vulnerabilidades ou estão incorretas), esse tipo de proteção em camadas não é um luxo. É essencial.

E, além da questão do CI, um programa de segurança vai muito além das verificações de CI. Inclui painéis centralizados que agregam riscos de centenas de repositórios. Inclui descobertas de SAST correlacionadas com resultados de DAST, confirmando que o mesmo endpoint pode ser explorado em tempo de execução. Inclui seu mecanismo de SCA identificando que a biblioteca ORM usada tem uma CVE conhecida que, em determinados casos extremos, contorna a parametrização, e relacionando isso à descoberta de SAST no mesmo método do controlador. Cada um desses dados, isoladamente, é apenas um ponto. Correlacionados na mesma plataforma, eles mostram exatamente o que está acontecendo, por que e o que corrigir primeiro. Um scanner de código, mesmo autônomo, com quatro agentes e um volume impressionante de PRs, não responde a essas perguntas. Uma plataforma de segurança, sim.

Validação, não concorrência (e já estamos integrados)

Escrevi algumas semanas atrás sobre o lançamento do Claude Code Security da Anthropic e defendi que o investimento das plataformas de programação com IA em segurança é uma validação, não uma ruptura. A mesma lógica se aplica aqui: quando os maiores nomes das ferramentas de desenvolvimento com IA começam a criar recursos de segurança, isso mostra que o setor entendeu que a segurança no desenvolvimento assistido por IA é infraestrutura, não um complemento opcional.

Como Cursor e Snyk trabalham juntos

Cursor e Snyk não são dois navios que passam um pelo outro sem se notar: a Snyk já está no diretório MCP do Cursor. Temos uma extensão verificada. Lançamos o Evo Agent Guard via Hooks. Há duas semanas, o Cursor foi reconhecido como nosso AI Innovation Partner of the Year. Essa não é uma relação adversarial; é a arquitetura de dois níveis em ação. Pense assim: os agentes de IA são os pesquisadores, que descobrem vulnerabilidades e propõem correções com rapidez e criatividade. A validação determinística é a revisão por pares, que confirma de forma independente se as descobertas são reais e se as correções são confiáveis.

A arquitetura de segurança de dois níveis

Você não publicaria um artigo sem revisão por pares, nem deveria lançar uma correção de segurança sem validação determinística. O Cursor oferece a camada de pesquisa (orquestração de agentes, acionadores de webhook e geração automatizada de PRs). A Snyk oferece revisão por pares, governança e ampla cobertura em toda a cadeia de suprimentos de software.

E isso já funciona na prática: a Labelbox usa Cursor + Snyk em produção e conseguiu eliminar um acúmulo de vulnerabilidades que se formou ao longo de vários anos. O Cursor automatiza os fluxos de trabalho de correção; a Snyk garante que as correções sejam eficazes e estejam à altura das exigências corporativas.

A cadeia de suprimentos agentiva é a nova superfície de ataque

Afaste-se um pouco da implementação específica do Cursor e observe o que está acontecendo no setor. No último ano, surgiu uma cadeia de suprimentos de software totalmente nova, e ela está crescendo rápido: servidores MCP, habilidades de agentes, modelos de automação, plugins de ferramentas de IA e configurações personalizadas de modelos. Podemos chamá-la de cadeia de suprimentos agentiva. Ela reúne os componentes dos quais as ferramentas de desenvolvimento com IA dependem para funcionar e, neste momento, quase ninguém os protege.

Não se trata de uma preocupação teórica. Em janeiro de 2026, a equipe de pesquisa da Snyk descobriu centenas de habilidades maliciosas no ClawHub, o primeiro grande ataque à cadeia de suprimentos direcionado aos ecossistemas de agentes de IA. Pense nisso no contexto do que o Cursor acabou de disponibilizar como código aberto: modelos de automação que acessam sua base de código, seus pipelines de CI, seus canais do Slack e seus repositórios do GitHub. Um servidor MCP implantado como uma função Lambda que processa todas as descobertas de segurança da sua organização. São componentes poderosos e privilegiados. E o ecossistema para distribuí-los e encontrá-los — marketplaces, galerias de modelos e repositórios de código aberto — cresce muito mais rápido do que as práticas de segurança que deveriam acompanhá-lo.

A cadeia de suprimentos de software tradicional levou décadas para desenvolver as ferramentas das quais dependemos hoje: registros de pacotes com verificação de assinaturas, SBOMs, scanners de licenças e bancos de dados de vulnerabilidades. A cadeia de suprimentos agentiva ainda não conta com essa infraestrutura, mas já está sendo adotada em grande escala. Toda organização que instala servidores MCP, importa modelos de automação ou conecta habilidades de agentes ao ambiente de desenvolvimento amplia sua superfície de ataque de formas que a análise de código, por mais sofisticada que seja, simplesmente não consegue abordar.

O Evo by Snyk foi criado exatamente para resolver esse problema. O Evo é nosso sistema de orquestração de segurança agentiva, desenvolvido para o cenário de desenvolvimento nativo em IA: modelagem de ameaças com IA, que cria modelos dinâmicos a partir do seu código; red teaming com IA, que testa continuamente seus modelos e agentes com técnicas adversariais; AI-SPM, para você saber exatamente quais modelos e frameworks de IA estão em execução na sua organização, incluindo a “IA sombra” que nem as equipes de segurança conhecem; e Agent Scanning, que oferece visibilidade de todas as toolchains com barreiras de segurança em tempo real.

Ao executar agentes autônomos de segurança na sua base de código, você também precisa proteger esses agentes. As ferramentas da sua cadeia de suprimentos agentiva são tão essenciais quanto os pacotes npm em node_modules e merecem o mesmo rigor.

O que vem a seguir: as perguntas que isso levanta

Em vez de concluir com uma tese sobre a qual já escrevi, vou encerrar com perguntas voltadas para o futuro que o anúncio do Cursor levanta. Acho que são mais interessantes do que olhar para trás.

Experimente você mesmo

O Snyk Studio é gratuito e leva poucos minutos para configurar. Funciona no Cursor e em praticamente todos os outros assistentes de programação com IA. Em cerca de cinco minutos, você terá análises determinísticas e o comando de correção /snyk-fix funcionando na sua IDE. Se quiser ver a segurança em camadas na prática, este é o caminho mais rápido.

O Evo by Snyk é a solução para proteger a própria stack de IA: modelagem de ameaças, red teaming, AI-SPM, análise de agentes e orquestração de segurança agentiva. Se sua organização está adotando ferramentas de programação com IA em grande escala — e, sejamos sinceros, provavelmente está —, o Evo oferece visibilidade e barreiras de segurança para fazer isso com segurança.

Os modelos de automação do Cursor estão disponíveis como código aberto no GitHub. Se você usa o Cursor, vale a pena explorá-los. E, se executá-los junto com a Snyk, terá o melhor dos dois mundos: automação com agentes e validação de nível corporativo como base.

Está tudo pronto. É hora de juntar as peças.