Companion piece: Agentic apps are attack graphs — the design-time assessment side of the same boundary: modelling the attack paths a harness guardrail removes.
When a national signals-intelligence agency writes down where the security of a technology has to sit, that is worth reading closely — especially when it lands exactly where you have been building. The Australian Signals Directorate, through the Australian Cyber Security Centre, has published Agentic AI Harnesses — The layer above the model, a guide aimed at executives, CISOs and IT leaders. Its argument is simple and, for anyone shipping a control at that layer, striking: the model is not where you secure an agent. The harness is.
“Agentic AI Harnesses” is a government publication by the Australian Signals Directorate / Australian Cyber Security Centre, licensed CC BY 4.0 — which is why the quotes below are reproduced intact and attributed. ASD does not mention MoorAI, does not endorse it, and has no relationship with it. Everything connecting the two here is our own reading of their public guidance. The framework is entirely theirs; the honest self-assessment against it is ours.
What ASD actually says
ASD’s central image is the one in the subtitle. If you think of the LLM as the brain, then the harness is the body — the software around the model that supplies its context and memory, gives it access to tools and data, and enforces what it is and is not permitted to do. The model reasons; the harness acts, remembers, and constrains. And that division is not incidental — it is where ASD locates the entire security problem:
“the harness is where security controls must be applied, because the most significant weakness of agentic AI cannot be fixed in the model itself.” — ASD, p.5
The weakness ASD has in mind is prompt injection, and its treatment is unusually direct about why model-level fixes are the wrong place to look:
“Because the weakness is inherent to how LLM’s process context, mitigations must instead be applied in the harness, by controlling what an agent can access and what actions it is permitted to perform.” — ASD, p.6
The through-line of the document is that the controls that matter — the ones an organisation can actually own and tune — are enforced here. As ASD puts it, “Many of these controls are implemented in, or enforced by, the harness.” And its key takeaways for executives make the ownership explicit: “organisations control the harness, not the LLM”; “the harness is where long-term organisational value, governance and investment accumulate.”; and “the harness and its surrounding technical ecosystem are the primary focus for security and risk management”. There is even a good-practice line that reads almost as a warning label for the whole category: “Do not rely on model safety controls instead of harness-enforced controls.”
Two different jobs, one durable layer
ASD draws a clean line between what the LLM is and what the harness is. The harness column below is reproduced verbatim from the guide; the LLM column, and the full contrast, are in the PDF.
| Dimension | The harness — ASD, verbatim |
|---|---|
| Core job | “Decide what text goes in front of the model, and what to do with the output” |
| State | “Stateful — persists context, files, memory and progress” |
| Actions | “Executes tools, edits files, runs commands, calls APIs, browses” |
| Control | “Permissions, sandboxes, approval gates, hooks, policies” |
| Failure mode | “Wrong tool, lost memory, unsafe action, context overflow” |
| Changeability | “The durable architecture that outlives any single model.” |
Read the last row again. ASD’s point to executives is partly an investment argument: models are swapped, but the harness — and the controls, governance and audit built into it — is the thing that persists. Security spent on the layer above the model does not get thrown away with the next model release.
Where MoorAI sits against ASD’s harness
ASD breaks the harness into ten components it calls “the organisation’s configuration surface” — user interface, prompt and policy layer, context manager, model interface, tool registry, permission system, execution environment, connector layer (RAG and MCP-enabled tools), memory and session store, audit and observability, and the update / supply-chain path — and groups the risks into five categories: privilege, design and configuration, behavioural, structural and accountability. One line is worth pinning up: “For security purposes, a multi-agent system should be treated as a single agent.” The blast radius is the whole system, not the one agent that was compromised.
Mapped against that surface honestly — strong where MoorAI enforces at runtime, and clear about where everything else is owned.
| ASD requirement | How MoorAI addresses it |
|---|---|
| Privilege — least privilege on tools & actions | Decides the tool-boundary crossing by policy (coach / alert / block): excessive agency, tool misuse, entitlement drift, the lethal trifecta, human-approval gates. Measured: 12 of 12 malicious tool calls stopped at the action layer under an enforcing policy on Claude Code, after a jailbreak had already succeeded. |
| Behavioural — injection & poisoning | Direct, indirect and second-order prompt injection, obfuscated text, RAG and memory poisoning — named rules evaluated as data crosses the boundary, not by trusting the model to refuse. |
| Tool-parameter & output validation | Evaluates the resolved tool call and the model’s output — dangerous links, files or scripts, unsafe parameters — not the surface wording of the prompt. |
| Connector & supply chain | MCP config changes, tool poisoning, rogue-endpoint egress, typosquatting, and rules-file integrity (a poisoned CLAUDE.md or equivalent). |
MoorAI is an add-on to the harness, not the harness itself: it inspects and decides what crosses the boundaries at runtime. The rest is settled before the agent runs, enforced below it, or visible only across the whole system — owned elsewhere, and MoorAI should not claim it.
| ASD requirement | MoorAI’s part | Where it must be addressed |
|---|---|---|
| Accountability & audit | Content-free evidence — categories and keyed hashes, not verbatim prompts, responses or tool arguments (governance without surveillance). | The harness’s own logging, for full-fidelity forensics. MoorAI pairs with it; it is not a substitute. |
| Cost / denial-of-wallet | Detects runaway-input and cost signals. | The harness — a hard token budget or spend ceiling. MoorAI raises the flag, it does not cap the meter. |
| Sub-agent isolation & context focus | Watches for threats that move between agents. | The harness — it orchestrates sub-agents and manages context-window hygiene. |
| Design & configuration | — | Design-time review (ATAG-style attack-graph modelling) and the harness builder — settled before the agent runs. |
| Structural / cascade tracing | — | System-level observability — the whole-system view an add-on that sees one crossing at a time cannot build. |
| Execution environment / sandboxing | — | The OS, container or restricted token — a policy verdict is not a kernel boundary. |
| Model selection & provenance | — | Procurement, upstream of any runtime control. MoorAI governs what the agent does, not which model it was handed. |
MoorAI is a strong behavioural and privilege control on the harness, content-free by design at the cost of verbatim audit, and an add-on — explicitly not your design-time review, your sandbox, or your model-provenance story. Anyone who tells you a single runtime control covers all five of ASD’s risk categories is selling the decorated version of the claim.
ASD’s executive questions, answered honestly
The guide gives executives a set of governance questions to put to any agentic deployment. Here are four of them, with MoorAI’s concrete answer — including where the honest answer is “the harness must, and MoorAI helps by…”.
“What data, systems and tools can the agent access, and are least-privilege principles being applied?”
The harness’s permission system defines the entitlements; least-privilege is enforced there. MoorAI helps by detecting when a crossing exceeds least-privilege in practice — excessive agency, entitlement drift, and the lethal-trifecta combination of read-the-web, private-data and external-send powers — and acting on it at runtime.
“What actions can the agent perform, and which actions require human approval?”
This is MoorAI’s core. Actions are evaluated at the tool boundary and, by policy, coached, alerted on, or blocked — and human-approval gates are exactly the posture the “alert / block” policies express.
“How are prompt injection, data poisoning and other AI-specific attacks being mitigated?”
By shipped detection rules on the crossings: direct/indirect/second-order injection, obfuscated text, and RAG and memory poisoning — evaluated content-free as the data enters, rather than trusting the model to notice.
“Can all significant decisions, tool invocations and actions be monitored and audited?”
Partly, and by design. MoorAI produces a content-free audit stream — category, verdict, keyed hash — for every crossing it evaluates. For verbatim forensics the harness must record the full text; MoorAI helps by giving a privacy-preserving trail that does not itself expose the prompts.
There is a fifth question ASD poses that is really the whole document in one line: “If the harness were compromised, misconfigured or manipulated, what is the worst outcome and what controls would prevent or limit that outcome?” A runtime boundary control is one such limiting control — but only one, and only for the risks it actually covers.
Assessment names it; a graph maps it; a control enforces it
ASD is not the only independent line of work that lands on this layer. A team at Ben-Gurion University built ATAG, which models an agentic app as a formal attack graph — and in its own logic a prompt-injection attack is only reachable when the agent lacks a boundary guardrail. Put the three together and they converge without ever citing one another: ASD names the harness as the layer where controls belong, ATAG maps the attack paths that run across it, and MoorAI is a control that enforces at those crossings at runtime.
These are separate efforts arriving at the same place, not endorsements of each other or of any product. ASD’s guide is government guidance; ATAG is academic research; MoorAI is a shipping control. Neither ASD nor the ATAG authors mention or endorse MoorAI. The value is in the convergence: a signals agency, a university and a product independently agreeing on where the problem — and the fix — lives.
The distinction that keeps this honest is the same one that runs through the whole post: assessment tells you where a control should go, and enforcement is the control being there when the agent runs. ASD’s guide and ATAG’s graph both sit at design and analysis time. MoorAI sits in the request path. You want all of it — and you should not mistake any one of them for the others.
“Agentic AI Harnesses — The layer above the model” is a publication of the Australian Signals Directorate / Australian Cyber Security Centre, first published September 2026, licensed CC BY 4.0 — guidance page and PDF. Quotes are reproduced under that licence and attributed to ASD. MoorAI is content-free, open-core (AGPL-3.0) security for AI agents, enforced at the action layer on the developer’s endpoint; all MoorAI figures are our own measurements, self-reported. See also: rules-file security, the live MoorAI threat catalog, Prompt injection: content scanning won’t stop it, and Agentic apps are attack graphs.