Saltar para o conteúdo principal
Quando um revisor de compliance pergunta “quem mudou esta política de firewall, e quando?”, a resposta é uma linha no log de auditoria do seu workspace. Toda mutação que toca um recurso governado — uma política de firewall, uma regra, um guardrail, um prompt, uma decisão de aprovação, o papel de um membro — escreve uma linha de auditoria imutável carimbada com o ator, o alvo, o timestamp e um verbo de ação estável. Esta página é a tabela de consulta para esses verbos: o conjunto completo de ações de log de auditoria, agrupadas pelo recurso que descrevem, para que você possa filtrar a trilha exatamente aos eventos de que precisa.
Uma linha de auditoria registra quem fez o quê a qual recurso. Ela nunca carrega valores secretos, texto em claro de chave de gateway, blobs de regra ou corpos de prompt — o payload é apenas metadados seguros (ids, nomes, verdict, stage, is_default). Para a trilha de enforcement do que uma política fez ao tráfego ao vivo — chamadas de ferramenta negadas, PII mascarada — veja os feeds de Firewall events e Guardrail Matches, que são um armazenamento separado deste log de auditoria.

​
1. O que o catálogo de ações de log de auditoria cobre

Duas coisas escrevem na trilha de auditoria, e ajuda mantê-las separadas:
  • Log de auditoria — esta página. Um registro append-only de mudanças de configuração e governança: uma política editada, um membro convidado, uma aprovação resolvida. Carimbado com o verbo de ação, o ator e o momento em que foi commitado, depois que a mudança é bem-sucedida.
  • Feeds de enforcement — os feeds de Firewall events e Guardrail Matches. O registro de toda decisão de runtime que o gateway tomou em uma requisição. Maior volume, armazenamento diferente.
Os verbos de ação abaixo são strings estáveis em lower-snake-case. Eles sobrevivem a renomeações no console, fazem grep limpo em um export, e são o que você filtra quando fatia a trilha por tipo de evento.
Toda escrita governada emite sua linha de auditoria na mesma transação que a mudança, então a trilha nunca pode divergir da realidade — não há janela de “a edição commitou mas a linha de auditoria não”.

​
2. As ações de log de auditoria, agrupadas por recurso

O OrcaRouter traz um catálogo fixo de verbos de ação. Os que você cria no dia a dia caem nos grupos abaixo.
Todo create / update / delete em uma política de firewall ou uma de suas regras, mais mudanças de settings em nível de workspace:firewall_policy_create · firewall_policy_update · firewall_policy_delete · firewall_rule_create · firewall_rule_update · firewall_rule_delete · firewall_settings_updatePayloads de política carregam {id, name, is_default, default_verdict, enabled}; payloads de regra carregam {id, policy_id, verdict, stage, tool_name_glob, priority}. Nunca o blob completo da regra.
O seletor de autonomia em um clique (tight / balanced / permissive) escreve uma linha quando aplicado e uma quando desfeito:firewall_autonomy_applied · firewall_autonomy_undoneA linha applied carrega o snapshot de undo pré-aplicação em seu payload, que é exatamente do que o undo em um clique reconstrói.
Quando um revisor resolve uma chamada de ferramenta retida (um veredito pending_approval), a decisão é registrada:firewall_approval_approve · firewall_approval_rejectO payload anota se a decisão veio via o console ou um callback de webhook fora de banda — nunca os argumentos da ferramenta.
Ações sobre o conjunto de ferramentas governado de um servidor MCP registrado — quando seu conjunto de ferramentas ao vivo é encontrado diferindo do conjunto aprovado, quando um admin re-aprova o conjunto atual, e quando um admin coloca um servidor em quarentena:firewall_mcp_schema_changed · firewall_mcp_schema_approved · firewall_mcp_schema_quarantinedO payload é {mcp_server_id, name, tool_count} — nunca argumentos de ferramenta ou credenciais.
Trilha forense para o registro de prompts — create, edit, soft-delete (Trash), hard-delete (Purge), restore, label move, version rollback e import de um provedor conectado:prompt_created · prompt_updated · prompt_deleted · prompt_purged · prompt_restored · prompt_label_moved · prompt_rollback · prompt_importedOs payloads serializam apenas metadados seguros (id, name, kind, tags) — nunca o conteúdo ou as mensagens do prompt.
Eventos de ciclo de vida e associação no próprio workspace — criação, arquivamento, convites, mudanças de papel, remoções, top-ups de carteira e mudanças de assento / grupo / status:workspace_create · workspace_archive · invite · invite_resend · invite_revoke · accept · member_leave · role_change · remove · workspace_topup · group_change · seats_limit_change · status_change · workspace_promote_to_team
Edições de guardrail mantêm seu próprio histórico de versões por guardrail — uma trilha de diff-e-revert anexada a cada política — além do log de auditoria. Quando você precisa reverter uma mudança de política de conteúdo, esse histórico é a superfície a usar.

