Security By Thyago Coan July 29, 2026 · 8 min read

SPHR Enterprise Agentic Multi-Purpose Harnesses — The OWASP Agentic Top 10, Controlled — Part 4

Part 4 of 5 · SPHR Enterprise Agentic Multi-Purpose Harnesses

Diagram mapping the OWASP Agentic Top 10 (ASI01–ASI10) to concrete controls in an SPHR harness — injection and information-flow defense, tool and model supply-chain vetting, inter-agent integrity, cascade and loop budgets, and per-tenant crypto isolation.

The OWASP Top 10 for Agentic Applications (2026 edition, ASI01–ASI10) is the community threat model for autonomous, tool-using agents. It is an excellent list — and a list of risks is not a set of controls. This is Part 4 of our series on the SPHR Enterprise Agentic Multi-Purpose Harnesses, and it does one thing: shows how a governed platform answers each risk with a concrete control. Earlier parts built the pieces we lean on here — the control plane you own, agent identity and zero trust, and governance at runtime. For the risk-by-risk reference with one control per row, this pairs with our companion OWASP Agentic Top 10 checklist; here we group the ten into the control clusters a platform actually implements.

Injection and memory-poisoning defense (ASI01, ASI06)

Goal hijack (ASI01) and memory & context poisoning (ASI06) share a root cause: untrusted content steering the agent. The control is to treat every untrusted channel as hostile — not just the obvious user prompt, but ingested documents, tool outputs, external context signals, and memory itself — and to apply information-flow controls across all of them. The AI gateway blocks PII and PHI at the inbound boundary, so sensitive data never reaches the knowledge base or conversation memory in the first place. For poisoning specifically, memory writes are validated and provenance-tagged and reads are auditable and reversible, so a false "fact" can be traced to its source and rolled back rather than quietly shaping decisions for weeks.

Supply-chain vetting: tools, MCP, and models (ASI04, ASI05)

Agentic supply-chain risk (ASI04) and unexpected code execution (ASI05) are answered before an agent ever calls anything. Tools, MCP servers, and models are vetted at registration and on a schedule: signed and version-pinned packages, a deny-by-default allow-list, scoped access, sandboxed execution with no ambient network or filesystem reach, continuous scanning, and SBOM or model-card provenance recorded in the registries. A "read-only" connector is treated as an untrusted injection source, not a trusted input. Because re-verification is wired into the promotion pipeline rather than done once at registration, a dependency that goes bad after it was approved is caught on the next pass instead of living in production indefinitely.

Identity, privilege, and inter-agent integrity (ASI03, ASI07)

Agent identity and privilege abuse (ASI03) is answered by the identity model from Part 2: a scoped, attested per-agent identity and per-action authorization on the intersection of user and agent rights, so no action runs with more privilege than both the agent and the human behind it hold. Insecure inter-agent communication (ASI07) is answered by carrying that verifiable identity on every agent-to-agent message and delegation: messages are authenticated, scope travels with each hop, and out-of-scope or unsigned messages are rejected. The chain of who-authorized-whom stays intact instead of dissolving into anonymous internal calls — which is also what makes the audit trail from Part 3 reconstructible.

Cascading failure, loops, and rogue agents (ASI08, ASI10)

Cascading failures (ASI08) and rogue agents (ASI10) are contained by the same action layer that enforces policy. Circuit breakers, blast-radius and loop budgets, and per-task operation caps stop a runaway or looping agent before its failure fans out across a chain of dependents, and a kill switch suspends an agent that breaches a threshold. Every agent is inventoried with its mandate and continuously monitored, so an agent operating outside its intended scope — a shadow agent, a compromised one, or one whose behavior has drifted — is detected and contained rather than discovered after the fact. These are controls a governed platform applies by design, not hopes it will not need.

Human-agent trust and safe code execution (ASI09, ASI05)

Human-agent trust exploitation (ASI09) — fluent, confident output used to push a person into approving something they should not — is answered by making approvals meaningful. The human-in-the-loop gate surfaces the evidence behind a recommended action and requires genuine (not rubber-stamp) approval for consequential steps, recording who approved what. And where an agent generates and runs code, execution is sandboxed with resource caps and deny-by-default egress, so unexpected code (ASI05) cannot reach beyond its box. Read the controls, not the row numbers: nearly all of ASI01–ASI10 reduce to the same handful of primitives applied at different points.

The control map, in one view

