The Security View: 36 Events, 28 Blocks, and Live Injection Intercepts
A filterable audit log of every security check the harness has fired — 36 real events across six defensive layers, including injection scanner intercepts with verbatim payload, sensitive file access blocks, and Python execution rejections.
The harness runs research tasks autonomously, which means it fetches web content, executes Python, reads and writes files, and — via the Playwright skill — controls a browser. Each of those capabilities is a potential attack surface. The Security view is the audit log for the defensive layers that gate those capabilities: every check that fired, every block that landed, and every injection pattern the scanner matched.
Security view: 36 events across all layers. The KPI row breaks down by severity (28 blocked, 8 warnings) and by event type. The visible rows show injection scanner WARN events — actual prompt injection strings found in web search results — and an output sandbox BLOCK for ~/.Desktop/.env.local.
The Six Defensive Layers
Six scanners instrument different choke points in the pipeline:
run_python / execute_python tool invocations before execution. Rejects code that imports os, subprocess, sys, or socket in unsafe patterns; blocks shell escape attempts and file system traversal. Logs as BLOCK. 16 events — the most active layer.
.env files, SSH keys, browser credential stores, or any path outside the permitted workspace. Logs as BLOCK. 8 events.
javascript: URIs, and internal network addresses (localhost, 169.254.x.x, etc.). 0 events in the current log.
/scratchpad skill's Python execution workspace. Restricts imports and syscalls within the scratchpad sandbox, separate from the main Python scanner. 0 events in the current log.
What the Log Actually Shows
The current 36 events break down as follows:
- 8 injection detections (all WARN) — prompt injection strings found inside web content fetched during research runs. The injection scanner flagged these before they reached synthesis.
- 16 Python blocks — attempts by the synthesis or tool-loop LLM to call
run_pythonwith code that violated the scanner policy. - 8 file blocks — file access attempts outside the allowed workspace.
- 4 output blocks — synthesis outputs containing sensitive file paths or credential-like patterns that the output sandbox rejected before writing to disk.
The actual payloads visible in the screenshot are instructive. The injection scanner WARN rows show verbatim strings from web content:
These are classic indirect prompt injection strings — text embedded in web pages that attempts to override the model's instructions when fetched as research context. The scanner flags them as WARN rather than BLOCK because blocking would silently drop web content; the decision of whether to include flagged content in synthesis is left to the run's evaluation score.
The output sandbox BLOCK for ~/.Desktop/.env.local is a different class of event: the synthesis output contained an absolute path to a local environment file, which the output sandbox treated as a sensitive path pattern and blocked before the file was written.
The injection events in this log came from research runs on prompt injection defense — the harness was fetching papers about the attack, and those papers (or the pages linking to them) contained example payloads in their content. The scanner fired on real research content, not on malicious external actors.
Filters and Detail Panel
Three filter rows narrow the event table:
injection_scanner events in isolation — the resource column shows exactly what text triggered the match.
Clicking any row expands a sticky detail panel on the right. The panel shows the full event ID, precise timestamp, event type, layer label, caller (the function that triggered the check), run ID (links to the Runs view), the reason string from the scanner, and the full resource field — the actual payload, file path, or code snippet that triggered the event.
WARN vs BLOCK
WARN events are logged and flagged but don't halt the run. BLOCK events reject the action — the Python call fails, the file write is skipped, the output is not saved. A run that triggered a BLOCK may still PASS if it recovered; check the run record for the full outcome.
Run linkage
Every security event carries the run ID of the pipeline execution that triggered it. Click through to the Runs view to see the full pipeline context — what task was running, what stage it was in, and whether the run ultimately passed or failed.
Text search
The search input at the top matches against both the resource field and the reason string. Search .env to find all file access attempts involving environment files, or ignore all previous to surface injection events by payload content.
Persistent log
Security events are written to data/security_events.jsonl and persist across server restarts. The log grows as the harness runs more tasks — the 36 events shown here accumulated across several weeks of active research runs.
The Security view is the operational complement to the theoretical OWASP coverage described in Agentic Threat Hardening. The earlier post describes what the defenses are and where the gaps are; the Security view shows what they actually caught.