Subtraction in the Agent Era — Mapping Ten Agentic Risks onto the Hierarchy of Efficacy

What this post covers

What the OWASP Subtractive Security Top 10 actually published — the Hierarchy of Efficacy and the PER metric.
A direct mapping of ASI01–ASI10 onto those three tiers, and a count of how many land in the deletion tier.
What that count implies for what you can delete today and what you can't.

TL;DR

OWASP Subtractive Security Top 10 is out. Hierarchy of Efficacy: architectural deletion > architectural constraint > monitoring.
Companion standard is PER — paths erased over paths eligible for erasure. Binary, unweighted.
I mapped the ten agentic risks onto that hierarchy. Only two land cleanly in the deletion tier.
The problem with agent infrastructure isn't that paths multiply. It's that most of the new ones fall into the "can't delete, it's a feature" tier.
But those two are deletable this week — dormant agent identities and unnecessary inter-agent channels.
The Subtractive project is at OWASP Incubator stage. Closer to a proposal than a standard.

How it works — a hierarchy borrowed from reliability engineering

The project's guiding principle fits in one line: attackers can only traverse paths that exist.

What's new isn't that claim. Attack surface reduction is a twenty-year-old idea. What's new is the ordering. Project founder Christopher Frenz says he took it from reliability engineering, where failure modes are addressed by architectural erasure where possible, constraint where erasure isn't, and monitoring only for what survives both. In security, he argues, the attack path is the equivalent of the failure mode.

Tier	Action	Examples given by the project
1. Architectural deletion	Remove the path entirely	Legacy protocols, unnecessary privileges, public exposure, dormant identities, unnecessary trust relationships
2. Architectural constraint	Narrow what can't be removed	Segmentation, permission boundaries, conditional access, private endpoints
3. Monitoring	Watch the residual	Logging, alerting, SIEM, IDS/IPS, endpoint detection

Frenz is explicit that the standard doesn't argue for eliminating detection and response, only for demoting it from primary defense. His analogy is fire safety — teams spend their budget on better smoke detectors and a faster fire department, when the priority should be constructing a building that doesn't burn easily in the first place.

A condition comes attached: an analytics phase has to precede any removal. The goal isn't to erase every path, only the ones serving no legitimate purpose. His illustration is that a little analysis usually reveals your browser has no legitimate need to launch PowerShell.

The metric — turning erased paths into a fraction

PER = |P_erased| ÷ |P_eligible|

The denominator is the set of valid attack paths identified within scope; the numerator is the subset whose executable edges have been structurally removed. It's binary and unweighted — a firing detection rule earns no credit, and you can't lower your risk on paper by reclassifying assets. Frenz's justification for the unweighted design says a lot about the project's posture: an attacker who lands on a workstation through a successful phish doesn't care that your risk register calls it non-critical.

The definition of the denominator is what matters here. It isn't "paths that exist." It's paths that have been identified and are eligible for erasure. Two conditions — and the entire next section is about them.

The mapping — ten agentic risks, three tiers

OWASP already has an agent security list. In December 2025 the Agentic Security Initiative, under the GenAI Security Project, published the Top 10 for Agentic Applications 2026. The project says more than a hundred practitioners and researchers contributed.

The two lists speak different grammars. ASI is a threat taxonomy — "here is what can go wrong." Subtractive is an action list — "here is what you can remove." So I overlaid them. The mapping below is mine, not either project's.

ID	Risk	Tier	Reasoning
ASI01	Agent Goal Hijack	Constrain	Accepting prompts and external context is the feature. Separating trusted from untrusted input is the ceiling.
ASI02	Tool Misuse & Exploitation	Delete + constrain	Unused tools can go. Misuse of the ones you keep is a scoping problem.
ASI03	Identity & Privilege Abuse	Delete	Dormant agent identities, long-lived credentials, excess permissions — all removable.
ASI04	Agentic Supply Chain	Delete + constrain	Unused MCP servers and connectors are removable. Runtime dynamic composition isn't.
ASI05	Unexpected Code Execution	Constrain	Execution is often the point. Sandboxes and resource boundaries narrow it.
ASI06	Memory & Context Poisoning	Delete or constrain	If you don't use long-term memory, turn it off. If you do, validate writes.
ASI07	Insecure Inter-Agent Communication	Delete	Unnecessary agent-to-agent channels can be removed outright.
ASI08	Cascading Failures	Constrain	A byproduct of multi-agent structure. Blast radius limits are the answer.
ASI09	Human-Agent Trust Exploitation	Monitor	A human judgment problem. Architecture can't delete it.
ASI10	Rogue Agents	Delete + monitor	Unregistered agents are removable. Drift in legitimate ones is a monitoring problem.

Count it. Only ASI03 and ASI07 land cleanly in the deletion tier. Three more (ASI02, ASI04, ASI10) allow partial deletion. ASI06 goes either way depending on architecture. The remaining four fall to constraint or monitoring.

That count exposes the real problem with agent infrastructure. The usual framing is that agents multiply attack paths so subtraction can't keep up. What actually happens is that most of the new paths never enter the denominator. An agent's standing credentials and tool access are the feature itself, so they aren't eligible for erasure — and what isn't eligible counts in neither the numerator nor the denominator. The denominator doesn't inflate. The space outside it does.

