What is a governed workspace for security applications?

Definition

A governed workspace for security applications is a platform where security, IT and GRC teams build applications with AI on a consolidated live data layer, then run them in production with hosting, single sign-on, roles and permissions, human-approved actions and an audit log already in place.

It matters now because AI coding agents have made building a security application the common response to a tooling gap. Getting that application into production, with the controls a security team would demand of any other software, has not become easier.

The phrase "governed AI workspace" is also used for a governed chat environment where employees use large language models. This article is about something else: a place to build and run security applications. The two overlap only in the word "governed".

Why do security teams need one now?

Security teams need a governed workspace for their applications now because they are already building tools with AI, and without a governed place to run them those tools end up in one of two bad outcomes: they stall at security review, or they reach production without consistent oversight.

The building has already happened. In research commissioned by ThreatAware, the cybersecurity software company behind Dimension, and conducted by Censuswide (opens in a new tab) among 300 UK IT security decision makers at businesses with 1,000 to 10,000 employees, 16 to 22 October 2026, 77% said their security team had used AI coding assistants to build internal security tools in the past 12 months. Across the wider developer population, 84% use or plan to use AI tools (opens in a new tab) in their development process, according to Stack Overflow's 2025 Developer Survey of 33,662 respondents.

The building is not confined to engineers. In a May 2026 survey of 818 US workers who had built a work tool with AI coding tools, conducted by Centiment for Zapier, 49% had shipped four or more tools (opens in a new tab) in the past year.

The first bad outcome is that the application never ships. In the same ThreatAware research, 69% said tools had been delayed or scrapped because of security, governance or compliance concerns. The build was fine; hosting, authentication, permissions, approvals, audit and backups were not, and a hardening project at the end rarely gets funded.

The second bad outcome is that the application ships anyway. 45% said self-built tools do not go through the same review and approval process as other software, and 41% had no formal policy for AI-built internal security applications, or did not enforce one.

The security team, whose job is to reduce shadow IT, becomes a source of it.

Both outcomes land on teams with no slack. 59% of cybersecurity professionals (opens in a new tab) report critical or significant skills shortages, up from 44% a year earlier, in ISC2's 2025 workforce study of 16,029 professionals. Analyst Jerry Gamblin's review of CVE List data counts 48,185 CVEs published in 2025 (opens in a new tab), up 20.6% on 2024.

The work is growing faster than the headcount, which is why teams build their own tools in the first place.

What does "governed" mean in practice?

In a governed workspace for security applications, governed means every application runs behind the organization's single sign-on, within defined roles and permissions, with a person approving each action that changes a live system and every action recorded in an audit log. The controls belong to the platform, not to the individual application, so every builder gets the same ones without configuring them.

In practice that comes down to six controls.

Control	What it does	What it replaces
Hosting and isolated tenancy	Each customer runs in a dedicated tenant, with backups and regional data residency maintained by the platform	A builder's own cloud account, or a laptop
SSO and user provisioning	Every application sits behind the organization's identity provider from the first login	A separate login per application, or none
Roles and permissions	Who can build, who can view and who can approve are defined once and apply to every application	Admin access for everyone who needs the tool to work
Human approval before action	When an application needs to disable a user, open a ticket or change a configuration, a person approves it first and existing permissions still apply	Scripts that run with whatever credentials they were given
Audit log	Every view, change and action is written to a tamper-evident log that assessors can query or export	Nothing, or a chat message saying it was done
Versioning and shared ownership	Applications live in a shared workspace, versioned, so they outlast the person who built them	One person's script, one person's knowledge

Two details matter. First, the data layer is read-only: building and reporting never touch production, and the only way an application changes a live system is through an action that has been explicitly connected to it and approved.

Second, applications are not approved as a gate. The builder publishes the application, and the governance sits in where it runs and what it is allowed to do: an application can only read the feeds and call the actions connected to it, and application code is separated from execution. Code review before publishing remains the team's own process, as it would be for any other software.

What are the risks of AI-built security tools without governance?

The risks of AI-built security tools without governance are sprawl, unreviewed code acting on live systems, dependence on one person and gaps in audit evidence. None of these is caused by AI. AI made building cheap enough that all four now happen more often.

