AI Governance in Practice: What CISOs Actually Need to Secure the AI Workspace

Q: "Why does blocking shadow AI tools fail as a security strategy?"

"Blocking drives usage underground. 57% of employees already hide their AI tool usage from their employer - not because they are doing something malicious, but because the policy said no and the work still needed to get done. Blocking via network controls pushes employees toward personal VPNs and personal devices, removing what little visibility the security team had. The result is the worst outcome: AI is in use everywhere, with no logging, no data controls, and no governance."

Q: "What does genuine AI visibility actually require?"

"Three layers: tools - what AI applications are actually running (most security teams can name two or three; the real number is typically ten times that); ecosystem - what those tools connect to, including MCP servers, plugins, and extensions with active access to CRM or cloud infrastructure; and artifacts - what employees are building with AI, such as internal apps and automated workflows that can create exposures without any data ever being directly leaked. Visibility across all three layers is the foundation - without it, governance is guesswork."

Q: "How do NIS2, DORA, and the EU AI Act apply to AI workspace risk?"

"All three frameworks reach AI-generated artifacts and third-party tool risk. NIS2 requires network and information systems security controls that extend to the tools operating within them. DORA mandates ICT third-party risk management, which includes AI tools connected to financial processes. The EU AI Act introduces obligations around high-risk AI system usage. A statement that a policy existed will not hold up in an audit when evidence shows unmanaged AI tooling connected to critical systems."

11 May 2026 • 3 min read • AI GovernanceShadow AIAI Workspace SecurityCISOCEEMENAAI Security

AI governance in practice starts with an uncomfortable number: 57% of employees actively hide their AI tool usage from their employer.

Not because they are doing something malicious. Because the policy said no, and the work still needed to get done.

I see this regularly. The policy exists. The behavior it was written to stop exists too - just invisible.

The threat model is already wrong

Most security teams are still thinking about AI risk as a browser tab. Someone pasting text into ChatGPT. Maybe leaking something sensitive.

That was 2023.

Today the average enterprise has up to 27 AI tools actively running. AI-native IDEs with full filesystem access. Vibe-coding builders connected to production SaaS. MCP servers giving AI models a direct interface into internal APIs and databases.

Every endpoint is now an AI workspace. Your perimeter controls cannot see any of it.

Two responses. Both wrong.

Block everything - employees route around it via personal VPNs, shadow AI goes deeper underground, you lose what little visibility you had.

Allow without supervision - every endpoint becomes a potential entry point, and you have no idea what data is going where.

I spoke recently with the team at Pluto Security. They described a real incident: an employee used Lovable to build an internal app connected to Workday and Salesforce. The AI automatically spun up a Supabase database. Misconfigured. Exposed to the public internet. A direct backdoor into core business systems - built by someone trying to be productive, not by an attacker.

The tool was not the problem. Nobody knew it was running.

What visibility actually means

Before you govern anything, you need to know what exists. Three layers:

Tools - what AI applications are actually running. Most security teams can name two or three. The real number is ten times that.

Ecosystem - what those tools connect to. MCPs, plugins, extensions. An AI that reads text is one risk. An AI with an active connection to your CRM or cloud infrastructure is another.

Artifacts - what employees are building with these tools. Code, workflows, internal apps. The Lovable incident was an artifact problem - the AI did not leak data, it built something that created the exposure.

Pluto Security can map roughly 80% of an organization’s shadow AI footprint in two hours via read-only EDR integration. No agents, no infrastructure change. Visibility does not have to be a six-month project.

Control that scales

Runtime enforcement beats network blocks. PII going into a public model - intercepted. Malicious extension executing - stopped. The employee gets an in-context message explaining the policy, not a generic block page.

No 50-analyst SOC required.

The CEE angle

NIS2, DORA, and the EU AI Act all touch AI-generated artifacts and third-party tool risk. “We had a policy” will not hold up in an audit when the evidence shows unmanaged tooling connected to critical systems.

Start with the footprint. Find out what is running. Map the connections. Understand what has been built. That takes hours.

Everything else follows from there.

For the identity and access dimension - how AI agents inherit credentials and what that means for your attack surface - see AI Agents Already Have the Keys.

Working through this in your organization? Reach out via LinkedIn or info@et-cybersecurity.pl.

Frequently asked questions

Why does blocking shadow AI tools fail as a security strategy?

Blocking drives usage underground. 57% of employees already hide their AI tool usage from their employer - not because they are doing something malicious, but because the policy said no and the work still needed to get done. Blocking via network controls pushes employees toward personal VPNs and personal devices, removing what little visibility the security team had. The result is the worst outcome: AI is in use everywhere, with no logging, no data controls, and no governance.

What does genuine AI visibility actually require?

Three layers: tools - what AI applications are actually running (most security teams can name two or three; the real number is typically ten times that); ecosystem - what those tools connect to, including MCP servers, plugins, and extensions with active access to CRM or cloud infrastructure; and artifacts - what employees are building with AI, such as internal apps and automated workflows that can create exposures without any data ever being directly leaked. Visibility across all three layers is the foundation - without it, governance is guesswork.

How do NIS2, DORA, and the EU AI Act apply to AI workspace risk?

All three frameworks reach AI-generated artifacts and third-party tool risk. NIS2 requires network and information systems security controls that extend to the tools operating within them. DORA mandates ICT third-party risk management, which includes AI tools connected to financial processes. The EU AI Act introduces obligations around high-risk AI system usage. A statement that a policy existed will not hold up in an audit when evidence shows unmanaged AI tooling connected to critical systems.