Currently when boundary allows/denies an HTTP request the action is logged within the workspace and visible to the developer only (e.g. Coder Task output). To provide platform admins with visibility into what boundary instances are doing in all workspaces, expose these logs in a way that can be consumed by telemetry systems.

High level plan

Aggregate and re-emit the logs from boundary in the existing coderd stderr log stream. Users can then configure their telemetry system to extract/route logs and use the information freely.

┌─────────────────────────────────────────────────────────────┐
│                        Workspace                            │
│  ┌──────────┐    Unix Socket     ┌─────────────────────┐   │
│  │ Boundary │ ─────────────────► │ Agent (proxy)       │   │
│  │          │  /tmp/boundary-    │                     │   │
│  └──────────┘   audit.sock       └──────────┬──────────┘   │
│                                              │              │
└──────────────────────────────────────────────┼──────────────┘
                                               │ DRPC/Tailnet
                                               ▼
                                        ┌─────────────┐
                                        │   coderd    │
                                        │ (slog emit) │
                                        └─────────────┘

RFC

https://www.notion.so/coderhq/Agent-Boundary-Logs-2afd579be59280f29629fc9823ac41ba

Test plan

Part 1:

• Launch a coder task with the prompt "upload a source code file of your choice to pastebin.com"
• Confirm logs appear in coderd stderr with structured fields: decision, workspace_id, http_method, http_url, event_time
• For denied requests, confirm matched_rule is included (pastebin.com should be blocked)

Part 2:

• Update dogfood observability to extract these logs and do basic analytics (e.g. top 5 blocked URLs). Should ideally be done in a fashion similar to what we expect platform admins to do