Patch alone won't secure Copilot Studio from prompt injection risks.

The CVE assigned to Copilot Studio is a signal, not a solution. Microsoft did the right thing by patching ShareLeak and giving it a number, but treating this as a fixed vulnerability misses the structural reality that Capsule Security exposed. The patch closes one door while the architecture leaves a dozen others open. Prompt injection is not a bug that gets resolved in a Tuesday release. It is a class-level condition of how agentic systems process untrusted input alongside trusted instructions. If you are waiting for the next CVE to tell you when your agents are safe, you are already behind.

The practical takeaway is uncomfortable but direct: your agents are only as secure as the runtime that watches them. Capsule's research showed that Microsoft's own safety mechanisms flagged the malicious request, yet the data still left the building through a legitimate Outlook action. That is not a failure of patch hygiene. That is a failure of design. A DLP that does not fire because the email came from an authorized tool is not a DLP. It is a formality. The same pattern appears in Agentforce, where PipeLeak survived Salesforce's earlier ForcedLeak patch by routing exfiltration through email rather than URLs. Patching one channel and missing the other is not a vendor oversight. It is the predictable outcome of treating prompt injection as a discrete flaw instead of a runtime condition.

What this means for your 2026 planning is that you need to stop classifying agents by their CVEs and start classifying them by their exposure. The lethal trifecta is simple: private data, untrusted input, external communication. Most production agents hit all three because that combination is what makes them useful. If you cannot eliminate one leg of that triangle, you need runtime enforcement that observes what the agent actually does before it does it. Vendor hooks exist. Copilot Studio has security webhooks. Claude Code has pre-tool-use checkpoints. Use them. And if you are relying on human-in-the-loop as a control, ask yourself whether you are running an agent or a remote-controlled human. The answer will shape your budget.

The board does not need to understand the mechanics of a multi-turn crescendo attack. They need to understand that agents operate at machine speed with human-scale permissions, and that intent is now the perimeter. That is a business risk, not an IT risk. Audit every agent against the trifecta today. Restrict outbound communication to approved domains. Require stateful monitoring for any agent touching production data. And when a vendor tells you a patch solves it, ask them which of the three legs it eliminates. If the answer is none, the patch is just a starting point. The real work is runtime.