Summary

When the FirewallVerifier or other pre-execution verifiers block a tool call, the block event is logged as a WARN trace and increments pre_execution_blocks metrics — but no AuditEntry is written to the audit log (.local/testing/data/audit-test.jsonl stays empty for blocked calls).

Reproduction

1. Run agent with [tools.audit] enabled = true
2. Ask it to: Use the read tool to read /etc/passwd
3. Agent outputs: [error] Tool call to read was blocked by pre-execution verifier.
4. Check audit file: empty — no "type":"blocked" entry

Expected

The audit log should contain an entry like:

{"timestamp":"...","tool":"read","command":"/etc/passwd","result":{"type":"blocked","reason":"[FirewallVerifier] sensitive path pattern '/etc/passwd' matched..."},"duration_ms":0}

Root Cause

Pre-execution blocking happens in native.rs (around line 681). At that point:

• AuditResult::Blocked is NOT created or written
• Only tracing::warn! and self.update_metrics() are called

The AuditResult::Blocked path exists in ShellExecutor::check_permissions() (shell policy blocklist), but FirewallVerifier blocks in native.rs bypass the shell executor entirely.

Impact

• Security audits are incomplete: all FirewallVerifier blocks are invisible in the audit trail
• SIEM integrations that parse the audit JSONL would miss pre-execution firewall events
• Compliance: the audit log is supposed to be a complete record of all tool call outcomes