What You Govern Is the Harness, Not the Model

Your AI policy probably names a model. Your risk assessment probably scores a model. Your supplier evaluation probably compared two models.

None of those is the thing that will hurt you.

On 11 September 2026 the Australian Signals Directorate published Agentic AI harnesses: the layer above the model. It introduces a distinction that is going to reshape how AI governance is written, and it is worth understanding before your next audit. Everything attributed to ASD below is from that publication, and it is short enough to read in full.

What a harness is

An agentic AI system is not just a model. It is a model plus the software that connects it to the real world: the tools it can call, the data it can read, the memory it keeps between sessions, the permissions that decide what it may do, and the loop that keeps it going until the task is finished.

ASD calls everything other than the model itself the harness, and uses a useful image: if the model is the brain, the harness is the body.

The model reasons about what it is shown and proposes an action. The harness decides what it is shown in the first place, whether the proposed action is permitted, whether it executes, and whether anyone finds out that it happened.

Why the distinction matters more than it sounds

Two consequences follow, and both are practical.

The model is replaceable and the harness is not. One harness can run several models, and a well-built harness will outlast a series of model upgrades. ASD’s phrasing is that the harness is likely to become the more enduring organisational capability. In management system terms, you are governing an asset with a long life, not a subscription you might change next quarter.

Most agent failures are harness failures. A model may pick the wrong tool, use the right tool badly, lose context, or propose something unsafe. Whether any of that reaches your production systems is decided by the harness. ASD gives the clean example: a model can propose a file deletion command, but whether the deletion happens depends on the harness and its controls.

That reframes the investigation question after an incident. The instinct is to adjust the prompt. The better question is what the harness permitted.

The part that cannot be fixed in the model

This is the sentence worth reading twice. ASD states that prompt injection has no fully reliable technical mitigation, because the weakness is inherent to how a language model processes context. A model is given instructions and information together, and it cannot reliably tell which is which. Anything it reads, a web page, a document, an email, a code comment, may be interpreted as an instruction.

If a weakness cannot be fixed in the model, it has to be contained around it, by limiting what the agent can reach and what it is permitted to do.

That is a control problem, not a technology problem, and it is exactly the kind of problem a management system exists to handle.

Update, 21 September 2026. ASD lists a UK National Cyber Security Centre post as a reference for this point, and the NCSC goes further than ASD does. In Prompt injection is not SQL injection (it may be worse), published 8 December 2025, its technical director argues that a classical confused deputy vulnerability can be mitigated, whereas a language model is inherently confusable, so the risk cannot be. The conclusion is the sentence to take into a risk workshop: “If the system’s security cannot tolerate the remaining risk, it may not be a good use case for LLMs.” Read that as a clause 6.1 decision. Sometimes the treatment is not a control at all. It is declining the use case and recording why. The NCSC also aligns its mitigations to ETSI TS 104 223, the baseline cyber security requirements for AI models and systems, which is a useful second reference if you are assembling the control set.

What the harness is made of

ASD breaks the harness into components. This matters because it converts a vague thing into a list you can put in a register, assign an owner to and audit against.

ASD’s point about this list is the useful one: these are settings. Which tools are exposed, what is permitted, which approvals are required, which connectors are attached. That is your configuration surface, and it is where your controls live.

Which software counts as a harness

Two kinds exist, and only one of them is the kind your organisation has. The first is sold as a framework or an SDK and is chosen deliberately by developers. Microsoft Agent Framework, which runs through Azure AI Foundry and which Microsoft gave a formal agent harness at Build this year, is the one most likely to turn up in an Australian business. Alongside it sit LangGraph, the OpenAI Agents SDK, CrewAI, Pydantic AI and, at the enterprise end, Rasa. That the term has settled enough for vendors to put it on a product page is itself worth noting: a year ago this layer had no agreed name.

The second kind is the one that matters for certification, and nobody calls it a harness. It is the agent already sitting inside software your organisation bought: Copilot inside the Microsoft tenancy, the agentic feature in the CRM, the notetaker that joins calls and writes to a shared drive, the automation platform quietly wiring them together. Every one of those has the components in the table above. Your organisation did not build them, cannot see most of the configuration, and in several cases did not decide to switch them on. None of that moves the accountability, which is the uncomfortable part.

Strip the branding and a harness is a list of settings: what the agent may call, which of those calls need a person to approve, what data and systems are attached, what it is shown, what it remembers between sessions, what gets logged, what standing rules it reads each time, and where its actions run. If you can write those eight things down on one page for one agent, you have most of an AI management system scope and the beginnings of a risk assessment. In our experience the exercise usually stalls on the second item, because almost nobody can say what their agent can reach.

That second kind raises a question the guidance does not answer. When the harness arrives inside a product you bought, you cannot read its tool registry or its permission model, because both belong to the vendor. The controls you do have are supplier controls: Annex A 5.19 to 5.21, and the ISO/IEC 42001 requirement to manage the suppliers of your AI services. So ask the vendor what the agent can reach in your tenant, which actions require a person to approve them, what is logged, and whether you can see the logs. A reassuring answer containing no nouns is itself a finding, which is the same test we applied to getting a specific answer out of an IT provider.

Update, 24 September 2026. The register this article recommends is now a numbered control. ASD’s September 2026 update to the Information Security Manual added controls recommending that every AI agent have its own identity, separate from any person’s account and from other agents (ISM-2133), and that organisations keep an AI agent register that is developed, implemented, maintained and regularly verified (ISM-2134). ISM-2135 sets out what the register should hold for each agent: a unique identifier, its owner and business purpose, the identities assigned to it, the accounts and credentials it uses, and the tools, permissions and data repositories it can reach.

