Where_This_Started

My copy lead has no Bash grant. It isn't in her permission set, it isn't a preference she can override mid-session, and it isn't documented anywhere as a security control - it's just how her scope was written, because a copywriter doesn't need shell access to do the work she does. I didn't think of that as a control until I read OWASP's Top 10 for Agentic Applications and recognised ASI03 - Identity and Privilege Abuse - as the name for a thing I'd already built.

OWASP published its Top 10 for Agentic Applications in December 2025 - a peer-reviewed taxonomy built with more than 100 security experts, not a quick vendor whitepaper. What's new isn't the framework; it's the gap Tom's research confirmed while I was scoping this piece: every existing treatment of the ten categories assumes an enterprise SOC - a team, a monitoring budget, headcount to run each control as its own workstream. Nobody has translated ASI01 through ASI10 for the operator running a fleet alone. That's the gap this piece fills.

ASI01_-_Agent_Goal_Hijack

At solo scale this isn't a nation-state prompt-injection scenario - it's a task that drifted from what was actually authorised, because nothing was written down to check it against. A brief-less instruction is a hijack surface by default; there's no reference for "was this the goal" to fail against. The check I run is the spec-before-code gate: any change touching more than two files needs a written brief before an agent starts, and that brief is what the eventual output gets checked against. If an agent's work doesn't trace back to a brief, the finding isn't "was this hijacked" - it's that there was nothing here to hijack in the first place.

ASI02_-_Tool_Misuse_and_Exploitation

Every agent in my fleet has a declared tool scope: which ones get Bash, which get write access to which paths, which are read-only by design. My copy lead's missing Bash grant is one instance of this. The check is EXP_012, the Agent Permission Linter - it scores a pasted prompt or agent definition for privilege-escalation and scope flags, surfacing where a tool grant exceeds what the stated role actually requires. A grant that's broader than the job is the finding, whether or not it's ever been used to cause harm.

ASI03_-_Identity_and_Privilege_Abuse

The enterprise version is stolen session tokens and delegation chains. The solo-scale equivalent is an agent silently inheriting more authority than its own definition specifies - which is exactly what the model tiering inheritance bug was. Every subagent in my fleet ran on Opus, the most capable and most expensive tier, for several weeks, because a spawn-time parameter wasn't being passed and each subagent quietly assumed the parent session's identity instead of the one written in its own definition. Telemetry Before the Failure has the full mechanics; I'm not repeating them here. The check this produced: verify at spawn time that the tier and scope an agent is running under match its own definition, not whatever it inherited from the session that called it.

ASI04_-_Agentic_Supply_Chain_Vulnerabilities

The agentic supply chain isn't just npm packages - it's every MCP server, tool, and skill an agent can reach. My fleet's rule is that manually-added MCP servers register across a small, tracked set of configuration locations - global, user-level, or a documented project exception - not an ad hoc file nobody's tracking, and none get added without explicit approval first. The check is an inventory audit: list every MCP server and tool an agent can currently call, and confirm each one was deliberately approved rather than accumulated. Ordinary dependency scanning - Dependabot, npm audit - still applies underneath this; ASI04 is the layer above it, for the things that entered the system because an agent reached for them, not because a build step declared them.

ASI05_-_Unexpected_Code_Execution

This is the failure mode where agent-run code does something the brief didn't intend, and nothing throws an error to say so. I have a documented incident in exactly this category - a rebrand script that used the wrong method against a content database and silently wiped image references across eight documents while reporting success - and the incident and its mechanics are in Telemetry Before the Failure, not reproduced here. What the incident produced as standing policy: any agent-executed script that mutates production data runs against a dry run or a diff first, reviewed by a person, before the mutating version runs for real.

ASI06_-_Memory_and_Context_Poisoning

A fleet's context isn't just the prompt in front of it - it's every file an agent reads before acting: rule cascades, memory indexes, prior decisions. If one of those files is wrong, every agent that reads it inherits the error silently, because the file looks authoritative regardless of whether it still is. The check is memory hygiene as a standing discipline rather than a one-off cleanup: memory files carry a last-verified date, get re-checked once that date ages past a threshold, and stale or superseded entries move to an archive instead of lingering, tagged "resolved," inside the active index a future agent might still read. A memory file is either current and trusted or it's out of the fleet's context entirely - there's no middle state where an agent could read it without knowing which.

ASI07_-_Insecure_Inter-Agent_Communication

At solo scale this isn't encryption-in-transit between microservices - it's whether one agent's output can silently become another agent's authority. My fleet's rule is that no message from one agent counts as another agent's permission or approval: a subagent recommending a change, however confidently it's phrased, doesn't get to apply that change to shared infrastructure directly. Anything touching a shared system - a content database, a production file - comes back as a proposed change for a supervising step to apply, not something executed inline by the agent that suggested it. The check: pick any agent-to-agent handoff and ask whether the receiving step can act on the message's content without a separate authorisation step. If it can, that's the finding.

ASI08_-_Cascading_Failures

A fault in one agent's output becomes a fault in three more precisely when the coupling between them was never written down anywhere an agent could check it before acting. I've had this happen at repo scale - a change scoped correctly to one module produced a failure in a module the brief never mentioned, because nobody had documented that the two were coupled. Telemetry Before the Failure walks through it in full; this is the pointer, not the retelling. The solo-scale check is a dependency map kept current: which repos and modules depend on which others, consulted before a brief is approved, not discovered after the PR ships.

ASI09_-_Human-Agent_Trust_Exploitation

The enterprise framing is a bad actor persuading a human via a chatbot. The solo-operator version is quieter: an agent's output can read as confident and complete without being either, and a confident wrong answer is exactly the kind of thing that gets waved through by someone who's already reviewed forty correct outputs that day. My publish gate for Labs articles has a rule against precisely this: a "hold" or "minor fix" verdict from a reviewing agent can only be overridden by an explicit instruction, given in the current session, from me - inferred consent doesn't count, and an agent's own confidence in its output is never sufficient authorisation to skip the override step. The check is procedural, not technical: does the review process require a stated decision, or does silence count as approval?

ASI10_-_Rogue_Agents

This is the category I've already given a full article to, and I'd rather point there than compress it into one paragraph here - the audit checklist is in The Haunted House Audit. The short version: an agent that's unowned, uninvoked, and undocumented for retirement isn't malicious, it's just still running, on credentials nobody's checked in months, in a scope nobody's reviewing. At solo scale, rogue rarely means adversarial. It usually means forgotten.

What_Solo_Scale_Actually_Changes

None of the ten categories needed rewriting for a one-person fleet - only the shape of the check changed. Where an enterprise SOC runs continuous automated monitoring, or assigns a dedicated reviewer, I run a documented manual protocol and one enforced rule, both applied by the same person every time: the ASI03 spawn-time check is specified but not yet built, so it happens because I ran it; the ASI09 rule is that inferred consent doesn't count. Proportionally smaller controls are still controls - the alternative is none at all.

That's the value of the taxonomy now: what used to be lessons filed under incident nicknames - "the tiering bug," "the fabricated-anecdote thing," "the roster gap" - share a name, so the next incident in any of these ten shapes is one I can recognise before it produces its own postmortem.

What_This_Doesn't_Solve

I want to be precise about this piece's limit - a checklist can read as more solved than it is. Every check above is something I run, not something the system enforces automatically. The gap between a documented policy and a runtime enforcement layer is real; The Control Plane Problem covers it in depth, and I won't reopen it here. Translating OWASP's categories to solo scale tells you what to check and how often - it doesn't make the check run itself. For most of these ten, at my scale, it still runs because I ran it.