Agentic AI harnesses

ASD’s ACSC publication Agentic AI Harnesses — The layer above the model (11 September 2026) defines the harness as every component of an agentic system other than the large language model itself: connectors, tool registry, memory store, permission system, and the workflows that bind them. The model will be swapped. The harness is the long-lived control plane your organisation actually owns — or rents inside a vendor product.

Prompt injection sits in that frame as an inherent weakness, not a bug with a clean patch. Instructions and untrusted content share one context window. The model cannot reliably tell them apart. ASD’s wording is blunt: no fully reliable technical mitigation currently exists inside the model. The UK NCSC reached the same conclusion earlier: treat the model as a confusable deputy, and if residual risk is intolerable, do not put a language model on that use case.

Mitigations therefore live in the harness. Least privilege on tools and data. Human approval for high-impact actions. Verify outputs before they become operational. Log prompts, tool invocations, and configuration changes. Treat a multi-agent mesh as one agent for blast-radius purposes — compromise travels through shared context and trust. Delete stale agent context rather than summarising it (summaries rewrite the record). Keep a persistent rules file the harness loads at the start of every session. Model vendor safety filters are not a substitute for harness-enforced controls.

Board question ASD wants answered: what is the worst outcome if the harness is compromised, misconfigured, or manipulated, and which controls contain it? For commercial agent products where you cannot inspect the vendor’s harness, that question still stands — demand the allowed-tool list, egress policy, logging, and who can change them. Pair this entry with Essential Eight / ISM least privilege and logging, and with the desk card on the ACSC harness guidance.