Alongside the register, new controls recommend restricting agents to the minimum tools and permissions they need (ISM-2156), limiting an agent to what both the person invoking it and its task are allowed to do (ISM-2157), treating anything an agent retrieves as untrusted all the way through (ISM-2158), and centrally logging every tool call, external request and output (ISM-2159). An existing control, ISM-2113, now asks for human approval before sensitive or high-impact actions rather than simply flagging them. These are recommendations: ISM controls bind Commonwealth entities through the Protective Security Policy Framework and are guidance for everyone else. For a certified organisation the practical effect is the same, because an auditor now has a published benchmark to test your register against. We have updated the Harness Register template above with a unique agent identifier, a column for effective permissions, and the ISM control against every column in the mapping sheet.

Where this lands in ISO/IEC 42001

If you are certifying an AI management system, the harness is not a technical detail. It is most of your scope.

Clause 4.3, scope. An AI management system scope written around “our use of AI tools” is too vague to audit. A scope written around the harness, its connectors and the systems it reaches is specific, boundable and testable.

Clause 6.1 and the AI risk assessment. Assessing a model tells you about its known limitations. Assessing the harness tells you what an agent can reach in your business. ASD is explicit that the highest-impact organisational risks emerge when a model is connected to enterprise data and tools, which is to say they emerge in the harness.

The AI system impact assessment. Impact depends on what the system can do, not on what it can say. That is a harness question.

Clause 8.1, operational planning and control. The controls ASD recommends are operational controls: least privilege, approval gates on high-impact actions, validation of outputs, isolation of exploratory work in bounded sub-agents.

Clause 9.2, internal audit. Here is the part people miss. You cannot audit a model in any meaningful sense. You can audit a harness: read the tool registry, sample the approval records, test whether a permission actually blocks, check the logs exist and are protected. The harness is what makes an AI management system auditable at all.

Clause 5.3 and accountability. ASD is blunt that the harness may draft and act, but accountability for the result stays with a person. That is a roles and responsibilities requirement, not a technical one.

Our guide to what ISO 42001 means for AI companies covers the structure of the standard, and how 42001 and 27001 fit together covers the overlap.

And in ISO/IEC 27001 Annex A

Most of what ASD recommends is not new. It is existing information security practice pointed at a new kind of user, one that happens not to be human.

• A.8.2 privileged access rights. An agent with broad credentials is a privileged account. Treat it as one.
• A.5.9 inventory of information and other associated assets. You cannot govern connectors you have not listed.
• A.5.19, A.5.20 and A.5.21, supplier relationships and the ICT supply chain. A commercial harness is a supplier, and its update path is a supply chain.
• A.8.9 configuration management. The harness is configuration. That is the whole point.
• A.8.31 separation of development, test and production environments. ASD’s advice to restrict agent access to production is this control, restated.
• A.8.15 logging. Record prompts, responses, tool invocations, approvals, actions and configuration changes, then protect and retain them. Without this an agent’s activity is unreconstructable after the fact.
• A.8.16 monitoring activities. Logging is not the same as watching. ASD asks for logs to be independently monitored, which means by somebody who does not operate the agent.

Our explainer on the Annex A controls sets out the full set.

The controls ASD recommends

Worth reading in full, but the ones that will change what you do:

Treat a multi-agent system as a single agent. For security purposes, a compromise in one component propagates through shared context and trust relationships. We wrote about what happens when agents meant to be isolated find each other.

Delete stale context rather than summarising it. This one is easy to miss and genuinely counterintuitive. Summarising rewrites the record and can introduce new errors. Deleting does not.

Isolate exploration in sub-agents. Give a sub-agent only the tools, permissions and context needed for one bounded task. It limits exposure to untrusted content and keeps the main session small.

Keep a persistent rules file the harness reads every session. Standards, prohibited areas, build and test commands. It makes behaviour consistent and, more usefully for you, reviewable.

Monitor spend as a security signal. Agentic sessions cost far more than a single chatbot exchange. Unexplained consumption can indicate misuse, compromise or a runaway loop.

Do not rely on model safety controls instead of harness controls. ASD says this directly.

Seven questions for the board

ASD sets out governance questions for directors and executives. They translate almost word for word into management review input, which makes them worth putting in front of your leadership team before someone else does.

1. What business outcome is this system meant to achieve, and why does it need to be agentic?
2. What data, systems and tools can the agent reach, and is least privilege applied?
3. What actions can it perform, and which require human approval?
4. How are prompt injection and data poisoning being mitigated?
5. Can every significant decision, tool call and action be monitored and audited?
6. How will we know it is delivering value and staying within risk tolerance?
7. If the harness were compromised or misconfigured, what is the worst outcome, and what would limit it?

If your organisation cannot answer question two, the rest are academic.

What to do in the next month

• List your harnesses. Most organisations have more than they think, because every AI feature bolted into an existing product is one. Start from the shadow AI problem if you have no inventory.
• Write down what each one can reach. Data, systems, tools, credentials.
• Find the actions that do not require approval and decide whether that is deliberate.
• Check the logs exist, are protected, and are reviewed by somebody who does not operate the agent.
• Point your AI policy at the harness, not at a vendor. Our view on why your AI policy should not name a vendor explains the reasoning.
• Add agent identities to your access review. The logins you forgot to turn off covers the exit problem.

Speak with an experienced ISO auditor

If you are building or certifying an AI management system, the scoping decision is the one that determines whether the rest of the project is auditable. We build ISO/IEC 42001 systems around what your organisation actually controls, and we provide an independent internal audit where your team lacks the capacity or the impartiality to run it internally.

Email hello@streamline.business or use our contact page. Phone Brisbane 07 3667 8280, Sydney 02 8315 7780 or Melbourne 03 9034 3990.