Saltar para o conteúdo principal
As regras de firewall estáticas pegam as chamadas que você sabia nomear. Elas não conseguem pegar a chamada que é individualmente permitida mas errada no agregado — 200 chamadas db.query às 3h de domingo, um agente martelando uma ferramenta que falha em um loop apertado, um salto ferramenta-a-ferramenta que este workspace nunca fez antes. Cada chamada passa por cada regra; o padrão é o problema. A detecção de anomalias do firewall é a camada comportamental. O gateway aprende a forma normal de uso de ferramentas do seu workspace e pontua a atividade ao vivo contra ela, trazendo à tona os desvios em um feed que qualquer Member pode ler. É como você percebe um agente comprometido ou um loop descontrolado sem ter pré-escrito uma regra para uma forma que você nunca viu. Esta página é o landing focado para esse feed de detecção de anomalias do firewall; a Visão geral do Firewall é a referência profunda.
O feed de anomalias é detecção, não enforcement. Ele lhe diz o que parece fora — ele não bloqueia. Quando um padrão é real, você o transforma em uma regra ou um veredito com rate-limit para que a próxima ocorrência seja parada inline. Ler o feed é aberto a cada Member; transformar um achado em política é Developer+.

​
1. O que a detecção de anomalias do firewall sinaliza

Quatro tipos de sinal, cada um ligado a um modo de falha diferente:
Volume de chamada por ferramenta pontuado contra um baseline aprendido de hora-da-semana. Uma ferramenta dispara rate_spike quando sua contagem cruza um piso absoluto e roda alta relativa ao baseline para aquela hora, ou quando seu z-score cruza o threshold. Chavear em hora-da-semana (não hora-do-dia) significa que terça-14:00 é comparada com terças-14:00 passadas, de modo que o tráfego de pico de dia útil legítimo não se lê como um pico enquanto o mesmo volume às 3h de domingo sim.
A mesma comparação de hora-da-semana, aplicada ao custo acumulado em vez da contagem de chamadas. Uma ferramenta cujo gasto roda bem acima de sua norma de custo aprendida aparece como um burn_spike — o sinal de alerta-precoce para um agente que é caro antes de ser destrutivo.
Um grupo (conversation, tool, arguments) que se repete muitas vezes dentro de uma janela curta — um agente preso reemitindo a mesma chamada de ferramenta que falha em vez de se recuperar. Polling legítimo e lento não o dispara; o sinal é um loop apertado.
Uma transição consecutiva tool_a → tool_b para a qual este workspace não tem baseline aprendido. A primeira vez que um agente vai, digamos, de crm.read → http.fetch, essa aresta é nova — exatamente o tipo de passo que uma cadeia de exfiltração de dados dá.
A detecção de anomalias complementa as regras de sequência. Uma regra de sequência corresponde a uma cadeia que você definiu de antemão; novel_path sinaliza uma transição que você não definiu — é como você descobre as cadeias que valem escrever uma regra de sequência.

​
2. O baseline de 14 dias

O detector não é um threshold fixo — é uma norma aprendida. Para cada bucket (tool, hour-of-week) o gateway mantém uma contagem-de-chamada e custo esperados móveis, preenchidos a partir de um lookback de 14 dias (cerca de duas ocorrências de cada bucket de hora-da-semana — o suficiente para suavizar um único dia estranho sem perder a forma semanal). novel_path usa o baseline de transição paralelo: a contagem de ocorrência aprendida para cada aresta tool_a → tool_b naquela hora-da-semana. Um workspace novinho ainda não tem baseline. Tudo bem: sem norma aprendida, os detectores de volume caem para um piso absoluto, de modo que uma enchente óbvia ainda é pega no dia um enquanto as normas por hora se preenchem.
SinalDe que ele aprende
rate_spike / burn_spikeContagem e custo por (tool, hour-of-week), móvel de 14 dias.
novel_pathContagem de transição por (tool_a → tool_b, hour-of-week).
retry_loopSem baseline — um threshold de repetição em janela em (conversation, tool, args).
O feed reporta nomes de ferramenta, ids de token redigidos e contagens apenas. Um id de chave de API bruto nunca aparece — cada item carrega um digest unidirecional do token chamador, de modo que você pode distinguir duas anomalias sem o feed jamais vazar a chave por trás delas.

