The harness is where the risk lives
Most discussion of AI security focuses on the model itself. That is not where most of the risk lives.
The risk lives in the harness: the software layer that connects an AI model to your organisation's systems, data, and tools. The harness is what lets an AI agent read files, query databases, send messages, call APIs, trigger workflows, and interact with other agents. Without it, the model can only produce text. With it, the model can do things.
That capability is also the attack surface. Australia's Australian Signals Directorate (ASD) made this point directly in its Agentic AI Harnesses guidance, published September 2026. ASD identified the harness as the component organisations can most directly govern, secure, and control — and the one that most frequently lacks adequate controls.
Source: ASD Agentic AI Harnesses — cyber.gov.au
What a harness looks like in practice
Harnesses take different forms depending on how the AI system was built. What they have in common is that they extend the model's reach into your environment. In Australian and New Zealand organisations, the most common harness patterns are:
Protocol-level frameworks. MCP (Model Context Protocol) is the current dominant standard for connecting AI models to external tools and data sources. Most serious agentic deployments being built or purchased right now are MCP-based. MCP servers grant models access to file systems, APIs, calendars, databases, and enterprise applications. The trust boundaries between MCP servers and host systems are one of the most actively exploited attack surfaces in agentic AI.
Orchestration frameworks. LangChain, LangGraph, and LlamaIndex wire together sequences of model calls, tool calls, memory retrieval, and decision logic. A significant proportion of enterprise AI being deployed across Australia and New Zealand runs on these frameworks, whether the vendor discloses it or not.
Vendor-built agentic products. Microsoft Copilot, Salesforce Agentforce, and ServiceNow AI agents are packaged harnesses. The model connects to your Microsoft 365 environment, your CRM, or your ITSM platform. The harness is present and active — simply abstracted behind a product interface, which is precisely why many organisations cannot tell you what it can access, what it has done, or whether the access controls are appropriate.
Cloud-native agent platforms. AWS Bedrock Agents, Google Vertex AI Agent Builder, and Azure AI Foundry provide managed harness infrastructure inside the respective cloud environments, with native access to cloud storage, databases, identity services, and APIs.
Custom integrations. Larger organisations and software vendors build their own integration layers. More control, more responsibility, and substantially more risk if the team building it has not worked with AI-specific attack patterns before.
What ASD says to do about it
ASD's guidance identifies five categories of harness risk: privilege, design and configuration, behavioural, structural, and accountability. In plain terms: the model can access too much, the configuration creates unintended exposure, autonomous actions produce unexpected outcomes, the system is too complex to audit, and nobody can tell you what happened after the fact.
The recommended controls are least-privilege access, identity and access management applied to AI agent identities, secure design from the outset, monitoring and audit logging integrated with incident response, human oversight of high-impact actions, and phased adoption with validated controls before broader deployment.
These are governance requirements. They require evidence. That evidence has to come from somewhere.
Source: ASD Agentic AI Harnesses (September 2026) — cyber.gov.au
What AI Assurance tests
AI Assurance: Assess maps your harness configuration before testing it. We identify what implementation pattern your AI systems use, what systems and data the harness can reach, what trust boundaries exist between agents, and what access controls are in place. We then test those boundaries adversarially.
This is the work that vendor security attestations do not cover. When your AI vendor says their platform is secure, they are describing the model and the platform infrastructure. The harness — the system prompts, the tool integrations, the trust boundaries between agents — is your organisation's implementation. That implementation is entirely your responsibility and entirely untested until someone tests it.
AI Assurance: Assess tests the implementation layer. AI Assurance: Continuous monitors it ongoing, with F5 AI Guardrails enforcing runtime protection as the threat landscape evolves.
If you have deployed agentic AI and you do not know what harness pattern it uses, that is the first question AI Assurance: Assess answers.