The Risk Conversation You Skipped When You Deployed Copilot
Most organisations that rolled out Microsoft Copilot in the last eighteen months framed it as a productivity decision: faster drafting, better meeting summaries, quicker synthesis of what the organisation already knows. The conversation that did not happen, or happened briefly between the wrong people, was about what risk posture was being accepted in exchange.
A researcher’s self-propagating prompt injection worm targeting Copilot for Word has now survived months of mitigation attempts. The mechanism is simple enough to explain in a sentence: a malicious prompt sitting inside a document tells the AI to take actions and to copy itself into other documents. The assistant bolted onto your sensitive corporate content can be turned around and driven through that same content, and Microsoft’s own engineers have not closed it.
Copilot Was Treated as a Software Upgrade
The decision to enable it almost certainly went through procurement and IT, where the questions were about licensing, integration, deployment timelines and user training. Reasonable questions for a software upgrade, and the wrong set entirely for what was being switched on.
Copilot is an autonomous agent inside your information environment. It reads documents, drafts responses, acts on behalf of users and increasingly reaches across everything Microsoft 365 holds. That is a new attack surface carrying its own threat model, inheriting every document the organisation stores and every permission its users hold.
Nobody formally made the risk appetite decision that should have preceded it — how much exposure, in which parts of the business, under what controls. The productivity mandate simply routed around it.
What Prompt Injection Actually Means at the Organisational Level
Prompt injection is the technique of embedding instructions inside content that an AI system will process, causing the AI to act on those instructions rather than serve the user’s intent. In the context of Copilot for Word, a document can contain hidden or disguised instructions that redirect what the AI does when it encounters that document.
The worm variant described in the research adds a propagation layer: the AI is instructed to embed the same malicious prompt into other documents it generates or edits. The attack spreads through the document corpus.
For an executive audience the consequence is this: the assistant’s attack surface is the entire document library. Anything arriving from outside — a vendor proposal, a contract sent for review, an attachment forwarded by a colleague — is a potential delivery mechanism, because the AI processes it on behalf of a trusted user and inherits that user’s access while doing so. The old instinct that an untrusted file is contained as long as nobody runs it does not survive a system that reads every file and acts on what it reads.
The Governance Failure Underneath the Technical One
What makes this worth a board’s attention is less the vulnerability than what it exposes about how AI adoption decisions get made.
In most organisations the CISO was either absent when Copilot was approved or present and not heard. Productivity mandates, especially ones arriving from a CEO fresh out of a vendor briefing, compress security review into a formality. Concerns are logged, a caveat appears in the implementation plan, the rollout proceeds on the original date.
Whether to deploy an autonomous agent across your most sensitive documents is not a question IT can settle by itself. It needs the people who understand the exposure in a room with the people who own the business outcome, and it needs to happen before deployment rather than during the first incident review.
Australian organisations sitting under APRA CPS 234, the SOCI Act, or with significant Privacy Act obligations face an additional dimension here. Information security capability requirements and the expectation of formal risk assessment before adopting technologies that materially alter the threat environment are not suggestions. Deploying Copilot across a regulated entity without a documented risk assessment and explicit sign-off from the accountable executive is a compliance gap waiting to be discovered — and under a strengthened Privacy Act, the consequences of an AI-mediated data exfiltration event are materially higher than they were three years ago.
Microsoft’s Accountability Here Is Not Zero
It is worth being direct about vendor accountability. A self-propagating prompt injection attack that survives months of mitigation attempts is not an acceptable outcome from an enterprise software vendor of Microsoft’s scale and resources. The architectural decision to allow AI systems to execute actions based on content they process — without robust sandboxing between content interpretation and action execution — is a design choice. It was made in favour of capability and against caution.
Organisations should not accept the implicit framing that this is a research novelty they need to wait out. It is a known vulnerability class in a widely deployed enterprise product, and the vendor’s mitigation timeline is measured in months, not days. That has implications for how much access Copilot should currently hold inside sensitive document repositories, and that decision belongs to the organisation, not to Microsoft.
What to Do Differently
If Copilot is deployed and the risk conversation never happened, have it now, and not as a briefing from IT. It needs the CISO, the CEO and the executives who own the most sensitive information assets in the same room.
None of the questions are technical. Which document environments is it operating in, and what follows if one of them is compromised? Has its access been scoped to the sensitivity of what it can reach? Who made that scoping decision, and against what criteria?
Unclear answers mean the risk appetite decision was defaulted rather than made. A default is still a decision. It just means somebody else made it, and you will find out who during the incident.