We use necessary cookies to make our site work. We’d also like to use some non-essential cookies (including third-party cookies) to help us improve the site. By clicking ‘Accept recommended settings’ on this banner, you accept our use of analytics cookies. For more information on how these cookies work please see our Cookie policy.
The Bank of England has heard through the Frontier AI Information Sharing Forum (FAISF) that the practical use of frontier AI for cyber defence is shaped not only by access to the underlying model, but by the design of the surrounding harness.
This article summarises discussion themes for a wider sector audience, to support internal firm discussions. It does not set new Bank supervisory expectations or policy, prescribe implementation models or provide guidance.
A harness is the collection of tools, workflows, controls, data and operating environments that sit around a frontier AI model and shape how it is used.
In cyber defence, a harness helps translate model capability into outputs that can be reviewed, validated and acted upon in practice. It can determine what information is provided to the model, what tasks it performs, how outputs are checked, and how findings are routed to cybersecurity and engineering teams. This article explores the practical considerations involved in designing these surrounding capabilities.
Access to a powerful AI model does not automatically create an effective cyber defence capability.
A well-designed harness can help turn model capability into cyber defence outputs that are usable, explainable and capable of being acted upon. This can include how tasks are framed, how outputs are checked, how findings are routed to cyber or engineering teams, and how human review is built into the workflow.
This places emphasis on the architecture around the model, including the way tools, workflows and controls are organised and connected, together with workflow design, controlled access to tools, contextual information provided to the model, validation steps and integration with existing engineering and security platforms. Model access alone is unlikely to provide a reliable cyber defence capability without these surrounding design choices.
This means that the benefits organisations obtain from frontier AI may depend as much on harness design as on the underlying model itself.
Firms can choose from a growing range of ways to build and operate AI harnesses, each with different strengths and limitations.
A range of harness approaches is emerging, including internally developed tools, vendor-provided platforms, managed third-party offerings and open-source components. No single approach appears to provide a complete solution at this stage. Different approaches offer different degrees of flexibility, supportability, transparency, organisation-specific context, and integration with existing cyber processes.
Vendor-provided harnesses can be useful where they are closely aligned to the underlying model. Their limitations may become more apparent where greater context, customised workflows, output validation, or more accurate or detailed results are sought. Internal and open-source components can add flexibility, but may also place greater demands on engineering capability, documentation, maintenance and assurance.
Experiences with AI-enabled vulnerability scanning systems highlighted the benefits of using specialised AI agents focused on different types of vulnerabilities. These agents could compare and cross-check findings before presenting results, helping to reduce low-value engineering work. Limitations included black-box characteristics, limited context in current versions, and the possibility that some deployments may work across multiple models rather than being tied to a single frontier AI model.
Some approaches may offer pre-built agents, model-specific workflows or mechanisms for comparing outputs across multiple runs. Others may offer greater transparency, customisation or integration with internal tooling, while carrying higher engineering and support demands.
The choice of harness can therefore influence not only technical performance, but also how easily organisations can integrate AI capability into existing cybersecurity processes and operating models.
As firms experiment with different AI tools and models, one challenge is avoiding early dependence on a single technology, supplier or approach.
Wrapper or orchestration layers can provide a way to coordinate multiple harnesses, route activity to specialist tools or models, and reduce early dependency on a single model or vendor. This can be relevant where different tools perform better against different vulnerability classes, testing objectives, validation activities or stages of a workflow. In practice, this could allow one tool to be used for discovery, another for validation, and a separate workflow for human review, triage or remediation routing.
A modular architecture may help compare capabilities, improve signal-to-noise, support substitution between tools and preserve flexibility as frontier models and harness technologies continue to evolve. It can also provide a structure for separating specialist agent roles, mechanisms that compare findings from multiple agents, validation steps and human review points.
A range of other tools and initiatives also illustrates the pace of development in this area, including open-source harness work from Visa, XBow, Terra, Elias Robotics, CAI and AISLE. These examples can support awareness and comparison, while also highlighting the distinction between promising technical capability and solutions that are sufficiently flexible, reliable and supportable for broader enterprise use.
This flexibility may become increasingly important as frontier AI models, harness technologies and supporting tools continue to evolve.
One of the practical challenges in applying frontier AI to cyber defence is deciding how much organisational information the model and harness should be allowed to access.
Model effectiveness is highly dependent on the quality and relevance of organisational context. Relevant inputs can include source code, asset and environment information, security architecture, control data and other contextual material.
However, deciding what information can be safely provided to FAI models and harnesses remains a central risk management question. Differentiated approaches may be relevant for classification, supplier assurance, data access and exclusions, including limiting repositories, sensitive intellectual property or higher-risk business areas from ingestion. The engineering challenge is to provide enough context to generate actionable findings while reducing unnecessary exposure of sensitive information. Relevant considerations include confidentiality, data protection, supplier assurance, information-handling restrictions, and potential misuse if a powerful model or harness were compromised.
Direct deployment into production networks is generally regarded as higher risk, particularly where cyber guardrails are removed or where the model could interact with live systems. Firms are therefore exploring isolated, sandboxed, production-like or non-production environments to obtain security benefit while reducing operational and misuse risks.
A clearer treatment of data access can help define which repositories, assets, environments and data classes are in scope, restricted or excluded. Useful distinctions can include source code as a production artefact, production networks, production-like test environments, externally facing perimeter testing and human-executed attack simulation. These distinctions can help separate access to source code or production artefacts from access to live production environments.
The overall challenge is to provide enough information for frontier AI to produce useful cybersecurity outcomes while reducing unnecessary exposure of sensitive systems, data and intellectual property.
As AI capabilities become more powerful, organisations are exploring how safeguards can be built directly into the harness and the environments in which it operates.
Governance decisions can be reflected through practical controls within the harness and its operating environment. This can include use-case restrictions, controlled user access, network isolation, environment segregation, monitoring, approval workflows, rules of engagement and controls that limit when and how users or systems can obtain access.
Model-level or platform-level guardrails may therefore be only one part of the control design, with additional controls applied through the harness, user permissions and operating environment.
These embedded controls are particularly relevant where a harness interacts with sensitive code, production-like data, security tooling or adversarial testing workflows.
A key design trade-off concerns how close powerful AI capabilities are placed to production-like environments in order to identify vulnerabilities earlier, balanced against the potential for misuse, compromise, unexpected behaviour or operational impact. The balance can vary by use case, environment, control maturity and the level of confidence in human oversight.
The practical challenge is not simply introducing AI capability but determining how it can be used safely and effectively within existing operational and security boundaries.
Identifying potential vulnerabilities is only one part of the challenge. Organisations must also be able to validate, prioritise and address findings at a scale they can manage.
Harness effectiveness is not only about identifying potential issues. Scaling is likely to depend on the capacity to triage, validate, prioritise and remediate outputs without overwhelming engineering, cyber or remediation teams. False positives, remediation burden, validation effort and team capacity can become significant constraints as use cases expand.
Scaling can also depend on suitable environments, access to relevant repositories and assets, integration with existing engineering and security tooling, and the ability to feed validated findings into established remediation processes.
This points to the importance of operating models that bring together red teaming, software engineering, AI literacy, security architecture and operational cyber expertise. A mix of internal capability building, structured knowledge sharing and external support may help grow capability over time.
The same issue can also arise across the wider supplier ecosystem. Some third parties may have fewer engineering resources than larger firms, creating potential dependencies as AI-enabled vulnerability discovery and remediation activity increases.
Scaling the use of frontier AI may therefore depend as much on people, processes and remediation capacity as on the AI capability itself.