Cyber asset management provider ThreatAware has launched Dimension, a platform intended to put controls around the custom applications security teams build using AI coding tools. The launch, reported by CIR Magazine on 28 October 2026, addresses a problem for organisations adopting AI-assisted development: software can be created faster than the processes needed to govern its use.
Research accompanying the launch suggests that internal security tools are not always subject to established software checks. For UK and European organisations, that raises an operational question as well as a technical one: whether applications built to strengthen defences are themselves being given adequate scrutiny before gaining access to business systems.
What happened
Dimension provides an environment in which organisations can develop and operate bespoke security applications using AI coding tools. According to CIR Magazine, its features include permission controls, approval workflows, activity records, version management and backups. These address different parts of an application's lifecycle, from deciding who can use it to recording activity and preserving earlier versions.
Applications built in the workspace can connect to existing systems through application programming interfaces, or APIs. ThreatAware says actions that alter live systems require explicit configuration and approval. That distinction is important: a tool that retrieves information has a different operational risk profile from one authorised to change the environment it monitors.
The platform's proposition is therefore broader than helping teams produce code. It is intended to provide a controlled setting for running that code, including oversight of the information applications can reach and the automated actions they can perform. The launch report does not provide independent testing of those controls or evidence of their effectiveness in customer deployments.
ThreatAware chief executive and co-founder Jon Abbott framed the issue as one of continuing responsibility after development. In comments reported by CIR Magazine, he argued that organisations need to establish application ownership and understand data access, rather than treating a working piece of software as a finished governance task.
The background
The Censuswide research surveyed IT security decision-makers. It found that 77 per cent said their security teams had used AI coding assistants to create internal security tools during the preceding 12 months. The figure indicates substantial adoption among respondents, although the source does not specify the survey's sample size, geographical coverage or fieldwork dates.
The findings also identified uneven oversight. Some 45 per cent said internally built tools were not put through the same review and approval procedures as other software. Separately, 41 per cent reported either having no formal policy for AI-built internal security applications or not enforcing one. These are distinct weaknesses: a documented policy does not establish that checks actually take place.
Governance concerns were also affecting delivery. Among respondents, 69 per cent said applications had been postponed or dropped because of security, governance or compliance issues. The research does not establish whether those decisions reflected effective safeguards, unclear requirements or difficulties meeting them.
AI coding assistance changes the speed and accessibility of development, but it does not remove conventional software risks. Permissions, maintenance and accountability remain relevant regardless of how code is produced. That management challenge connects with the wider debate over making AI risk a boardroom responsibility: decisions about acceptable access and operational authority cannot be settled by development teams alone.
For security leaders, the survey's scope matters. Its findings concern tools created by security teams themselves, not merely applications introduced elsewhere in the organisation. Internal provenance is not a substitute for review, particularly when software can interact with production systems.
What people are saying
Abbott’s commercial argument is that bespoke development need not come at the expense of control. He told CIR Magazine that Dimension was intended to let organisations create tools without adding “another layer of unmanaged technology”. That sets a test for the product: whether centralising development also makes the resulting applications easier to supervise in practice.
The launch report contains no customer testimony or external expert assessment. Nor does it identify the kinds of applications respondents were building. A reporting utility and a tool used during incident response could have very different consequences if they failed; the survey does not distinguish between those uses.
The findings should not, therefore, be read as evidence that AI-built security applications have caused breaches. They describe reported practices and concerns, rather than measured incidents or losses. Establishing the relationship between those practices and operational harm would require evidence beyond the research presented.
What happens next
For prospective buyers, several procurement questions remain unanswered. CIR Magazine’s report does not specify pricing, deployment arrangements, supported AI coding assistants or where application data would be hosted. Those details would help UK and European organisations assess contractual obligations, integration requirements and the suitability of the service for sensitive information.
Technical evaluation would also need to distinguish between governing an application and checking its code. Approval to run software does not establish that its logic is correct or that it handles unexpected inputs safely. The report does not describe vulnerability testing or code-validation capabilities, leaving buyers to establish how those tasks would fit into their existing assurance processes.
Connections to other systems create a separate set of checks. Organisations would need to examine how credentials are stored, limited and revoked, including when an application is retired. The broader importance of validating trust between connected components is reflected in reporting on GoAhead TLS flaws and device trust checks; the launch report does not suggest any connection between those flaws and Dimension.
Data handling would merit similar scrutiny. Moving information into a custom application can introduce additional storage, retention and deletion questions, even if the original system remains secure. The Engie breach involving partner marketing systems provides a separate context for examining where information travels beyond its original environment.
Continuity teams would also need to establish what happens if the workspace becomes unavailable. Restoring an application’s code is not necessarily the same as reversing changes it has made elsewhere. Before relying on a bespoke tool for an essential security task, an organisation would need to test recovery arrangements and determine whether that task could continue without the platform.
