法规简介
2026年9月11日,澳大利亚信号局(ASD)通过其下属澳大利亚网络安全中心(ACSC)正式发布《智能体AI框架——模型之上的层级》(Agentic AI harnesses — The layer above the model)出版物,面向正在采用或考虑采用智能体AI(agentic AI)的大型组织与关键基础设施、政府部门,专门就"框架(harness)"这一组件的治理与安全提出系统要求。这是继ASD联合美、加、新、英五国机构发布《审慎采用智能体AI服务》(Careful adoption of agentic AI services)之后,澳大利亚在智能体AI安全治理领域的又一项重要官方指引。
一、核心命题:组织可控的是"框架"而非大模型。指引将"框架"定义为智能体AI系统中除大语言模型(LLM)本身以外的全部组件——即连接LLM与外部工具、数据源、记忆与规划工作流的软件层,它负责执行动作与执行权限的控制,并运行直至任务完成的控制回路。若把LLM比作"大脑",框架就是"身体":LLM接收上下文、推理并建议动作,框架则提供上下文与记忆、执行访问数据或使用工具的动作,并对数据与工具施加权限与控制。指引强调,LLM是可插拔、可替换的,而框架才是组织长期积累能力、治理与投资的所在,因此应把框架视为AI系统的关键组成部分,并按其引入的风险施加相应安全与治理控制。
二、LLM与框架的九维对照。指引从核心职能、状态、动作、记忆、控制、一致性、失效模式、可变更性八个维度作出区分:LLM是"无状态、仅产出token、无法直接控制结果动作、失效模式为幻觉"的可替换部件;框架则是"有状态、可执行工具/编辑文件/运行命令/调用API、持有长期记忆与会话日志、通过权限/沙箱/审批门/策略实施控制、失效模式为错误文本/记忆丢失/不安全动作/上下文溢出"的持久架构。由此得出两点实践结论:一是LLM可替换,单套框架可与多个LLM配合,良好设计的框架将超越历次模型升级;二是许多看似"模型出错"的问题实为模型与框架交互所致,例如模型可能选错工具、用错工具、丢失上下文、超出上下文上限或建议不安全动作,而是否真正执行取决于框架及其控制——组织应同时排查模型决策与框架配置,而非仅依赖提示词调整。
三、框架十大组件构成组织的"配置面"。指引逐一列出用户界面、提示与策略层、上下文管理器、模型接口、工具注册表、权限系统、执行环境、连接器层(含RAG库与MCP工具)、记忆与会话存储、审计与可观测性、更新与供应链路径,并说明各自的安全关联:上下文管理器可能暴露敏感信息或遗漏重要上下文;工具注册表定义不清会放大运行风险;连接器层把框架接到外部数据源与企业系统;记忆与会话存储可能留存敏感、过期或被篡改的内容;更新与供应链路径引入新功能的同时带来供应链风险。指引指出,绝大多数对智能体系统的实际控制(暴露哪些工具、允许什么、需要哪些审批、挂接哪些连接器)都落在这一组件清单之中。
四、风险与缓解:五类风险与"无法在模型内解决"的提示注入。指引重申ASD五类风险划分:权限风险(代理被授予过度访问或权限,单点失陷即产生广泛后果)、设计与配置风险(架构、集成或设置不安全,在系统投运前即埋下弱点)、行为风险(代理以非预期方式追求目标,或被攻击者通过提示注入、数据投毒操纵)、结构性风险(故障在互联组件与多步工作流中级联,掩盖故障源头)、问责风险(系统复杂且不透明,难以追溯决策、审计动作或分配责任)。关于提示注入,指引明确指出:LLM把"指令"与"信息"一并提供为上下文,难以区分授权指令与外部内容中的信息,网页、文档、邮件、代码注释都可能被当作指令;目前不存在完全可靠的技术缓解手段,因该弱点内生于LLM处理上下文的方式,故缓解措施必须施加在框架层——通过控制代理可访问什么、可执行什么动作来实现。此外,就安全目的而言,多代理系统应视为单一代理对待,因为某一组件的失陷可经由共享上下文与信任关系扩散。
五、良好实践九项。包括:使用组织可控且经加固的环境,仅包含完成任务所需的工具与权限,限制对生产系统、敏感数据与网络服务的访问;配置框架以适用组织安全编码标准、禁止不安全动作、校验工具参数与输出,并要求对敏感或高影响动作进行人工审批;在投入运营使用前验证输出——代理的输出与动作应经评审、测试与正式验收,不得因"读起来自信"即视为正确,框架可以起草与执行,但结果的责任仍在人;对API实施成本控制——智能体会话成本远高于单次聊天,监测消耗可识别误用、失陷、失控代理循环或"denial-of-wallet"攻击;记录提示、响应、工具调用、审批、动作、安全事件与配置变更,并保护、留存、评审与独立监控日志;选择适合任务的可信模型并评估其来源、局限、安全特性与行为,不得以模型安全控制替代框架强制控制;保持上下文聚焦与相关性,遵循最小权限,需要缩减上下文时应删除陈旧内容而非摘要(摘要会重写记录并可能引入新错误),把持久事实与决策保存到外部记忆或文件,用带简明摘要的全新会话替换冗长陈旧会话;将探索性工作隔离在"子代理"(sub-agent)中并推广其使用,按最小权限原则为子代理仅配置特定任务所需的工具、权限与上下文;在组织层面维护框架强制读取的持久规则文件,记录标准、禁止区域与构建测试命令。
六、面向董事与高管的七项治理提问。指引要求高管就以下事项取得保证:该智能体系统欲实现的业务成果是什么、为何必须用智能体方式;代理可访问哪些数据、系统与工具,是否落实最小权限;代理可执行哪些动作、哪些需人工批准;提示注入、数据投毒等AI特有攻击如何缓解;是否可监控与审计全部重要决策、工具调用与动作;如何判断系统在交付价值、安全运行并处于可接受风险容忍度内;若框架被失陷、错误配置或操纵,最坏结果是什么、哪些控制可阻止或限制该结果。
指引最后强调:行业讨论往往聚焦LLM,但组织应同等关注框架;应从低风险用例起步、落实适当控制、保持人工监督,并仅在控制成熟后扩大部署。
【说明】以下为澳大利亚信号局(Australian Signals Directorate, ASD)下属澳大利亚网络安全中心
(Australian Cyber Security Centre, ACSC)于 2026 年 9 月 11 日首次发布的官方出版物
《Agentic AI harnesses — The layer above the model》(智能体 AI 框架:模型之上的层级)正文。
官方页面:https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/agentic-ai-harnesses
官方 PDF 附件:https://www.cyber.gov.au/sites/default/files/2026-09/Agentic%20AI%20Harnesses%20-%20The%20layer%20above%20the%20model.pdf
面向读者:大型组织与关键基础设施、政府部门,特别是 executive decision-makers、CISO 与 IT 负责人。
本文件为对该英文原文的完整整理,章节结构与原文一致;如需引用,请以官方英文原文为准。
Agentic AI harnesses — The layer above the model
Australian Signals Directorate (ASD) / Australian Cyber Security Centre (ACSC)
First published: 11 Sep 2026 | Last updated: 11 Sep 2026
Official source: https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/agentic-ai-harnesses
Content written for: Large organisations & infrastructure; Government
PURPOSE
This publication explains the concept of the Agentic AI harness (referred to hereafter as the harness), the software layer that enables a large language model (LLM) to interact with data, tools and systems to perform agentic tasks. It examines how harness design influences the security, governance, reliability and operational risks of agentic AI systems.
ASD's "Careful adoption of agentic AI services" provides broader guidance on agentic AI security considerations, including expanded attack surfaces, system complexity and the evolving security landscape. It also outlines the principal risk categories of privilege, design and configuration, behavioural, structural and accountability risks, and provides best-practice guidance for designing, developing, deploying and operating secure agentic AI systems. The harness publication complements that guidance by focusing on the harness as the component organisations can most directly govern, secure and control.
AUDIENCE
This publication is intended for organisations adopting or considering agentic AI. It is written for executive decision-makers, chief information security officers and IT leaders.
EXECUTIVE SUMMARY
A harness is the software layer that enables a large language model (LLM) to operate within real-world environments. If you think of the LLM as the brain, then the harness is the body. The LLM takes in information in the form of context, reasons about it and proposes actions to gain more information or complete the task. The harness provides information, as context and memory, it performs actions to access data or use tools, and it can enforce permission and controls on that data and tools. Together, these form an agentic AI system.
Understanding this distinction is important because while some risks stem from the behaviour of the LLM itself, many of the highest-impact organisational risks emerge when the model is connected to enterprise data, systems and tools through a harness. Security, privacy, governance and operational risks are often a consequence of what an agent can access, what actions it can perform, and how it interacts with organisational systems. Some risks, including prompt injection, cannot be reliably addressed within the model alone and require additional controls across the harness, connected systems and organisational governance processes. The harness and its associated integrations, governance mechanisms and operational processes are likely to represent a significant long-term organisational investment. While LLMs will continue to evolve and can be replaced over time, the harness ecosystem is likely to become the more enduring organisational capability. Organisations should treat the harness as a key component of their AI system and apply security and governance controls commensurate with the risk it introduces.
No harness is inherently secure. Organisations should apply established cyber security practices, including least-privilege access, identity and access management, secure design, monitoring, human oversight and integration with incident response processes. Agentic AI should be introduced through a phased approach that defines approved use cases, classifies data, selects appropriate harnesses, applies the controls described in ASD's "Careful adoption of agentic AI services", and validates security controls before broader deployment.
Successful adoption requires matching the model and harness to the task, granting only the access needed to perform that task, applying controls across multiple layers of the system, and maintaining clear human accountability for decisions, actions and outcomes.
Key takeaways
- organisations control the harness, not the LLM
- the harness is where long-term organisational value, governance and investment accumulate
- the harness and its surrounding technical ecosystem are the primary focus for security and risk management
WHAT IS A HARNESS
An agentic AI system comprises an LLM alongside external tools, external data sources, memory and planning workflows. Together, these components enable the system to perceive its environment and, where applicable, take action to achieve its goals.
This publication uses the term 'harness' to describe the components of an agentic AI system other than the LLM itself. The harness is the software layer that connects the LLM to external tools, data sources, memory and planning workflows. It also enforces the system's action and execution privileges and operates the control loop that repeats until a task is complete. In the terms used in "Careful adoption of agentic AI services", the LLM is the statistical model used to identify what actions to take. The harness supplies the agent's information input, provides its tool or service access, enforces its action and execution privileges, holds its memory and planning workflows, and records its metrics for evaluation.
Identifying the harness as a distinct part of an agentic AI system allows organisations to assess and govern it separately from the LLM. This is important because many of the decisions that determine an agentic AI system's reliability, operating cost and security risk are made in the harness, not in the LLM. In some cases, the harness is developed by the organisation; in others it is supplied as part of a commercial product or service. Regardless of its origin, organisations should understand the harness's capabilities, permissions, integration points and security controls, and assess the risks associated with its use.
The table below summarises the key differences between an LLM and a harness.
Dimension | LLM | Harness
Core job | Predict the next words or text; reasons over the text in front of it. | Decide what text goes in front of the model, and what to do with the output.
State | Stateless — each interaction starts without memory or previous interactions.| Stateful — persists context, files, memory and progress across turns and sessions.
Actions | Produces tokens only. | Executes tools, edits files, runs commands, calls APIs, browsers.
Memory | Only the current context window. | Long term memory, session logs, scratchpads, files.
Control | Produces outputs but does not directly control any resulting actions. | Permissions, sandboxes, approval gates, hooks, policies.
Consistency | Same input can yield different output. | Adds validation, structured output, retries and error recovery.
Failure mode | Hallucination, wrong answer. | Wrong text, lost memory, unsafe action, context overflow.
Changeability | A pluggable part you can swap. | The durable architecture that outlives any single model.
This distinction has two practical consequences.
First, the LLM is replaceable. A single harness can operate with multiple LLMs, and a well-designed harness will outlast successive model upgrades. For most organisations, the harness is the longer-term investment.
Second, many apparent agent failures result from the interaction between the model and the harness rather than the model alone. An LLM may select an inappropriate tool, use a tool incorrectly, lose context, exceed practical context limits, or propose an unsafe action. The harness determines which tools are available, enforces permissions and guardrails, and executes approved actions. For example, a model may propose a file deletion command, but whether that action is executed depends on the harness and its controls. When an agentic system behaves unexpectedly, organisations should investigate both the model's decision-making and the harness configuration rather than relying solely on prompt adjustments.
HARNESS COMPONENTS
The components of a harness, and the security relevance of each, are described below.
Component | Description
User interface | Determines the visibility users have of agent activity and the controls available for approval or intervention.
Prompt and policy layer | Stores system instructions, business rules and organisational policy that help guide agent behaviour.
Context manager | Selects the information provided to the model and can expose sensitive information or omit important context.
Model interface | Provides the interface between the harness and organisation-approved LLM services, sending prompts, context and model parameters and receiving generated responses.
Tool registry | Defines available tools and their functions. Poorly defined tools may increase operational risk.
Permission system | Controls approvals and permissions for sensitive actions.
Execution environment | Defines where actions execute and can enforce bounds on potential actions.
Connector layer | Connects the harness to external data sources, services and enterprise systems, including RAG repositories and MCP-enabled tools.
Memory and session store | Retains information between sessions and may preserve sensitive, stale or manipulated content.
Audit and observability | Records activity for monitoring, review and incident response.
Update and supply chain path | Introduces new functionality and potential supply-chain risk.
These components are the organisation's configuration surface: most of the practical controls over an agentic AI system — such as which tools are exposed, what is permitted, which approvals are required and which connectors are attached — are settings within this list.
SECURITY RISKS AND MITIGATIONS
The harness both contributes to the attack surface of an agentic AI system and provides the means to defend against it. Every external tool, data source, connector and memory store the harness adds is a new path into the system. At the same time, the harness is where security controls must be applied, because the most significant weakness of agentic AI cannot be fixed in the model itself.
Broader security considerations
The harness increases both the capability and attack surface of an agentic AI system. By connecting LLMs to organisational data, tools, services and operational environments, it introduces additional trust relationships, dependencies and integration points that may be exploited by a malicious actor if not appropriately secured.
Agentic AI systems are inherently complex. Decisions and actions may depend on interactions between models, harnesses, tools, data sources and external services. This complexity can obscure the origin of failures and increase the likelihood of cascading impacts across interconnected systems.
Organisations should manage agentic AI security within established cyber security frameworks and apply existing security practices, including secure-by-design principles, defence in depth, identity and access management, monitoring and incident response. The harness is a key location where these controls can be implemented and enforced.
Agentic AI security risks
LLMs are provided instructions and information together as context when queried. As a result, a model may have difficulty distinguishing authorised instructions from information contained within external content, creating opportunities for prompt injection and other manipulation techniques. Content processed by an LLM, including web pages, documents, emails and code comments, may be interpreted as an instruction. This weakness underpins prompt injection attacks, for which no fully reliable technical mitigation currently exists. Because the weakness is inherent to how LLMs 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's "Careful adoption of agentic AI services" categorises the security risks of agentic AI systems into five groups:
- privilege risks: agents granted excessive access or permissions, allowing a single compromise to have far-reaching consequences
- design and configuration risks: insecure architecture, integration or setup that creates weaknesses before the system is operational
- behavioural risks: agents pursuing goals in unintended ways, or being manipulated by malicious actors through techniques such as prompt injection and data poisoning
- structural risks: failures cascading across interconnected components and multi-step workflows, obscuring where a failure originated
- accountability risks: the complexity and opacity of agentic systems making it difficult to trace decisions, audit actions or assign responsibility.
For security purposes, a multi-agent system should be treated as a single agent, because a compromise in one component can propagate through shared context and trust relationships.
ASD's "Careful adoption of agentic AI services" recommends applying defence-in-depth controls across the agentic AI system lifecycle. Key practices include least-privilege access, strong identity and access management, controlled use of tools and external data sources, validation of agent outputs, human oversight of high-impact actions, continuous monitoring, supply-chain assurance and phased deployment of agentic capabilities. Organisations should implement these controls through the harness and surrounding infrastructure wherever possible, rather than relying solely on model behaviour or prompt instructions.
Many of these controls are implemented in, or enforced by, the harness.
GOOD PRACTICE
A harness can improve an organisation's cyber security posture by making security controls repeatable and enforceable, integrating security testing into workflows, limiting the effect of unsafe agent behaviour, and producing evidence that supports monitoring, investigation and continuous improvement.
- Use an organisation-controlled and hardened environment containing only the tools and permissions required for the task. Restrict access to production systems, sensitive data and network services.
- Configure the harness to apply organisational secure coding standards, prohibit unsafe actions and validate tool parameters and outputs. Require human approval for sensitive or high-impact actions.
- Verify outputs before putting them into operational usage. An agent's output and actions should be reviewed, tested and formally accepted before it is utilised in an operational setting, not treated as correct because it reads confidently. The harness may draft and act, but accountability for the result remains with a person.
- Implementing cost controls on APIs can help with cost monitoring as well as security. Agentic sessions cost substantially more than a single exchange with a chatbot, whether billed as tokens by a hosted provider or consumed as computing resources on self-hosted infrastructure. Monitoring this consumption can identify unexpected activity that may indicate misuse, compromise, runaway agent loops or denial-of-wallet attacks.
- Record prompts, responses, tool invocations, approvals, actions, security events and configuration changes. Protect, retain, review and independently monitor logs to support auditability, security monitoring, incident response, investigations and accountability.
- Select a trusted model appropriate to the task and assess its provenance, limitations, security characteristics and behaviour. Do not rely on model safety controls instead of harness-enforced controls.
- Keep context focused and relevant; only provide information and access required for the task at hand. Operate the harness with least privilege. When managing AI workflows retain only information that remains relevant to the task. Where context must be reduced, delete stale content rather than summarising it, as summarisation rewrites the record and risks introducing new errors. Save durable facts and decisions to external memory or files, and replace a long, stale session with a fresh one seeded with a concise summary.
- Isolate exploration in sub-agents (a separate agent instance the harness creates for a bounded part of a task) and promote their use. Applying least-privilege principles, organisations can configure sub-agents with only the tools, permissions and context required for specific tasks. This can limit exposure to untrusted content while keeping the primary agent's session context small and reducing security risk, operational cost and context degradation.
- Maintain a persistent mandatory rules file for the harness at an organisational level. Recording standards, prohibited areas, and build and test commands in a file the harness reads each session avoids rediscovering the same information every time, and makes the harness's behaviour more consistent and easier to review.
GOVERNANCE QUESTIONS FOR EXECUTIVES
Directors and senior executives do not need to understand every implementation detail of an agentic AI system. However, they should seek assurance that the harness, its integrations and its governance controls have been designed and implemented appropriately.
- What business outcome is this agentic AI system intended to achieve, and why is an agentic approach required?
- What data, systems and tools can the agent access, and are least-privilege principles being applied?
- What actions can the agent perform, and which actions require human approval?
- How are prompt injection, data poisoning and other AI-specific attacks being mitigated?
- Can all significant decisions, tool invocations and actions be monitored and audited?
- How will we know whether the system is delivering value, operating safely and remaining within acceptable risk tolerances?
- If the harness were compromised, misconfigured or manipulated, what is the worst outcome and what controls would prevent or limit that outcome?
CONCLUSION
The conversation around agentic AI often focuses on the LLM, but organisations should focus equally on the harness. The harness determines how an LLM interacts with tools, data and workflows, and it plays a major role in both capability and risk.
As models continue to change, the harness is likely to become the more enduring organisational capability. Well-designed harnesses can provide consistency, governance and security controls across changing generations of AI technology. Poorly designed harnesses can undermine even the most capable LLMs.
Start with low risk use cases, implement appropriate controls, maintain human oversight and expand deployment only as controls mature.
Organisations should apply the security practices described in ASD's "Careful adoption of agentic AI services" and implement them through the harness and surrounding ecosystem.
ADDITIONAL READING
- National Cyber Security Centre - UK: "Prompt injection is not SQL injection (it may be worse)".