Generative AI arrived in most companies before the controls did. LLMs, copilots and "vibe coding" — building software by prompting rather than writing — are already in daily use, often without inventory, policy or oversight. The problem is not using AI; it is using it without architecture, limits or evidence. This article sets out the real risks and the controls a reasonable organisation should already have.
At a glance
- The core issue: AI adoption has outrun governance — shadow AI with no inventory.
- The risks: data leakage, prompt injection, insecure generated code and leaked secrets.
- The controls: inventory, data-tiered policy, DLP, code review, least privilege and traceability.
Three levels of AI use, three levels of risk
It helps to distinguish low-impact assistant use; use connected to internal data or tools; and use with the ability to act — agents that can take actions on systems. Risk rises sharply across the three, and most organisations have all three running at once, often without realising it.
What really changes when a company adopts LLMs and agents
Data leaves more often and through more channels; untrusted content can become an instruction (prompt injection); development accelerates while security review does not; secrets and credentials leak faster; and agents add a genuinely new capability — the ability to act, not just answer. Each shifts the risk surface in a way traditional controls did not anticipate.
The most serious risks today
In practice the dangerous ones are: shadow AI with no inventory or governance; leakage of sensitive information into external models; prompt injection via untrusted external content; insecure code generated or accepted too quickly; and poorly governed secrets, credentials and connectors. The OWASP Top 10 for LLM Applications is a good map of the territory.
The controls a reasonable company should already have
None of these is exotic; the gap is usually that they have not been applied to AI yet:
- A real inventory of AI tools and how they are used — you cannot govern shadow AI you cannot see.
- A data-tiered AI usage policy that says what data may go where, aligned with the NIST AI Risk Management Framework.
- DLP and egress controls to catch sensitive data leaving through AI channels.
- Mandatory review of AI-generated code before it ships, backed by vulnerability management.
- Least privilege for copilots and agents, so an assistant cannot act beyond its remit — least privilege applies to machines too.
- Traceability and continuous supervision, ideally into a managed SOC.
What leadership should review
A short, honest review across governance, data, development, operations and compliance surfaces most of the exposure: is there an inventory and policy; where is sensitive data going; is AI-generated code reviewed; what can agents actually do; and can any of it be evidenced to an auditor. A security audit and Microsoft 365 security review are natural places to fold AI in — connected agents raise the same production-control questions covered in our MCP guidance.
What not to do
The common mistakes: treating this purely as a productivity story; believing an "enterprise" edition alone solves it; stopping at one policy and one training session; and assuming the risk lives only in the chat window rather than in code, connectors and agents. Each leaves a gap that adoption is already exploiting.
The bottom line
AI is not the risk; ungoverned AI is. The organisations that benefit are the ones that keep the speed while adding inventory, limits and evidence — turning shadow AI into governed AI. To assess where you stand and build the controls, talk to us or start with a GRC-aligned review.