Skip to main content
When an agent runs loose across a dozen MCP tools, the question that matters after the fact is never “is this one tool safe” — it’s “what did the agent actually call, what did the firewall decide, and which rule made that call.” OrcaRouter answers that from one place: the mcp audit log. Every tools/call the MCP gateway evaluates on the mcp surface lands as a firewall event — verdict, tool, matched rule, and the agent run that issued it — so you can monitor a session live or reconstruct it later. This page is the focused how-to for reading that trail. For the gateway itself, the verdict vocabulary, and the rule DSL, see Firewall and Firewall: MCP servers.
Every read here is configured from the console (or the REST API with your session/access token — UserAuth) and is role-gated. Only /v1/* relay calls and the firewall gateway routes carry an sk-orca-...-style key.

​
1. What the mcp audit log records

Each MCP tool call produces one firewall event on the mcp surface. The event carries what you need to answer “who called what, and what did the policy do” — and nothing it shouldn’t (tool arguments are redacted, see §4).
verdict (allow / audit / deny / sanitize / pending_approval / observe), surface (mcp here), policy_name, rule_label, and a human-readable reason. A quarantine flag marks a call held because the owning skill is in quarantine mode.
tool_name (namespaced <server>.<tool>), skill_name when the call is attributable to a registered skill, model_name, and token_name.
agent_run_id, conversation_id, and request_id — the keys you use to group a session’s calls or drill from one request into every call it fanned out.
A gap flag marks an observe-mode call your attached policy saw but matched no rule — the signal the Discovered Tools view uses to surface tools your policy doesn’t cover yet.

​
2. Reading the feed

The Events tab in the console is the primary view. To pull the same data programmatically, list events with your access token and filter to the mcp surface: 
# Console route (UserAuth). Reading events requires Developer+.
curl "https://api.orcarouter.ai/api/workspace/firewall/events?surface=mcp&verdict=deny,pending_approval" \
  -H "Authorization: Bearer <your-access-token>"
The verdict filter accepts a single value or a comma-separated set (the “denies + holds” preset above). A sample event: 
{
  "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"
}
To reconstruct one request’s full fan-out — every tool the model called under a single relay request — drill in by request id: 
curl "https://api.orcarouter.ai/api/workspace/firewall/events/by-request/<request_id>" \
  -H "Authorization: Bearer <your-access-token>"
For a session-level rollup instead of raw rows, hit GET /api/workspace/firewall/events/aggregate?group_by=run (or group_by=session) — one row per agent run with a per-verdict breakdown, distinct tools, and first/last-seen. The trace endpoints (/trace/runs, /trace/by-run) reconstruct the run’s call tree.

​
3. Server-governance audit rows

Per-call events tell you what the agent did. A second, smaller trail tells you what you did to a server’s governance — and it’s where the rug-pull story lives. When a probe finds a registered server’s advertised tool set has drifted, and an admin re-baselines or quarantines it, that decision is written to the workspace audit log:
Audit actionWritten when
firewall_mcp_schema_changedA probe finds the live tool set drifted from the approved one.
firewall_mcp_schema_approvedAn admin re-baselines to the new tool set.
firewall_mcp_schema_quarantinedAn admin quarantines (and disables) a drifted server.
Each row carries the server id, name, and tool count — never tool arguments or credentials. This is the forensic trail behind Rug-pull defense: a server you approved on Monday can’t silently grow a shell.exec tool on Friday without leaving a row here.
Firewall policy, rule, and settings changes write their own audit rows alongside these. When a platform admin makes the change, it also lands in the central admin audit log (GET /api/admin/audit-logs, admin-only); a regular member’s edit stays in the workspace trail.

​
4. Arguments are redacted by default

The event stream is built to be readable by your team without leaking secrets. Tool-call arguments are never stored verbatim — an event carries at most a capped, redacted args_summary, and the raw argument hash used for anomaly grouping never leaves the server.
Because events carry that sanitized argument snapshot, the events, aggregate, and trace endpoints are gated Developer+ — a Viewer-role member can read policies and discovered tools but not another member’s tool-call provenance. Plan your roles accordingly.

​
5. Live monitoring: anomalies

Reading after the fact is one half; the other is being told while it’s happening. The anomaly feed watches MCP (and every other surface) for behavior that breaks from the workspace’s learned baseline — rate and cost spikes against an hour-of-week profile, retry loops, and novel tool paths — and surfaces them without you writing a single rule. 
# Anomaly feed is open to any Member.
curl "https://api.orcarouter.ai/api/workspace/firewall/anomalies?window=5m" \
  -H "Authorization: Bearer <your-access-token>"
A noisy signal can be snoozed (up to 7 days) so it stops crowding the feed without being permanently silenced. The anomaly read is Member-open — broader than the event stream — because it carries the signal, not the arguments.
Pair the feed with shadow mode: roll a tightened policy out as audit-only, watch the would-be denies in the events stream (reason prefixed [shadow] would …), and promote it once the feed is quiet.

​
6. Retention and erasure

Firewall events expire automatically — they’re not a permanent store, they’re a rolling monitoring window. Workspace audit rows (the server-governance trail in §3) are kept up to 180 days. And when a user is deleted, the grace-then-scrub cycle cascades through firewall events and matches so a departed user’s tool-call trail doesn’t linger.
Data-residency and retention controls live in the compliance plane. The mcp audit log inherits the workspace’s retention posture; you don’t configure it per-server.

​
7. Where to go next

MCP security overview

The whole MCP governance surface — gateway, verdicts, skills, egress.

Rug-pull defense

The drift events in §3, end to end: detect, re-baseline, quarantine.

Allow-list MCP tools

Turn what the audit log shows into a default-deny policy.

Firewall: MCP servers

The complete field-and-route reference.
New to the model? See How OrcaRouter inspects for where events are emitted in the evaluation path, and Excessive agency for the threat a clean audit trail helps you catch early.