Sprawl. Applications multiply across security operations, IT, GRC, identity and cloud, and each builder chooses their own hosting, login and data handling. 60% of organizations (opens in a new tab) say they lack confidence in their ability to detect unregulated AI deployments (Cisco, 2025 Cybersecurity Readiness Index, 8,000 leaders in 30 markets).

Unreviewed code acting on live systems. In Veracode's 2025 GenAI Code Security Report, AI-generated code introduced a security vulnerability in 45% of test cases (opens in a new tab) across 80 coding tasks and more than 100 models. That is manageable when the code produces a dashboard. It is not manageable when the code can disable accounts or change cloud configuration with whatever credentials it was handed.

Dependence on one person. Scripts and spreadsheets depend on whoever built them. When that person changes role, the knowledge and the tooling go with them, and the team inherits something it cannot safely change or switch off.

Gaps in audit evidence. An application that runs outside the organization's controls produces no usable record of who saw what, who changed what and who approved it. IBM's Cost of a Data Breach Report 2025 (opens in a new tab) found that one in five organizations had a breach involving shadow AI, that organizations with high shadow AI use saw breach costs $670,000 higher on average, and that 63% of breached organizations had no AI governance policy or were still writing one.

How is it different from low-code builders, SOAR and building it yourself?

A governed workspace for security applications differs from low-code builders, SOAR platforms and building on your own cloud in that it combines a security data layer, AI building and production governance in one place, where the alternatives each cover one or two of those and leave the rest to the team.

	Governed workspace for security applications	Low-code builder	SOAR or AI SOC platform	AI coding agent on your own cloud
Data	Consolidated, read-only live data layer connected to the systems you already run through their APIs	General-purpose connectors to databases and APIs	Alert and case data from integrated tools, built for the SOC	Whatever the builder connects, with whatever credentials they hold
Governance	SSO, roles, approval before action and an audit log built into the platform, on every application	Authentication, access control and audit logging available, applied per application by the builder	Playbook permissions and run logs, scoped to automation	Solved per application, differently by every builder
AI building	Describe the application in natural language, or build with your own AI coding agent over MCP	AI application generation and agent integration on most platforms	AI agents for triage, investigation and response, not for building applications	The strongest part of this option
Production readiness	Hosting, tenancy, backups, versioning and sandbox-to-production promotion are the platform's job	Hosting provided; security controls configured by the builder	Production-grade for automation workflows	Hosting, hardening and maintenance are the team's job
Ownership	Shared, versioned workspace; applications outlast the builder	Shared workspace, typically owned by engineering	Owned by the SOC	Owned by whoever built it

The column headings describe product categories, not specific vendors, but the vendors are worth naming, in their own words. Retool (opens in a new tab) describes itself as a way to "build, deploy, and manage internal tools" and offers importing of applications built in Lovable and Replit, with built-in authentication, access controls and audit logging.

Torq (opens in a new tab) calls itself "the AI SOC platform that helps security teams triage, investigate, and respond to threats faster". Swimlane (opens in a new tab) describes "agentic AI automation for every security function". Tines (opens in a new tab) says "Tines lets every team build. IT and Security maintain complete visibility, governance, and control."

CrowdStrike Falcon Foundry (opens in a new tab) calls itself "cybersecurity's first AI-driven application development platform" and runs applications on Falcon data and infrastructure. Sola Security (opens in a new tab) describes itself as "one living understanding of your entire environment", a read-only context layer that answers questions across systems.

Of these, Falcon Foundry is the closest in category. The difference is that a governed workspace for security applications is built to connect any system through its API and to serve security, IT and GRC teams together, rather than extending one vendor's platform.

Building with an AI coding agent on your own cloud is as much a partner to a governed workspace as an alternative. The agent does the build. The workspace is where the build lands, with one foundation, one set of controls and one audit log.

Who needs one, and who doesn't?

A governed workspace for security applications is for any organization with an in-house security function that builds its own tooling, whether that function is one person with scripts and spreadsheets or a large team building across several departments. The people building are not always engineers: in the Zapier survey of 818 US workers who had built work tools with AI, 34% had no formal programming background (opens in a new tab) and 44% built only for internal use.

