Falta de atribuição e forense

Quando algo dá errado com um agente, a primeira pergunta é sempre a mesma: o que ele realmente fez, e quem mudou a política que permitiu isso? Sem uma trilha você não consegue responder a nenhuma das duas. Você não consegue mostrar a um auditor que um controle estava em vigor no dia em questão, não consegue distinguir um ataque real de um falso positivo barulhento, e não consegue reconstruir a run que vazou a linha. O OrcaRouter registra a resposta conforme você avança. Cada prompt filtrado, cada chamada de ferramenta, cada aprovação e cada edição de política cai em um registro consultável e com escopo de workspace — correlacionado de volta à run e sessão do agente que o produziu. Esta página mostra como usar esse registro como uma trilha de auditoria de agente de ia: de uma única run suspeita a um relatório assinado que você entrega a um auditor.

​

1. Os quatro registros por trás de uma trilha de auditoria de agente de ia

A atribuição vem de quatro fluxos independentes, cada um correlacionado à mesma run e sessão para que você possa pivotar entre eles: O tecido conjuntivo é o id da run de agente e da sessão. Uma match de guardrail e um event de firewall da mesma conversa carregam a mesma linhagem de run, então “esta run mascarou um e-mail, depois tentou um fetch que negamos, depois foi aprovada para uma escrita” se lê como uma única história em vez de três logs desconectados.

​

2. Matches de Guardrail — o que foi filtrado (Member)

Cada vez que uma regra de guardrail dispara, o gateway escreve uma match. O feed vive na página de Guardrails (aba Matches) e é legível por qualquer membro do workspace. Cada match registra o tipo de regra, a ação tomada (block / mask / flag / annotate / spotlight), o stage (input / output), uma string de detalhe e a linhagem de run da requisição que a disparou. Liste-a, agrupe-a por guardrail ou tipo de regra, filtre por ação, mergulhe em uma única match ou exporte o feed para CSV. Uma regra barulhenta faz parte da trilha também. Marque uma match como falso positivo com POST /api/guardrail/match/:id/mark-fp (Admin) para que seu sinal permaneça limpo e seus relatórios não contem em excesso.

​

3. Events & Runs de Firewall — o que o agente fez (Developer+)

Onde Matches cobrem texto, os Events de firewall cobrem ações. Cada avaliação de chamada de ferramenta é registrada com seu veredito, superfície, nome de ferramenta e — criticamente — a run e sessão de agente à qual pertence. Leituras em Events, no rollup de Runs/sessões e no trace por-run exigem Developer+; os feeds mais leves de Discovered-tools e de anomalias estão abertos a qualquer Member. A view Runs & sessions é o cavalo de batalha forense: ela agrega events por run de agente em um breakdown de veredito, as ferramentas e modelos distintos que a run tocou e timestamps de primeira/última-vez-vistas — a resposta “o que este agente realmente fez” em uma única tela. Além dos vereditos estáticos, o feed de anomalias sinaliza desvios da baseline por hora-da-semana aprendida de cada workspace (uma média móvel de 14 dias) — picos de taxa e custo, retry_loop e transições novel_path — de modo que um padrão permitido-mas-anormal ainda aparece no registro.

​

4. Decisões de aprovação — quem disse sim (ação de auditoria)

Quando uma regra resolve para pending_approval, a chamada retida se torna uma revisão out-of-band (veja o fluxo HITL do Firewall). A decisão faz parte da trilha: aprovar ou rejeitar escreve uma linha de auditoria de workspace — firewall_approval_approve ou firewall_approval_reject — nomeando o ator. As decisões são first-writer-wins e idempotentes, e se a regra subjacente mudou após a retenção, o enriquecimento nota que o contexto mudou. Então uma chamada de ferramenta retida-e-depois-aprovada é totalmente atribuível de ponta a ponta: o event de firewall mostra a retenção, a linha de auditoria mostra quem a liberou, e ambos correlacionam à mesma run.

​

5. Auditoria de mudança de política — quem mudou as regras

Uma trilha de comportamento de agente só é confiável se você também pode provar qual era a política na época — e quem a mudou. Guardrails mantêm um histórico de versões completo. Cada create, update e delete escreve uma linha de histórico versionada na mesma transação da mudança. Abra History em um guardrail para ver cada versão com autor e timestamp, fazer diff de quaisquer duas e reverter para uma mais antiga (reverter é registrado como uma nova versão — o histórico nunca é mutado). Mudanças de política, regra e configurações do Firewall escrevem cada uma uma linha de auditoria de workspace depois que a mudança é commitada — firewall_policy_update, firewall_rule_create, firewall_settings_update, e assim por diante — e mudanças de nível de autonomia (firewall_autonomy_applied / firewall_autonomy_undone) capturam o snapshot do estado-anterior que alimenta o desfazer em um clique. Segredos e blobs de regra nunca são registrados.

​

6. Um exemplo trabalhado: rastreie uma run suspeita

Suponha que uma run é sinalizada por uma chamada outbound inesperada. Do console, com uma sessão Developer+: Uma run, quatro registros correlacionados, sem arqueologia de log-grep. Para as próprias defesas de exfiltração, veja Exfiltração de dados e Chamadas de ferramenta perigosas.

​

7. Relatórios de compliance assinados — uma trilha que um auditor pode verificar

Para prova externa, a superfície de Compliance transforma esta trilha em um único artefato. Navegar no catálogo de frameworks, packs e prontidão é aberto a qualquer Member e gratuito; instalar um pack, gerar um relatório, entrar em produção e definir residência de dados são ações de Admin de workspace em um plano pago (gated no servidor). Um relatório de compliance é assinado com Ed25519 com um hash de conteúdo SHA256 e é publicamente verificável — o destinatário o checa sem uma conta OrcaRouter: Relatórios exportam como CSV / JSON / PDF. Frameworks incluem soc2, hipaa, gdpr, iso_27001, iso_42001, nist_ai_rmf, pci_dss, o EU AI Act (eu_ai_act) e o OWASP Top 10 para Aplicações de LLM (owasp_llm), entre outros — instalar um pack materializa os guardrails e políticas de firewall correspondentes para que os controles sobre os quais você reporta sejam os controles realmente aplicados.

​

8. Retenção e o direito ao apagamento

Um registro forense é limitado, não eterno. Request logs têm retenção padrão de 30 dias e são clampeados no servidor a um máximo rígido de 180 dias. Quando um usuário se auto-deleta, uma janela de carência de 30 dias se aplica, após a qual sua PII é depurada e a cascata purga suas matches de guardrail, request logs e events de firewall — satisfazendo obrigações de direito-ao-apagamento / DSAR enquanto mantém o histórico de auditoria agregado intacto.

​

9. Para onde ir a seguir