Saltar para o conteúdo principal
Uma única chamada de ferramenta pode parecer perfeitamente inocente. Ler um registro de CRM: permitido. Chamar uma ferramenta de export: permitido. Atingir um host externo: permitido. A forma da run — cinquenta leituras, depois um export, depois egress para um host que você nunca viu às 3h de um domingo — é o ataque. Os vereditos por chamada julgam cada chamada isoladamente e nunca o veem. Esta página cobre os dois mecanismos do firewall que observam uma run ao longo do tempo em vez de uma chamada de cada vez: regras de sequência (uma cadeia ordenada que você cria) e detecção de anomalias comportamentais (desvio do normal aprendido do seu workspace). Juntos eles são como você detecta o comportamento de cadeia de ataque de agente que nenhuma regra de allow/deny isolada consegue capturar.
Tudo aqui é configurado no console (Security → Firewall), cujas rotas de gerenciamento usam sua sessão / token de acesso — não uma chave de relay sk-orca-…. As chamadas /v1/* do seu agente não mudam.

​
1. Por que regras por chamada perdem a cadeia

Os globs de ferramenta e cláusulas de argumento do firewall são stateless e determinísticos por design — eles decidem uma chamada, rápido, no hot path. Isso é exatamente o que você quer para “bloquear shell.exec rm -rf”. É exatamente errado para uma exfiltração lenta onde cada chamada individual é legal. Duas ferramentas complementares preenchem o gap:

Regras de sequência

Uma regra que você cria que corresponde a uma cadeia ordenada de chamadas dentro de uma janela de tempo — “bulk read → export → egress”. Você nomeia o padrão.

Detecção de anomalias

O firewall aprende a forma normal de uso de ferramentas de cada workspace e sinaliza desvios — loops de retry, caminhos de ferramenta nunca vistos antes e picos de volume/custo. Nenhuma regra para criar.

​
2. Regras de sequência: nomeie a cadeia de ataque

Uma regra sequence vive dentro de uma política de firewall como qualquer outra regra, mas em vez de um único tool_name_glob ela carrega uma lista ordenada de steps. Cada step é um glob de ferramenta com um min_count opcional e um egress: true opcional; os steps devem ocorrer em ordem (intercalar com chamadas não relacionadas é fino) e a cadeia inteira deve completar dentro de window_seconds. 
{
  "label": "bulk-read-then-exfil",
  "verdict": "audit",
  "sequence": {
    "window_seconds": 600,
    "steps": [
      { "match": "crm.*",   "min_count": 50 },
      { "match": "*.export" },
      { "match": "*", "egress": true }
    ]
  }
}
Isso dispara quando um agente lê 50+ registros crm.*, depois chama qualquer ferramenta *.export, depois faz qualquer chamada de egress — tudo dentro de dez minutos. Cada chamada por si só passaria; o padrão é o sinal.
Uma sequência é avaliada na chamada que a completa. O loop de regras inline pula as regras de cadeia (uma chamada não pode satisfazer uma cadeia de múltiplos passos); a correspondência roda quando uma chamada poderia ser o step final de uma cadeia, ponto em que o firewall puxa os eventos recentes desse principal e testa a cadeia. O verdict que você define na regra é o que então acontece com a chamada que completa: audit a registra e a deixa passar, pending_approval a retém para revisão humana, e deny a bloqueia. Então uma cadeia pode parar sua chamada final em tempo real — escolha o veredito para combinar. Use audit quando você só quer detectar e alertar; use pending_approval ou deny (ou combine com um deny / regra de egress por chamada) quando você precisa de uma parada rígida.
A sintaxe completa do campo sequence — window_seconds: 0 para sem limite de tempo, padrões de min_count, semântica de ordenação de step — está no schema de regra. Crie regras de sequência no editor de regras do console; salvar é uma ação Developer+.

​
3. Detecção de anomalias: desvio do normal aprendido

Onde as regras de sequência perguntam “este padrão específico aconteceu?”, a detecção de anomalias pergunta “alguma coisa sobre esta run é anormal para este workspace?”. Ela não precisa de regra — o firewall constrói um baseline a partir do seu próprio tráfego e pontua a atividade ao vivo contra ele. Quatro tipos aparecem:
Volume de chamadas por (tool, key) pontuado contra o baseline aprendido para esta hora-da-semana. Uma linha aparece quando a contagem supera um piso absoluto e roda alta em relação ao baseline, ou quando seu z-score cruza o limiar estatístico. Então “100 chamadas db.query às 3h de domingo” se destaca mesmo que um burst do mesmo tamanho numa terça-14h não se destacasse.
A mesma ideia aplicada ao gasto: uma ferramenta queimando múltiplos de seu custo de baseline aprendido para esta hora-da-semana. O aviso antecipado de denial-of-wallet — combine-o com uma regra cap_cost para aplicar um teto rígido.
Um grupo (conversation, tool, arguments) que se repete muitas vezes numa janela apertada — um agente preso chamando a mesma ferramenta que falha com os mesmos argumentos repetidamente, em vez de polling legítimo lento.
Uma transição tool_a → tool_b que este workspace nunca fez antes. A primeira vez que um agente vai de read_file direto para http_fetch, essa aresta acende mesmo se ambas as ferramentas são individualmente permitidas.

​
O baseline de hora-da-semana

O baseline é uma média móvel de 14 dias agrupada por hora da semana (weekday × 24 + hour), então terça-14:00 é comparada contra o histórico específico de terça-14:00 passado — não uma média plana de todo o tempo que lavaria seu ritmo diário e semanal real. Um workspace novinho sem norma aprendida ainda captura uma inundação óbvia via um piso absoluto, então você está protegido desde o dia um.
O feed reporta nomes de ferramenta, ids de chave redigidos, contagens e um z-score — nunca material de chave cru. Cada anomalia carrega uma remediação sugerida (rate_limit, review ou block_tool) para que o próximo passo seja um clique, não um palpite.

​
4. Um passo a passo concreto

Suponha que um prompt comprometido conduza um dos seus agentes a um loop de falha apertado, depois sonde um caminho de export que ele nunca tocou. Aqui está o que você vê — nenhuma regra criada com antecedência:
1

O agente se comporta mal

Instruções injetadas empurram o agente a fazer retry de um db.query que falha com argumentos idênticos, depois chamar report.export seguido de um fetch outbound — um caminho que este workspace nunca rodou.
2

Abra o feed de anomalias

Em Security → Firewall → Anomalies, a run revela um retry_loop em db.query e um novel_path na aresta report.export → http_fetch. Ler o feed é uma ação Member — qualquer um na equipe pode fazer triagem.
3

Confirme no trace de events

Clique até o log de events e a analytics de run para ver a sequência exata de chamadas, correlacionada à run do agente e à conversa. O feed de anomalias é legível por Member, mas o log de events e o trace de run carregam proveniência de chamada de ferramenta e são Developer+.
4

Converta a descoberta em uma regra

Agora que você viu a cadeia, codifique-a: um deny no export perigoso, uma allow-list de egress no fetch, ou uma regra de sequência que audita o padrão inteiro na próxima vez. A detecção de anomalias encontra o desconhecido; uma regra fixa o conhecido.
Se o feed está ruidoso enquanto você ajusta — um job de batch legítimo que genuinamente pica todo domingo, digamos — dê snooze no feed de anomalias por até 7 dias enquanto investiga. Dar snooze é uma ação Developer+; a janela é limitada pelo servidor para que a detecção sempre volte por conta própria.

​
5. Regras de sequência vs. detecção de anomalias

Elas resolvem problemas adjacentes — escolha a que combina com o que você sabe:
Regra de sequênciaDetecção de anomalias
Você criaA cadeia exataNada — ela aprende
CapturaUm padrão de múltiplos passos conhecidoO desconhecido / anormal
AgeAplica o veredito da regra à chamada que completa (audit / pending_approval / deny)Aparece no feed
Um workspace maduro roda ambos: a detecção de anomalias é o radar que revela cadeias que você não antecipou — apenas revelando, nunca bloqueando; as regras de sequência são como você codifica as que você tem, para que sejam rotuladas, rastreadas e (com um veredito pending_approval ou deny) capazes de controlar a chamada que completa. Para uma parada rígida numa única chamada independentemente de qualquer cadeia, recorra a um veredito por chamada.

​
6. RBAC e as rotas por trás do feed

O feed de anomalias e as regras de sequência ficam sob as rotas de gerenciamento de firewall do workspace — seu token de sessão / acesso, nunca uma chave de relay:
Método & pathPapelPropósito
GET /api/workspace/firewall/anomaliesMemberLê o feed de anomalias (?window=).
POST /api/workspace/firewall/anomalies/snoozeDeveloper+Dá snooze no feed ({until}, limitado a 7 dias).
POST /api/workspace/firewall/rulesDeveloper+Cria uma regra de sequência (ou qualquer) sob uma política.
POST /api/workspace/firewall/testDeveloper+Dry-run de uma política contra uma chamada de amostra antes de depender dela.
Leituras do feed são abertas a cada Member para que toda a equipe possa fazer triagem; criar regras e dar snooze no feed são escritas Developer+, consistentes com o resto do modelo de RBAC do firewall.

​
Para onde ir a seguir

Schema de regra

O campo sequence completo — steps, min_count, window_seconds e todos os outros campos de regra.

Log de events

Onde sequências e anomalias correspondidas aterrissam — filtre por run, superfície e veredito.

Limite de custo

Transforme um sinal burn_spike em um teto de gasto rígido por run.

Controle de egress

Pare o step final de exfiltração de uma cadeia na fronteira de rede.
Para os playbooks de atacante que esses mecanismos combatem, veja ataques encadeados, exfiltração de dados e agência excessiva. Para a referência profunda do firewall, veja Regras do Firewall.