Cisco Project Quarry pergunta o que um agente fez durante toda a tarefa
Project Quarry conecta mensagens, chamadas de ferramentas e ordem dos eventos em regras verificáveis. Guia do motor alfa, das evidências e das fronteiras de aplicação dos controles.
Um assistente lê um arquivo. Mais tarde, envia uma requisição web. Cada ação pode ser permitida, útil e comum. A pergunta de segurança é se a segunda carregou informações da primeira para onde nunca deveriam ter ido.
A Cisco apresentou o Project Quarry em 28 de outubro de 2026 como linguagem e motor abertos de detecção de comportamento de agentes. Em vez de examinar só uma mensagem isolada, permite descrever padrões entre mensagens, chamadas de ferramentas, resultados e ordem dos eventos. A descoberta inclui evidências que explicam qual atividade correspondeu à regra. Artigo da Cisco
Para equipes levando agentes ao suporte, desenvolvimento ou operações, é um acréscimo concreto às ferramentas de segurança. Este guia explica sua contribuição, como começar localmente e por que detectar uma sequência perigosa é só parte do controle. O framework público está em alfa, então o piloto deve considerar mudanças nas regras antes da versão 1.0.0. README, consultado em 2 de novembro de 2026
Firewall Cisco ASA 5510 em 2010; hardware histórico de segurança de rede. Quarry é software de comportamento de agentes, não este aparelho. Foto: Jon 'ShakataGaNai' Davis, CC BY-SA 3.0; redimensionada com margens. Fonte da imagem · Licença e notas da imagem. Referência oficial do produto.
Uma sequência explica o que um evento sozinho não explica
Imagine um agente interno que lê uma base de conhecimento e abre tickets externos. Ambos são legítimos. Agora uma página não confiável pede que anexe um diagnóstico interno a um ticket público sem relação. Buscar só “ignore instruções anteriores” pode perder um pedido indireto. Examinar só a ferramenta permitida pode perder por que os argumentos são inadequados.
A sequência fornece contexto. O que foi lido? Qual instrução precedeu o envio? Quais dados entraram nos argumentos? O destino fazia parte da tarefa do usuário? Investigar fica mais fácil com a trilha estruturada intacta.
A Cisco combina verificações exatas e julgamentos opcionais por modelo. As exatas expressam nomes, campos, textos e ordem; as apoiadas por modelo interpretam. O produto hospedeiro decide o efeito da descoberta, como alertar ou bloquear. Explicação de 28 de outubro de 2026
Nossa avaliação: uma boa regra é uma pergunta reproduzível sobre comportamento. Deve ser possível apontar eventos e discutir se a regra expressa a política pretendida. Isso vale mais que um alerta vermelho explicado apenas porque um modelo não gostou da conversa.
Sequência suspeita ilustrativa: Quarry avalia a trilha e devolve evidências; a aplicação integrada responde pela reação.
Quarry fica ao lado de autorização e verificação de conteúdo
Autorização pergunta se um ator pode realizar certa ação sobre um recurso. Classificação pergunta se a entrada ou saída possui uma propriedade. Detecção da trilha pergunta como os eventos se relacionam. Há sobreposição, mas nenhuma deixa de ser necessária porque outra tem uma demonstração convincente.
A Cisco cita Snort, YARA e Sigma como precedentes de linguagens legíveis e compartilháveis para redes, malware e registros. Quarry quer levar regras verificáveis à atividade dos agentes. Motivação da Cisco A analogia ajuda como objetivo; não dá a um projeto alfa a maturidade desses ecossistemas.
| Controle ou abordagem | Pergunta adequada | Responsabilidade restante |
|---|---|---|
| Autorização granular | Este ator pode agir aqui? | Definir e aplicar acesso permitido |
| Classificador de conteúdo | A mensagem tem a propriedade verificada? | Interpretar erros e conectar contexto |
| Regras Quarry | A atividade corresponde ao padrão definido? | Escolher resposta e manter política |
| Snort, YARA e Sigma | Como expressar detecção no domínio estabelecido? | Usar controles adequados ao domínio |
Volte ao arquivo e envio. Autorização forte pode impedir a leitura proibida antes da regra. Conteúdo pode identificar instrução suspeita no resultado. Sequência pode conectar leitura permitida e transferência inadequada. Juntos cobrem mais do caminho que qualquer verificação isolada.
O alerta precisa de evidência suficiente para ação humana
A vantagem de uma descoberta baseada em trilha é apoiar um próximo passo específico. O revisor precisa saber eventos relevantes, campo correspondente e contexto que muda a interpretação. A meta é um caso explicável, não uma lista crescente de notas de risco sem explicação.
Em suporte ilustrativo, uma descoberta pode ligar documento interno a envio posterior não aprovado. O analista verifica se a tarefa autorizava a transferência, se o destino pertence ao cliente e se os dados contêm informação protegida. Sinalizar toda leitura seguida de toda requisição enterraria os casos interessantes.
A precisão depende do vocabulário. “Externo” pode significar fora da empresa, de um ambiente aprovado ou de um serviço. “Sensível” pode ser documento rotulado, campo ou classificação. Defina os termos na integração antes da regra.
A evidência precisa de proteção. A trilha pode conter exatamente o arquivo ou fragmento de credencial que tornou o evento arriscado. Um alerta útil ao analista pode ser impróprio em página pública de erro. Planeje acesso e ocultação junto à regra, não após o incidente.
Três processos tornam o piloto concreto
O primeiro uso é revisar retrospectivamente sessões de suporte. Comece com dados autorizados pequenos contendo atividade normal e transferência imprópria sintética. Aplique as mesmas regras. O piloto deve explicar a correspondência e por que o trabalho legítimo passa limpo.
O segundo examina condições de parada. Se a tarefa permite três tentativas e exige escalonamento, a trilha mostra se o agente parou, continuou ou trocou de ferramenta para perseguir a ação indiretamente. É uma questão útil mesmo com mensagens individualmente inofensivas.
O terceiro é resposta a incidentes. Descoberto um padrão novo, procure-o nas trilhas anteriores. O valor é busca rápida e consistente no histórico autorizado. A resposta ainda depende dos campos e da ordenação que as trilhas antigas preservaram.
Comece em observação. Descobertas retrospectivas revelam falsos positivos sem interromper usuários e estimam a carga investigativa. Uma regra convincente em um exemplo sintético pode ser ampla demais no cotidiano. Intervir ao vivo deve seguir esse aprendizado, com resposta claramente atribuída.
Comece pelos exemplos locais do repositório
O repositório usa Apache 2.0 e oferece Python e linha de comando. O README lista Python 3.11 a 3.13 e início rápido com uv. A configuração seleciona 14 regras locais; quatro exemplos semânticos usam substitutos determinísticos de palavras-chave explicitamente para demonstração e teste, não decisões de produção. README do Project Quarry
A sequência segue a configuração publicada. É ponto de partida para avaliação do leitor, não afirmação de implantação ou varredura ao vivo realizada neste artigo.
-
Use pasta isolada. Confirme a faixa Python e instale
uvpelo processo habitual da organização. Separe de credenciais e trilhas de produção. -
Obtenha e prepare o projeto. Clone o repositório, entre na pasta e sincronize o ambiente fixado:
BashExecutar no Terminalgit clone https://github.com/cisco-ai-defense/project-quarry.git cd project-quarry uv sync --frozen -
Execute o exemplo benigno local. Use a configuração antes de adicionar provedor ou enviar conversas reais:
BashExecutar no Terminaluv run --frozen quarry scan --config examples/config.yaml --target examples/data/benign.json -
Examine um exemplo com correspondência. Mude para
examples/data/tool_calls.jsone confira regra e evidência juntas. Entenda pelos eventos, não aceite só porque apareceu aviso. -
Adicione um par específico de teste. Crie trilha sintética de violação e outra legítima próxima, com o mesmo vocabulário. Declare o esperado antes de ajustar.
-
Registre revisão e tratamento dos resultados. A convenção documentada da CLI é 0 para uma varredura completa sem correspondências, 1 para uma varredura completa com correspondência e 2 para uma varredura inválida ou incompleta. Preserve essas distinções em qualquer camada de integração.
Os códigos têm consequências. Falta de recursos ou entrada inválida não pode contar como limpo. O monitoramento deve expor avaliações incompletas para mostrar lacunas de cobertura.
Regras por modelo introduzem outra fronteira de dados
Algumas políticas precisam de interpretação além de correspondência exata. Um modelo pode avaliar tentativa de redirecionar o agente ou ação fora da tarefa. Isso adiciona latência, custo, comportamento do provedor e outra fonte de erro.
A documentação diz que uma operação de modelo envia mensagens selecionadas, definições de ferramentas e política ao endpoint configurado. Recomenda revisar retenção, registros, transporte e credenciais. Descreve prazos e orçamentos de chamadas, com adaptadores respeitando cancelamento e timeout. Documentação de inferência, consultada em 2 de novembro de 2026
O caminho vira decisão de projeto. Comece localmente e habilite modelo quando o ganho justificar processamento adicional. Antes de dados sensíveis, defina campos que atravessam a fronteira e quem aprova. Um controle de segurança não deve virar rota inesperada de exportação dos dados protegidos.
Substitutos de palavras-chave geram exemplos previsíveis sem provedor real. Não demonstram a precisão de um detector semântico de produção. Avalie o modelo configurado em casos rotulados relevantes, inclusive mensagens comuns parecidas com arriscadas. Falsos positivos e omissões pertencem à mesma revisão.
A integração de produção precisa assumir o caso incompleto
O guia manda preparar e validar regras antes do tráfego. Separa política e entradas confiáveis de adaptadores das conversas não confiáveis e exige status de varredura autoritativo antes de agir sobre correspondências. Guia de integração, consultado em 2 de novembro de 2026
Isso importa mais na falha. Conversa malformada, prazo excedido, modelo indisponível ou regra inválida devem seguir política explícita. Ela pode pausar ação importante, pedir revisão ou informar observação incompleta. Tratar todo erro como “nenhuma descoberta” cria lacuna silenciosa.
Correspondência completa, resultado limpo completo e avaliação incompleta têm significados diferentes. O hospedeiro decide como afetam o processo do usuário.
Mudanças de versão exigem clareza. O aviso alfa significa que sintaxe futura pode exigir atualizar regras. Fixe revisão, preserve trilhas representativas e repita-as antes de atualizar. Assim se distingue mudança de política de mudança do motor.
A Cisco discute implantação no trabalho mais amplo de AI Defense, mas a maturidade pública deve ser julgada pelo estado documentado do motor. Integrações planejadas são futuras. Um produto de produção usar um componente não fornece automaticamente integração suportada a toda aplicação dos leitores.
Segurança de agentes precisa de uma pergunta revisável
A ideia mais forte do Quarry é explicitar uma preocupação comportamental o suficiente para executar de novo. A equipe guarda regra, versão, atividade correspondente e razão da mudança. Isso torna a revisão de política mais concreta que discutir se o agente parece seguro.
A pergunta do piloto é prática: o revisor entende por que uma sessão legítima passou, uma violação correspondeu e o que acontece se a avaliação não termina? Com respostas claras, a equipe tem base para decidir onde detecção influencia ação.
Fontes
- Cisco: apresentação do Project Quarry, 28 de outubro de 2026.
- README do Project Quarry, consultado em 2 de novembro de 2026.
- Guia de integração de aplicações, consultado em 2 de novembro de 2026.
- Guia de inferência de modelos, consultado em 2 de novembro de 2026. Cenários ilustrativos; não se afirma instalação ou varredura de trilhas de produção aqui.
Mantenha a regra conectada às evidências
O Telli.sh é uma opção para guardar fontes autorizadas, notas de avaliação e decisões de uma mudança de engenharia. Criar um espaço de notas.