​
3. Um exemplo concreto: rastreando uma mudança de política de firewall

Digamos que um colega afrouxou uma regra de deny semana passada e você precisa saber exatamente o que mudou. Abra a gaveta de auditoria do workspace no console e filtre pela ação firewall_rule_update. Cada linha correspondente lhe dá o mesmo formato:
CampoO que ele lhe diz
Actionfirewall_rule_update — o verbo pelo qual você filtrou.
ActorO membro que fez a mudança.
TargetO {id, policy_id} da regra e seu novo verdict, stage, tool_name_glob, priority.
Isso é suficiente para reconstruir o antes/depois da regra sem nunca expor suas cláusulas de correspondência completas. Se a mudança foi uma troca de nível de autonomia, filtre por firewall_autonomy_applied e a linha carrega o snapshot do qual o undo em um clique restaura.
Filtrar por um único verbo de ação é a maneira mais rápida de responder uma pergunta pontual no tempo (“quando ligamos o auto-approve?”, “quem deletou aquela política?”). Os verbos são strings estáveis, então um filtro salvo continua funcionando entre redesenhos do console.

​
4. Escopo, retenção & erasure

Escopo de workspace

Cada linha de auditoria pertence a exatamente um workspace e é legível apenas dentro dele — nada cruza a fronteira de tenant. O ator, alvo e payload são todos com escopo para aquele workspace. Veja Escopo, chaves & políticas.

Retenção

Linhas de auditoria são retidas por até 180 dias, depois expiram por uma limpeza em background. Seus logs de requisição são um armazenamento separado com sua própria retenção — um padrão de 30 dias, limitado no servidor a um máximo rígido de 180 dias.

Direito ao apagamento

Em uma exclusão de workspace ou requisição explícita de apagamento, o OrcaRouter concede uma janela de carência de 30 dias, depois remove a PII de logs e registros de auditoria daquele workspace. Veja o glossário.

Evidência de compliance

A trilha de auditoria é um dos sinais dos quais um compliance pack extrai para um relatório de prontidão assinado. Os relatórios são assinados por Ed25519 e publicamente verificáveis.
Não recorra ao log de auditoria para responder “esta requisição foi bloqueada?” — isso vive nos feeds de enforcement, não aqui. O log de auditoria responde “esta política foi mudada, e por quem?”. Eles são armazenamentos deliberadamente separados com retenção diferente e caminhos de acesso diferentes. Veja Por que isto foi bloqueado? para o lado de runtime.

​
5. Para onde ir a seguir

Observabilidade do firewall

Os feeds de events, runs e discovered-tools — o registro de enforcement de runtime que complementa esta trilha de configuração.

Glossário de vereditos

Cada veredito de firewall e ação de guardrail que a trilha referencia, com status HTTP e impacto na cota.

API de Compliance

Transforme a trilha em um relatório de prontidão assinado e compartilhável com auditor.

Escopo, chaves & políticas

Como o escopo de workspace limita o que qualquer linha de auditoria pode expor.