A governed platform does not fight the OWASP list with ten disconnected fixes; it applies a small set of primitives across all of it:

  • ASI01 Goal hijack / ASI06 Memory poisoning → information-flow control on every untrusted channel; provenance-tagged, reversible memory; PII/PHI blocked at the gateway.
  • ASI02 Tool misuse / ASI05 Code execution → deny-by-default tool allow-list, validated arguments, sandboxed execution with no ambient egress.
  • ASI03 Identity & privilege → scoped, attested per-agent identity; per-action authorization on user ∩ agent rights.
  • ASI04 Supply chain → signed, version-pinned, continuously scanned tools/MCP/models with SBOM and model-card provenance.
  • ASI07 Inter-agent comms → authenticated messages, scope carried on each hop, unsigned/out-of-scope rejected.
  • ASI08 Cascading / ASI10 Rogue → circuit breakers, loop and blast-radius budgets, agent inventory + monitoring, kill switch.
  • ASI09 Human-agent trust → evidence-backed, meaningful human approval for consequential actions.

This is why we treat the OWASP list as an architecture question, not a checklist to tick once. The risks come from what agents do — reason, call tools, hold memory, act with an identity, delegate — so the controls have to live where those actions happen: outside the agent and enforced deterministically. That also future-proofs them, because a new ASI entry, or the companion OWASP Agentic Skills work, tends to land on the same primitives rather than demanding a fresh point product. And because every decision is recorded as a byproduct of enforcement, answering an auditor's "show me" for any of the ten is a query, not a scramble. Controls applied once, at the right layer, pay down risk across the whole list at the same time.

Continue the series

This is Part 4 of a five-part series on the SPHR Enterprise Agentic Multi-Purpose Harnesses:

The category these controls assemble into is covered in the enterprise agent control plane.

How SPHR helps

SPHR builds production agentic AI for enterprises across the USA, Brazil, Australia, and Japan. We assemble harnesses that answer the OWASP Agentic Top 10 with real controls at the action layer — information-flow defense, supply-chain vetting for tools and models, authenticated inter-agent messaging, cascade and loop budgets, and per-tenant cryptographic isolation — not with prompt instructions and hope. As an Anthropic partner working model-agnostic and multi-cloud, we make those controls constant while the engine stays swappable. If you want a straight read on where your agents sit against ASI01–ASI10, let's map your controls.

Frequently asked questions

Does the OWASP Agentic Top 10 have a 2026 version?

Yes. The OWASP Top 10 for Agentic Applications 2026 is the current edition, using the identifiers ASI01 through ASI10, published by the OWASP GenAI Security Project. It is distinct from the older Top 10 for LLM Applications and adds the risks that only exist once a model can take actions — tool misuse, identity and privilege abuse, memory poisoning, insecure inter-agent communication, cascading failures, and rogue agents. A governed platform answers each with a concrete control rather than a prompt.

How do you defend AI agents against prompt injection and memory poisoning?

Treat every untrusted channel as hostile: ingested documents, tool outputs, external context signals, and memory are all information-flow-controlled, not just the obvious user prompt. The AI gateway blocks PII and PHI at the inbound boundary so sensitive data never reaches knowledge or memory. Memory writes are validated and provenance-tagged, and reads are auditable and reversible, so a poisoned fact can be traced and rolled back rather than silently shaping future decisions.

How do you secure the AI agent tool and model supply chain?

Tools, MCP servers, and models are vetted before they can run: signed and version-pinned packages, a deny-by-default allow-list, scoped access, sandboxed execution, continuous scanning, and SBOM or model-card provenance recorded in the registries. Read-only connectors are treated as untrusted injection sources, not trusted inputs. Re-verification is wired into the promotion pipeline, so vetting is continuous rather than a one-time check at registration.

How do you stop one agent's failure from cascading?

The same action layer that enforces policy also enforces limits: circuit breakers, blast-radius and loop budgets, and per-task operation caps stop a runaway or looping agent before it fans out, and a kill switch suspends an agent that breaches a threshold. Every agent is inventoried with its mandate and continuously monitored, so a rogue or drifting agent is detected and contained rather than discovered after the damage.

Can a governed platform really address all ten OWASP Agentic risks?

Yes, because nearly all ten reduce to a small set of primitives applied at the action layer: scoped per-agent identity, deny-by-default policy before each action, sandboxing, information-flow control on untrusted channels, per-tenant cryptographic isolation, and cost and blast-radius limits. A single governed control plane applies those primitives across ASI01 to ASI10, which is why ten point fixes is the wrong shape and one enforcement layer is the right one.

The risk list is the OWASP GenAI Security Project's OWASP Top 10 for Agentic Applications (2026); the deterministic-enforcement pattern draws on Microsoft's Agent Governance Toolkit. This series describes pattern-level controls; implementation details are generalized.