The Sentence That Removes the Waiting Option
In August we argued that most organisations deployed Copilot without ever making the risk appetite decision that should have preceded it, and that the sensible read of a prompt injection worm surviving months of Microsoft’s mitigation attempts was to stop treating it as a research novelty and scope the agent’s access accordingly.
On 11 September the Australian Signals Directorate published Agentic AI Harnesses: the layer above the model, and it contains a sentence that changes what that decision has to cover.
Prompt injection, ASD says, is a weakness “for which no fully reliable technical mitigation currently exists”. Not unmitigated yet. Not pending a vendor fix. The reason is architectural: instructions and information arrive in the same context window, so a model “may have difficulty distinguishing authorised instructions from information contained within external content”. The UK’s National Cyber Security Centre reached the same conclusion, in a paper ASD links as further reading under the title Prompt injection is not SQL injection (it may be worse). SQL injection was solved by separating code from data. Nobody has worked out how to do that here, and the guidance does not suggest anyone is close.
That is the part boards need to absorb. The residual risk on this vulnerability class is not temporary. It does not close on a patch cycle. Whatever exposure your organisation is carrying from an AI assistant plugged into its document estate, it is carrying indefinitely, and a risk appetite statement that implicitly assumes a fix is coming is now documented as wrong by the national authority.
What ASD Actually Recommends
The guidance’s substantive move is to relocate the control surface. If the weakness cannot be fixed in the model, the controls go around it — in what ASD calls the harness: everything in an agentic system other than the model itself. The connector layer, the context manager, the tool registry, the permission system, the execution environment, the memory and session store, the audit and observability layer, the update and supply chain path.
ASD’s framing is that this layer is “the component organisations can most directly govern, secure and control”, and that the eleven components it lists “are the organisation’s configuration surface”. Which tools are exposed, what is permitted, which approvals are required, which connectors are attached. The recommendations follow from that: least privilege, human approval for high-impact actions, verification of outputs before operational use, logging of prompts, tool invocations, approvals and configuration changes, and a direct instruction not to rely on the model’s own safety controls in place of controls the harness enforces.
There are two details in there worth pulling out, because neither is being discussed and both are cheap.
Treat a multi-agent system as a single agent for security purposes, because a compromise in one component propagates through shared context and trust relationships. Any assurance that rests on one agent being more constrained than another needs to survive that assumption.
And when context has to be reduced, delete stale content rather than summarising it — summarisation rewrites the record and risks introducing new errors. That is a quietly significant point for anyone relying on an agent’s session history as evidence of what happened.
The Problem With the Advice Is Who It Is Addressed To
The guidance is written, in ASD’s own words, for organisations “adopting or considering agentic AI”, and it assumes a meaningful degree of choice about how the system is assembled. It acknowledges the alternative in a single line: in some cases the harness is developed by the organisation, in others it is supplied as part of a commercial product.
For the majority of Australian enterprises, it is the second. The agentic AI in production is Microsoft Copilot, and the configuration surface ASD is pointing at is substantially not yours.
Run the component list against what a Microsoft 365 tenant administrator actually holds. The permission system is inherited from existing SharePoint and OneDrive access, which means your control over it is your sharing hygiene — not a permission model designed for an agent. Audit and observability exist, through Purview, at the granularity the vendor chose to expose. The connector layer is configurable in part. The context manager, the prompt and policy layer, the tool registry, the execution environment, the memory store and the update path are the vendor’s. You are not securing those; you are trusting them.
So the honest position for a bought agent is that ASD’s central recommendation is only partly available to you. The levers you fully own reduce to two: what the agent can reach, and which of its actions require a human before they take effect. That is a narrower set of controls than the guidance contemplates, applied against a vulnerability the guidance says cannot be eliminated.
Which is precisely why the decision we wrote about in August matters more now, not less. When the technical controls are mostly someone else’s, scope is the control. Deciding what sits inside the agent’s reach becomes the primary risk treatment rather than a supporting one.
The Vendor Question Changes Shape
In August we said Microsoft’s accountability here is not zero. That still holds, but the useful question has moved.
Asking a vendor when prompt injection will be fixed is now a question with a published answer, and it is no. The question that produces something is a procurement question: which harness components can we configure, which can we monitor, which can we evidence to an auditor, and what happens in each of those when the underlying model is replaced. A vendor that cannot describe its permission model, its memory retention behaviour and its logging granularity in terms an assurance function can test is selling you a harness you cannot govern, and ASD has just published the vocabulary for saying so in a contract negotiation.
Advisory Guidance Is Still the Standard of Care
None of this is binding. ASD guidance is advisory, and there is no instrument making the harness publication a compliance obligation.
That is not the same as it being optional. The document is explicitly addressed to “executive decision-makers, chief information security officers and IT leaders”, and it closes with seven governance questions for directors. Among them: what data, systems and tools can the agent access; which actions require human approval; how are prompt injection and other AI-specific attacks being mitigated; can all significant decisions and tool invocations be monitored and audited; and if the harness were compromised or misconfigured, what is the worst outcome and what controls would limit it.
Once a national signals authority publishes the questions directors should be asking, an entity under CPS 234 or the SOCI Act that has not asked them is in a materially weaker position than it was on 10 September. The same logic reaches the reasonable-steps duty in the Privacy Act reform package: what constitutes reasonable is set by what competent organisations do, and competent organisations read the guidance their national authority writes for them.
Seven questions, addressed to the people who approved the deployment. “The vendor handles it” is now, on the record, not one of the available answers.
The August point stands unchanged. A default is still a decision.