Mid-market organizations, 100 to 1,000 employees. In ThreatAware's experience across more than 100 enterprise customers, the security function is one to three people, often one person carrying the whole mandate, with no formal CISO. The estate is cloud-first and often Microsoft-centric, critical tracking lives in spreadsheets, and gaps are filled with scripts and open-source tools.

A compliance standard such as Cyber Essentials Plus or ISO 27001 often has to be met to win larger clients. These teams need ready-made applications they can point at their data, and a foundation they do not have to host or maintain.

Enterprises, 1,000 employees and more. There is an established security team with a CISO, a dense tool stack with visible overlap, and building already happening across security operations, IT, GRC, identity and cloud. None of it sits on a common foundation. These teams need one governed place for the applications they are already building, and a way to replace the tools they pay for but do not fully use.

Who does not need one. Organizations with no in-house security function, or with security fully outsourced and nobody to shape the tools. Teams that want a finished product and have no intention of customizing anything. For them a conventional security product, or a managed service, is the better buy.

How do you evaluate a governed workspace for security applications?

Evaluate a governed workspace for security applications by checking that the governance is built into the platform rather than left to each builder, and that it covers the whole lifecycle from data connection to production action. Most organizations are evaluating from a low base: in ISACA's 2025 AI Pulse Poll, only 31% of European organizations (opens in a new tab) had a formal, comprehensive AI policy, while 83% believed employees were using AI.

Twelve things to look for:

1. A consolidated, read-only data layer. It should connect any system through its API and never write back to production except through an explicit action.
2. Two ways to build. Natural language in the platform, and your own AI coding agent such as Claude Code connected over MCP, producing the same governed application either way.
3. SSO on every plan. If single sign-on is a paid add-on, the smallest teams, who are least able to retrofit it, will go without.
4. Roles and permissions defined once. Builders, viewers and approvers set at workspace level, not per application.
5. An approval gate on every action. A person signs off before anything changes a live system, and the organization's existing permissions still apply.
6. A tamper-evident, exportable audit log. Every view, change and action, in a form assessors can query without the vendor's help.
7. Isolated tenancy and data residency. A dedicated tenant, not a shared pool, in the region you need.
8. Sandbox to production, with versions. Build against live data behind real authentication, promote when ready, and see what changed and when.
9. No model training on your data. Stated in the terms, not just the marketing.
10. Applications that outlive the builder. Shared, versioned and maintained by the platform, so the team can run and change them after the person who built them has moved on.
11. A way in for what you already built. Applications built elsewhere, in a coding agent or a low-code tool, can be imported and run under the same controls, so governance starts with the inventory you have rather than the next build.
12. Clear answers on credentials and exit. Ask how credentials to connected systems are stored and scoped, how a misbehaving application is paused or rolled back to a previous version, and how applications and data are exported if you leave.

A useful test: take the application your team most depends on today, the one held together by one person, and ask how each candidate would run it tomorrow if that person left.

Where does Dimension fit?

Dimension by ThreatAware is one implementation of a governed workspace for security applications. ThreatAware, a UK cybersecurity software company, launched Dimension in October 2026 as its second product, alongside its cyber asset management platform. It has three core components on one foundation.

Data (opens in a new tab) connects the systems the organization already runs, through their APIs, into one consolidated, read-only data layer. Studio is where applications are built, either by describing them to AI Composer or by building with your own AI coding agent over MCP. Actions let applications change live systems, with a person approving each action and every action written to the audit log.

The foundation under all three provides hosting and isolated tenancy on AWS, SSO and user provisioning, roles and permissions, change approvals, the audit log, backups and version control. Teams can start from a ready-made application in the App Library (opens in a new tab), reshape one that is close, or build one that does not exist yet. SSO, approvals and the audit log are included on every plan, from Starter upward (pricing (opens in a new tab)).

Dimension is built by ThreatAware, a cybersecurity software company founded in 2018 whose software is used by more than 100 enterprise organizations across Europe and North America. ThreatAware is ISO/IEC 27001:2022 certified. Product documentation, including MCP setup for Claude Code, Claude Desktop, VS Code, Copilot CLI and Codex, is at docs.dimension.io (opens in a new tab).