​
3. Uma leitura concreta

Digamos que uma chave de agente comece a entrar em loop. Puxe o feed no console em Security → Firewall → Anomalies, ou leia-o diretamente — qualquer Member pode: 
curl https://api.orcarouter.ai/api/workspace/firewall/anomalies \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN"

{
  "data": {
    "items": [
      {
        "id": "3f1c9a7b0e2d4a86",
        "kind": "retry_loop",
        "tool_name": "db.query",
        "token_id_redacted": "sk-***-9f2a",
        "count": 412,
        "baseline": 0,
        "z_score": 0,
        "suggested_action": "rate_limit",
        "first_seen": 1749470400,
        "last_seen": 1749470520
      }
    ],
    "snoozed_until": 0
  }
}
Um item retry_loop não carrega baseline nem z_score (esses campos permanecem 0 — pertencem aos detectores de volume/custo), e carrega um id opaco estável de modo que dois loops distintos na mesma ferramenta não colidem em uma linha. Um rate_spike é o inverso: ele reporta um baseline aprendido e um z_score, e deixa id vazio.
$ORCA_SESSION_TOKEN é seu token de sessão / acesso de console — a mesma auth que cada rota de gerenciamento /api/workspace/firewall/*. Não é uma chave de relay sk-orca-… (essas são apenas para chamadas de modelo /v1/*) e não é uma chave de firewall-gateway. Uma chave de relay nesta rota é rejeitada.
Cada item nomeia a ferramenta, o token redigido, quantas chamadas dispararam, o z-score (apenas sinais de volume/custo), e uma suggested_action (rate_limit, block_tool, ou review). A partir daqui você age: solte uma regra deny na ferramenta, valide seus argumentos, ou abra o log de eventos para ver exatamente o que o agente fez.

​
4. Dando snooze no feed

Um teste de carga conhecido ou um backfill planejado vai acender o feed. Em vez de perseguir ruído, dê snooze nele — por até 7 dias: 
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/anomalies/snooze \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"until": 1749643200}'
Enquanto um snooze está ativo o feed não retorna itens e reporta snoozed_until; ele se limpa no momento em que o prazo passa. O cap é um teto rígido — um until digitado errado ou hostil mais adiante é clampeado para que a detecção de anomalias não possa ser silenciada indefinidamente. Postar um until passado ou agora limpa um snooze existente.
Ler o feed é uma ação Member; dar snooze nele é Developer+ — mutar um sinal de segurança de todo o workspace é uma escrita, não uma leitura.

​
5. RBAC num relance

A superfície de analytics se divide ao longo da linha usual de leitura/ação:
AçãoPapel
Ler o feed de anomaliasMember
Ler configurações, políticas, ferramentas descobertasMember
Dar snooze no feedDeveloper+
Events, runs, aggregate, traceDeveloper+
Criar uma regra a partir de um achadoDeveloper+
As visões de agregado mais leves — configurações, políticas, e o mapa de cobertura de ferramentas descobertas — são leituras de Member também; o detalhe em nível de linha de eventos e runs é Developer+, porque carrega dados de argumento por chamada.

​
6. Do sinal à política

O feed é o começo de um loop, não o fim:
1

Detecte o padrão

Um novel_path ou rate_spike mostra uma forma que você não esperava. Leia-a contra o log de eventos para confirmar que é real, não um caso isolado.
2

Escreva a regra

Transforme o achado em enforcement — um block, uma cláusula de argumento, uma regra de sequência para a cadeia, ou um cap de custo para o burn.
3

Faça o rollout com segurança

Lance a regra sob shadow mode primeiro para medir seu raio de explosão antes que ela bloqueie uma única chamada, depois aplique o enforcement.

​
Para onde ir a seguir

Visão geral do Firewall

A referência completa de detecção de anomalias e o resto do plano de política.

Log de eventos

Aprofunde de uma anomalia até as chamadas exatas por trás dela.

Bloquear uma ferramenta

Transforme um achado em uma regra de enforcement.

Modos de enforcement

Como detecção, audit, shadow e enforce se encaixam.
Para as ameaças que estes sinais expõem, veja exfiltração de dados e agência excessiva.