Vai al contenuto principale
Quando un agent corre libero attraverso una dozzina di tool MCP, la domanda che conta a posteriori non è mai “questo singolo tool è sicuro” — è “cosa ha l’agent effettivamente chiamato, cosa ha deciso il firewall, e quale regola ha fatto quella chiamata.” OrcaRouter risponde da un unico posto: il mcp audit log. Ogni tools/call che il gateway MCP valuta sulla superficie mcp atterra come un evento del firewall — verdetto, tool, regola matchata, e il run dell’agent che l’ha emesso — così puoi monitorare una sessione live o ricostruirla più tardi. Questa pagina è il how-to mirato per leggere quella traccia. Per il gateway stesso, il vocabolario dei verdetti e il DSL delle regole, vedi Firewall e Firewall: MCP server.
Ogni lettura qui viene configurata dalla console (o dalla REST API con il tuo session/access token — UserAuth) ed è role-gated. Solo le chiamate relay /v1/* e le route del gateway del firewall portano una chiave in stile sk-orca-....

​
1. Cosa registra il mcp audit log

Ogni chiamata a tool MCP produce un evento del firewall sulla superficie mcp. L’evento porta ciò che ti serve per rispondere a “chi ha chiamato cosa, e cosa ha fatto la policy” — e niente che non dovrebbe (gli argomenti dei tool sono redatti, vedi §4).
verdict (allow / audit / deny / sanitize / pending_approval / observe), surface (mcp qui), policy_name, rule_label, e un reason leggibile dall’uomo. Un flag quarantine marca una chiamata messa in attesa perché la skill proprietaria è in modalità quarantena.
tool_name (con namespace <server>.<tool>), skill_name quando la chiamata è attribuibile a una skill registrata, model_name, e token_name.
agent_run_id, conversation_id e request_id — le chiavi che usi per raggruppare le chiamate di una sessione o per scendere da una richiesta in ogni chiamata che ha diramato.
Un flag gap marca una chiamata in modalità observe che la tua policy attaccata ha visto ma non ha matchato alcuna regola — il segnale che la vista Tool Scoperti usa per presentare i tool che la tua policy non copre ancora.

​
2. Leggere il feed

La tab Events nella console è la vista primaria. Per estrarre gli stessi dati programmaticamente, elenca gli eventi con il tuo access token e filtra alla superficie mcp: 
# Route della console (UserAuth). Leggere gli eventi richiede Developer+.
curl "https://api.orcarouter.ai/api/workspace/firewall/events?surface=mcp&verdict=deny,pending_approval" \
  -H "Authorization: Bearer <your-access-token>"
Il filtro verdict accetta un singolo valore o un insieme separato da virgole (il preset “deny + attese” sopra). Un evento di esempio: 
{
  "created_at": 1700000000,
  "surface": "mcp",
  "tool_name": "github.create_issue",
  "verdict": "deny",
  "policy_name": "Coding agent",
  "rule_label": "no writes to prod org",
  "reason": "rule matched: no writes to prod org",
  "agent_run_id": "run_8f3a",
  "model_name": "claude-sonnet-4-5",
  "token_name": "ci-agent"
}
Per ricostruire l’intero fan-out di una richiesta — ogni tool che il modello ha chiamato sotto una singola richiesta relay — scendi per request id: 
curl "https://api.orcarouter.ai/api/workspace/firewall/events/by-request/<request_id>" \
  -H "Authorization: Bearer <your-access-token>"
Per un rollup a livello di sessione invece delle righe grezze, colpisci GET /api/workspace/firewall/events/aggregate?group_by=run (o group_by=session) — una riga per run di agent con una ripartizione per verdetto, tool distinti, e first/last-seen. Gli endpoint di trace (/trace/runs, /trace/by-run) ricostruiscono l’albero delle chiamate del run.

​
3. Righe di audit della governance del server

Gli eventi per chiamata ti dicono cosa l’agent ha fatto. Una seconda traccia, più piccola, ti dice cosa tu hai fatto alla governance di un server — ed è dove vive la storia del rug-pull. Quando un probe scopre che l’insieme di tool pubblicizzato di un server registrato è driftato, e un admin lo ri-baselinizza o lo mette in quarantena, quella decisione viene scritta nel log di audit del workspace:
Azione di auditScritta quando
firewall_mcp_schema_changedUn probe scopre che l’insieme di tool live è driftato da quello approvato.
firewall_mcp_schema_approvedUn admin ri-baselinizza al nuovo insieme di tool.
firewall_mcp_schema_quarantinedUn admin mette in quarantena (e disabilita) un server driftato.
Ogni riga porta l’id del server, il nome e il conteggio dei tool — mai gli argomenti dei tool o le credenziali. Questa è la traccia forense dietro la Difesa dai rug-pull: un server che hai approvato lunedì non può far crescere in silenzio un tool shell.exec venerdì senza lasciare una riga qui.
Le modifiche a policy, regole e impostazioni del firewall scrivono le proprie righe di audit accanto a queste. Quando un platform admin fa la modifica, atterra anche nel log di audit admin centrale (GET /api/admin/audit-logs, solo admin); la modifica di un membro regolare resta nella traccia del workspace.

​
4. Gli argomenti sono redatti per default

Lo stream degli eventi è costruito per essere leggibile dal tuo team senza far trapelare segreti. Gli argomenti delle chiamate a tool non vengono mai memorizzati verbatim — un evento porta al massimo un args_summary redatto e limitato, e l’hash grezzo degli argomenti usato per il raggruppamento delle anomalie non lascia mai il server.
Poiché gli eventi portano quella snapshot sanitizzata degli argomenti, gli endpoint events, aggregate e trace sono gated Developer+ — un membro di ruolo Viewer può leggere policy e tool scoperti ma non la provenienza delle chiamate a tool di un altro membro. Pianifica i tuoi ruoli di conseguenza.

​
5. Monitoraggio live: anomalie

Leggere a posteriori è una metà; l’altra è essere avvisato mentre sta accadendo. Il feed delle anomalie sorveglia MCP (e ogni altra superficie) per comportamenti che si discostano dal baseline appreso del workspace — picchi di rate e costo rispetto a un profilo ora-della-settimana, loop di retry, e percorsi di tool nuovi — e li presenta senza che tu scriva una singola regola. 
# Il feed delle anomalie è aperto a qualsiasi Member.
curl "https://api.orcarouter.ai/api/workspace/firewall/anomalies?window=5m" \
  -H "Authorization: Bearer <your-access-token>"
Un segnale rumoroso può essere posticipato (fino a 7 giorni) così smette di affollare il feed senza essere silenziato permanentemente. La lettura delle anomalie è aperta a Member — più ampia dello stream degli eventi — perché porta il segnale, non gli argomenti.
Abbina il feed alla shadow mode: fai il rollout di una policy stretta come solo-audit, osserva i would-be deny nello stream degli eventi (reason prefissato [shadow] would …), e promuovila una volta che il feed è silenzioso.

​
6. Retention ed erasure

Gli eventi del firewall scadono automaticamente — non sono uno store permanente, sono una finestra di monitoraggio scorrevole. Le righe di audit del workspace (la traccia di governance del server in §3) sono mantenute fino a 180 giorni. E quando un utente viene eliminato, il ciclo grace-then-scrub si propaga attraverso gli eventi e i match del firewall così la traccia delle chiamate a tool di un utente partito non resta.
I controlli di data-residency e retention vivono nel piano compliance. Il mcp audit log eredita la postura di retention del workspace; non lo configuri per-server.

​
7. Dove andare dopo

Panoramica sulla sicurezza MCP

L’intera superficie di governance MCP — gateway, verdetti, skill, egress.

Difesa dai rug-pull

Gli eventi di drift nel §3, da capo a fondo: rileva, ri-baselinizza, metti in quarantena.

Allow-list dei tool MCP

Trasforma ciò che l’audit log mostra in una policy default-deny.

Firewall: MCP server

Il riferimento completo di campi e route.
Nuovo al modello? Vedi Come OrcaRouter ispeziona per dove gli eventi vengono emessi nel percorso di valutazione, e Agency eccessiva per la minaccia che una traccia di audit pulita ti aiuta a cogliere presto.