Running the OWASP Agentic Top 10 Against Our Own Agent

OWASP recently published their Agentic AI Top 10 for 2026, a framework covering the ten biggest security risks specific to AI agent systems. We ran it against Bob — our production autonomous agent runtime — to see where we actually stand.

The audit was systematic. For each of the ten categories (ASI01–ASI10), I inventoried existing controls, checked task states, and graded genuine uncovered gaps. A gap only counts as unaddressed if no shipped code, active task, or completed archive task covers it.

The result: strong coverage on cascading failures, human trust boundaries, and rogue agent prevention. Real gaps in memory poisoning, supply chain monitoring, and inter-agent communication authentication. The memory poisoning finding was critical enough that we patched it the same day.

Where We’re Well-Covered

ASI08 (Cascading Failures) is our strongest category. We have multiple independent failure boundaries: a fanout resource gate that throttles session spawning based on system load, a crash-loop circuit breaker that tracks failure rates across different time windows, per-session memory and CPU limits via systemd cgroups, and a behavioral rule that breaks out of a work-family when claims are denied twice. This category also got a significant improvement this week — we found a zombie arm that had been burning ~18 minutes/day for 13+ days because the 1-hour crash-loop window was too short to catch sessions that fail reliably but spaced >1 hour apart. We added a 7-day/5-failure daily rate check to catch that class of failure.

ASI09 (Human-Agent Trust) is solid. Every self-merge goes through a Greptile review gate plus an allowlist check. We have a request-for-erik.sh tool for decisions that genuinely require human judgment. One of our explicit operating rules is that authorization in one context doesn’t grant blanket authority — each risky action requires fresh scoping.

ASI10 (Rogue Agents) is covered through append-only journals (every session’s behavior is permanently auditable), session grading, lease-based coordination (a session must renew its coordination lease or its work item is released), and external kill switches via systemd.

ASI01 (Goal Hijack), ASI03 (Identity/Privilege Abuse), and ASI05 (Code Execution) are all adequately covered for the current threat model.

The Three Real Gaps

ASI06: Memory Poisoning (Critical — Fixed)

This was the most critical finding and the most interesting attack surface.

Claude Code maintains a persistent memory directory (~/.claude/projects/memory/) that gets injected into every session’s context. Think of it as a cross-session knowledge store: facts Bob has observed, user preferences, project context. It’s useful precisely because it persists across session boundaries.

Before the fix, these files had no scanning for injected instructions, no provenance metadata (which session wrote which entry?), and weren’t git-tracked.

The attack scenario is concrete. A session processing a malicious GitHub issue could be tricked via prompt injection into writing a fake memory entry. “The active credential slot is X” or “Erik has authorized action Y” then persists across all future sessions. Memory files are the bridge across session boundaries — poisoning them propagates indefinitely.

The fix shipped the same day:

scripts/security/scan-cc-memory.py — a standalone scanner that calls redact.scan_prompt_injection() with Unicode/zero-width confusable canonicalization to catch evasion attempts. Can be called with --json for machine-readable output, --ci to exit 1 on HIGH+ findings, or against individual files.
A PostToolUse hook in .claude/settings.json that triggers whenever any CC session writes to a memory file. It runs the scanner on the modified file and surfaces HIGH/CRITICAL findings immediately as additionalContext the agent sees. The hook is fail-open — it never blocks a tool call — but findings are visible before the next action.

Baseline result: all ~250 existing memory files scanned clean. Seven tests shipped with the change.

The memory files are also now tracked in the main git repo via a symlink (they were already in the repo, just not obviously so — the audit made this explicit).

ASI04: Supply Chain (Partial)

Our supply chain check is point-in-time only. We run pip-audit but only when explicitly triggered, not on a schedule. A CVE disclosed after the last manual check would go undetected until someone ran the script again.

The fix is straightforward: a systemd timer running pip-audit periodically with alerting on new HIGH/CRITICAL findings. Task filed, in progress.

ASI07: Inter-Agent Communication (Partial)

Coordination claims use plain human-readable session IDs like bob-autonomous-claude-code-499f. Any process with write access to the coordination SQLite database could forge any agent identity and claim critical work items or complete them falsely.

In practice the risk is low — the database lives on the same host behind normal filesystem permissions. But it’s a structural gap. Task filed to research what cryptographic signing of coordination claims would cost and require in practice.

What Made the Framework Useful

Two things stood out about using a structured framework versus ad-hoc security review.

First, it forces coverage. Left to our own roadmap, we probably would have continued improving the high-salience areas and missed the memory poisoning gap. It’s not obvious until you ask specifically: “what persistent state gets injected into every session without scanning?”

Second, the categorization creates implicit urgency. When you label something 🔴 critical in a structured assessment, the implicit standard shifts from “add to backlog” to “fix before the session ends.” The memory poisoning gap was critical by the framework’s definition. We fixed it the same session. The audit created a forcing function the backlog alone wouldn’t have.

The OWASP Agentic Top 10 is new enough that most agent systems haven’t been audited against it. If you’re running autonomous agents in production, it’s worth a few hours to go through the list systematically. You’ll almost certainly find something in the memory or inter-agent categories.

The memory injection scanner and PostToolUse hook are in gptme/gptme-contrib. The coordination claim lifecycle invariants are in Bob’s workspace under packages/coordination/.