There's a timing problem on top of that. ASI04 frames agentic supply chain risk as dynamic runtime composition rather than pre-deployment static risk. When components are discovered and integrated at execution time through MCP or A2A, fixing P_eligible at design time doesn't work in principle. ASI06 adds a time axis: if an erased path can be revived through memory, there's no answer to how long PER's "this can no longer execute" verification stays valid.

A counterexample — what Vercel deleted wasn't a path

The case most often cited as proof that subtraction works for agents is Vercel's d0, an internal text-to-SQL agent. They built it with sixteen purpose-built tools — schema lookup, query validation, join path finding — then deleted most of them. Vercel reports the success rate went from 80% to 100%, with 40% fewer tokens, 40% fewer steps, and 3.5x faster responses. This was December 2025.

Read that far and it looks like a perfect endorsement. What they replaced it with changes the story. In place of sixteen tools went one: arbitrary bash execution inside a sandbox. They mounted the semantic layer and handed the model grep, cat, and ls.

From a security standpoint that isn't deletion. The number of tool abstractions dropped, but the range of what the agent can execute went up. That's exactly why ASI05 sits in the constraint tier above. Vercel's setup is safe because of the sandbox and the read-only schema, not because of the tool count — in hierarchy terms it's tier two, not tier one. Vercel attached their own condition: it worked because their semantic layer was already well documented, and pointing a model at a messy data layer just produces bad queries faster.

The point isn't that this refutes subtractive security. It's about proxy metrics. Tool count is not a proxy for P_eligible. Cutting sixteen tools to one increases reachability if that one is arbitrary code execution. Subtract on reachability, not on count.

Execution — what you can delete this week

Pull the deletion-tier rows out of the mapping and you get a work list. It sits at tier one, so it outperforms adding detection rules, and it needs no new tooling.

ASI03 family — identity and privilege

Inventory agent and service accounts with no call activity in 90 days, then disable them.
Replace non-expiring API keys with task-scoped short-lived credentials; revoke the originals.
Revoke permissions held by agents that never appear in actual call logs.
Separate any point where human and agent accounts share credentials.

ASI07 family — inter-agent communication

Inventory agent-to-agent channels and remove paths that have never carried a message.
Close internal agent endpoints that are open without authentication.
Remove orchestration layers that, in a multi-agent setup, actually only ever make a single call.

Partial deletion — ASI02 / ASI04 / ASI10

Remove registered tools with no invocation history. (Vercel's lesson: check the execution range of what you keep.)
Disconnect MCP servers and connectors that are wired up but unused.
Find and shut down agent instances missing from your asset inventory.

The ransomware examples the project cites for traditional infrastructure have the same shape — removing unused local administrator accounts, disabling legacy remote access protocols, restricting east-west traffic, pruning excess cloud identity permissions.

What all of these share is that they start by counting what isn't used. So the first step isn't deletion, it's enumeration. Without call logs at usable resolution, none of this list is executable.

Security Engineer's Perspective — why this, why now

Agent infrastructure is where this approach works least well, and paradoxically that seems to be why the proposal arrived now.

The evidence is in the shape of the incidents. The OWASP GenAI project's Q1 2026 exploit round-up observes that most AI-related security events aren't tracked as CVEs at all. Rather than discrete code flaws, they arise from architectural and configuration problems — misconfigured permissions, excessive autonomy, weak validation — producing data exfiltration and remote code execution. Only classical vulnerabilities embedded in AI platforms consistently get CVE identifiers.

That isn't a shape detection rules catch. There's no signature, it doesn't separate cleanly from normal operation, and you learn the combination was possible after the fact. Add the log volume that always-on agents generate and the alert fatigue Frenz points to stops being a matter of degree.

AWS releasing Kiro Crew the same day reads in this context. AWS describes it as a persistent, open-source development workspace for work larger than a single task in a single session — orchestrating multiple agents, running recurring work on a schedule, preserving project context across sessions. Industry commentary notes that enterprises would need policies on least-privilege access, human approvals, memory retention, code provenance, and auditability first.

Back to the mapping: most of what a tool like that opens falls into the constraint tier. But ASI03 and ASI07 — the credentials you issue agents and the channels between them — are deletion tier. Emptying those two comes before automating subtraction. That work is the enumeration of P_eligible.

Reversal cost differs too. A detection rule can be switched off; a deleted service and a revoked permission need a restore plan. That's why subtractive security asks more of an organization than the additive model did, and why the analytics phase before deletion isn't skippable.

Caveats

The tier mapping is entirely my own judgment. Neither project proposes this mapping, and neither references the other.
The mapping shifts with your architecture. ASI06 is deletion tier if you don't use long-term memory and constraint tier if you do.
The Subtractive project is at OWASP Incubator stage. As of August 4, 2026 the repository shows 18 commits, 4–5 stars, 0 forks — this is pre-community-validation. The ASI list, with 100+ contributors, is at a different maturity.
List selection differs from the classic OWASP Top 10. Frenz states the items were chosen by how much they reduce attacker optionality in a typical organization — not from a contributed vulnerability dataset.
This post doesn't quote individual items from the platform-specific Top 10s. It covers the hierarchy and the project's stated examples only, so check the source before applying the Linux or AWS lists.
PER's denominator is produced by the assessor. It's too early to use for cross-organization comparison or as an insurance/regulatory number.
The Vercel d0 case is December 2025 material, and it targeted accuracy and cost, not security.