There is a race on. Not the humanoid robot race — though that’s coming too — but a quieter and in some ways more consequential one. The race to get a large language model into production inside your enterprise before your competitors do, before your board starts asking why you haven’t, or simply because someone in the business discovered ChatGPT six months ago and has been asking IT to productise it ever since.
The pressure is real. The technology is genuinely useful. And the security frameworks have not kept up.
The problem with moving fast on AI
Organisations that have built mature security practices around traditional application development are discovering that LLMs introduce threat vectors that their existing controls simply weren’t designed to address. This isn’t a reason not to deploy AI — it’s a reason to deploy it thoughtfully.
The most dangerous posture we see is the one where AI is treated as a normal software deployment. It isn’t. A conventional application does what its code says. An LLM does what its training and its prompt say — and both of those surfaces can be manipulated in ways that traditional input validation doesn’t catch.
Prompt injection — the threat most teams underestimate
If you understand SQL injection, you understand the concept of prompt injection. An attacker crafts input that causes the model to ignore its instructions and behave in unintended ways. The difference is that SQL injection targets a well-defined syntax. Prompt injection targets natural language — which is inherently ambiguous and far harder to validate.
In an enterprise context, the risk is acute when an LLM has access to internal systems, databases, or APIs. A model that can query your HR system, summarise emails, or raise tickets on behalf of users is a model that — if not properly isolated — can be manipulated into doing those things in ways you didn’t intend. The attack surface is every piece of external content the model processes: documents, emails, web pages, user inputs.
The controls here are architectural. Input sanitisation helps but is not sufficient. The more robust approach is to minimise what the model can actually do — constrain its tool access, require human confirmation for consequential actions, and treat LLM outputs as untrusted data that needs validation before it acts on anything.
Data exposure and the context window
When you give an LLM access to your enterprise data — via retrieval-augmented generation, fine-tuning, or direct context injection — that data becomes part of the model’s reasoning surface. This has implications that most data classification policies haven’t been updated to address.
The specific risks are: data leakage through model outputs (the model surfaces information to a user who shouldn’t have it), data persistence (fine-tuned models may encode sensitive information in their weights), and cross-tenant contamination in shared model deployments.
The controls are a combination of access management — the model should only retrieve data the requesting user is authorised to see — and output filtering, which reviews model responses before they reach the user. Neither is trivial to implement correctly. Both are necessary for any LLM deployment that touches sensitive data.
The supply chain problem
Enterprise AI deployments rarely involve a single model. They typically involve a pipeline — a foundation model from a third party (OpenAI, Anthropic, Mistral, or a cloud provider’s managed service), an orchestration layer, custom tooling, and retrieval systems. Each component in that pipeline has its own security posture, its own update cadence, and its own potential failure modes.
This is a supply chain security problem, and the enterprise security community has been thinking hard about software supply chain security for the last few years. The same principles apply: understand what you’re running, verify its integrity, monitor its behaviour, and have a plan for when something in the chain is compromised.
Model providers update their models. Sometimes those updates change behaviour in ways that affect your application. Do you have a process for evaluating model updates before they reach production? Most organisations don’t — yet.
Regulated environments need a different conversation
For organisations in financial services, healthcare, or government, the regulatory dimension adds another layer. The FCA, ICO, and sector-specific regulators are increasingly focused on algorithmic accountability — the ability to explain why a system produced a particular output. LLMs are, by their nature, difficult to explain. The attention mechanism that produces an output is not a decision tree you can audit.
This doesn’t mean LLMs can’t be deployed in regulated environments. It means the use cases need to be chosen carefully, the human oversight model needs to be explicit, and the audit trail needs to be designed in from the start — not retrofitted after a regulator asks the question.
What good looks like
The enterprises deploying AI well in 2026 share some common characteristics. They have a clear AI governance framework that defines acceptable use cases, data handling requirements, and human oversight obligations. They have threat-modelled their AI deployments — not as an afterthought, but before they went to production. They treat their LLM infrastructure as they would any other critical system: with change management, monitoring, incident response, and a defined owner.
They also have an honest conversation about what AI should and shouldn’t do in their environment. The pressure to automate everything is real. The wisdom to deploy selectively is rarer — and more valuable.
Our approach
At Xpress Net, AI security is not a separate practice bolted onto our cloud and security architecture work. It’s part of it. The same principles that govern how we design Zero Trust networks and secure cloud platforms apply to AI workloads: least privilege, defence in depth, monitoring, and explicit governance.
If your organisation is deploying AI and you’re not certain the security architecture is keeping pace, we’d welcome a conversation.