Prompt Injection Is a Property, Not a Bug: OWASP, Semantic Kernel RCE, and the Framework Supply Chain

If your organization is regulated, a behavioral health provider, a property manager holding tenant financial data, a PE portfolio company, a SaaS vendor under HIPAA, GLBA, or a state privacy statute, you have spent a decade building a control model around a simple idea: vulnerabilities are bugs, bugs get patched, and a current patch level is evidence of diligence. That model is about to fail you in a specific and expensive way. On June 11, 2026, OWASP published its agentic-AI Top 10 and mapped prompt injection to 6 of the 10 categories. Injection was not slotted in as risk number one. It was identified as the mechanism underneath most of the others, memory poisoning, tool misuse, privilege compromise, cascading failures. You cannot patch your way out of a property that pervasive. You have to design around it. That distinction, bug versus property, is the entire briefing. A bug is a defect you can remove. A property is a behavior that emerges from how the system is built and persists until the architecture changes. Prompt injection is the second kind. Any system that lets a language model read untrusted text and then take an action will, under the right input, take an attacker's action. There is no patch that closes that, because it is not a hole. It is how the technology works. What OWASP actually said, and why the number matters The headline is the 6-of-10 mapping, and the count is the point. When a single failure mode threads through more than half of a framework's risk taxonomy, it stops being an item on a checklist and becomes a design constraint. OWASP's categories are not independent boxes you can close one at a time; injection is the path that connects an attacker's input to memory poisoning, to tool misuse, to excessive agency, to the privilege escalation that follows. Treat the categories as ten separate tickets and you will close ten tickets while the underlying property remains live. This is also why "we tested for prompt injection and our model resisted it" is not a control. Resistance is statistical. The model that refuses the jailbreak in your June test will comply with a reworded variant in August, and there is no version number that makes the refusal permanent. GitGuardian's 2025 figures sharpen the stakes: 1,275,105 AI-related secrets found exposed on public GitHub, up 81% year over year. The credentials your agents carry are already leaking through ordinary channels. An injection that turns an agent against its own tools does not need to steal a secret, it just needs the agent to use the one it already holds. When injection becomes code execution The reason this graduated from a research curiosity to a board-level issue is that the injection no longer stops at the model. It reaches the host. On May 7, 2026, Microsoft disclosed two remote code execution vulnerabilities in Semantic Kernel, CVE-2026-26030 and CVE-2026-25592. Semantic Kernel is orchestration middleware, the layer that turns a model's text output into function calls. An RCE there means a crafted input, delivered through the model, can run code on the machine running the agent. The chain is: untrusted text, to model, to orchestration layer, to your infrastructure. Injection is the first link, not the whole attack. The framework supply chain makes it worse, because the compromise can arrive before any user types anything. On March 1, 2026, a poisoned LiteLLM package on PyPI seeded a backdoor that propagated into CrewAI, DSPy, and GraphRAG, three widely used agent and retrieval frameworks, through ordinary dependency resolution. On February 15, the ClawHavoc campaign planted malicious skills on the OpenClaw marketplace, weaponizing the same plugin-trust model that makes agent platforms useful. And tool-poisoning attacks now hide instructions inside tool metadata itself, so an agent reading a tool's description is reading attacker-controlled text before it processes a single user prompt. Put these together and the threat model inverts. You are no longer defending one model from one malicious user. You are defending a dependency graph, frameworks, plugins, tool definitions, MCP servers, in which any node can carry an instruction your agent will obey. For scale, recall the loosely reported incident in which an AI coding agent deleted a startup's production database and its volume-level backups in roughly nine seconds. The agent did not need an exploit. It had the permissions, and something told it to. What the audit and the regulator will ask The regulatory ground is already moving toward this framing. The US Treasury's Financial Services AI RMF, published February 19, 2026, lays out 230 control objectives across seven domains, a level of specificity that presumes you can describe what your AI systems are allowed to do, not just that you scanned them. The EU AI Act's "Digital Omnibus" deferred the high-risk Annex III obligations to December 2027, but GPAI enforcement powers still switch on August 2, 2026, with fines up to 3% of global turnover, and downstream deployers must be collecting provider documentation now. Texas TRAIGA has been in force since January 1, with a NIST AI RMF safe harbor that rewards demonstrable control mappings. NIST's preliminary Cyber AI Profile, IR 8596, published December 16, 2025, gives examiners a vocabulary for exactly this. So the question in the room will not be "is the framework patched." It will be: show me that when injection succeeds, it cannot do much. What can this agent's tools actually reach? Where can data leave? What version of each framework is running, and how do you know it is the one you reviewed? Where did this output come from? A current patch level answers none of those. The containment artifact Assume injection succeeds, then bound the damage. For every deployed agent, maintain a single row with these columns: Agent and owner, the named human accountable for it. Tool scopes, every tool the agent can call, each scoped to least privilege. No standing write or delete that an objective does not require. Egress and DLP path, where data can leave, through what allowlisted channel, with inspection. If the agent can reach the open internet, you have no containment. Credentials and identity, what the agent authenticates as, and the blast radius if that identity is hijacked. The Cloud Security Alliance's May 20 governance work pegs non-human identities at roughly 45:1 over humans, and up to 144:1 in some estimates; your agents are the larger attack surface now. Framework versions and SBOM, pinned versions for the orchestration layer, plugins, and MCP tools, with a software bill of materials. Pinning is what would have blunted the LiteLLM backdoor; floating aliases, the way GPT-5.5 Instant ships as a "chat-latest" pointer, are the opposite of evidence. Content provenance, how you know whether an input or tool description is trusted or attacker-controlled. This is the same posture our "Trust Architecture for Regulated AI" field guide develops, and it is the structure we build with regulated mid-market clients in a fixed-scope Diagnostic. What we recommend Four moves, in order. First, inventory every agent and fill in the containment row above; the row you cannot complete is your highest risk. Second, cut tool scopes to least privilege and put a DLP-inspected egress chokepoint in front of anything that touches data, assume the model will be turned against you and make that turn cheap. Third, pin and inventory your AI frameworks: version-lock orchestration, plugins, and MCP tools, generate an SBOM, and ban floating model aliases in regulated workflows. Fourth, map your controls to the Treasury RMF and NIST IR 8596 now, so the August 2 GPAI deadline is paperwork rather than panic. Stop asking whether your agents can be injected. Assume they can, and prove the blast radius is small.