Itwerx is a service-disabled veteran-owned managed IT and cybersecurity provider serving businesses in Seattle, Bellevue, Everett, Lynnwood and Snohomish County, founded in 2005, and part of that work is helping clients evaluate AI tools before sensitive data goes anywhere near them.
The limitation is not a bug. It is the design.
Ask why AI vendors with enormous funding and very smart engineers have not simply solved AI security, and the honest answer is that the thing being asked for is not achievable for a large language model specifically, no matter how much money or talent is applied to it. The problem sits in the name: “language.”
An LLM is only useful because it accepts open-ended input and produces output shaped by it. The more open that input channel is, the better and more relevant the output can be. Security works in the opposite direction: it restricts what is allowed through. Those two goals trade directly against each other inside the same system. Think of the model as a sieve – inputs go in the top, what the model already “knows” shapes what comes out the bottom, and the only ways to control that are filtering the input, filtering the output, or both.
That would be a solvable engineering problem if language had a fixed, enumerable set of “bad” phrasings to catch. It does not. There are effectively unlimited ways to say the same thing, which means any filter tight enough to catch every harmful phrasing will also catch a share of legitimate ones, and the model gets less useful in exact proportion to how secure the filtering tries to make it. No set of operating instructions, however carefully written, escapes that tradeoff, because the tradeoff is a property of language itself, not of any particular rule set.
Why nobody can just patch this from the inside
There is a second, quieter problem underneath the first: once a large model has been trained, no one, including the people who built it, can fully trace every path between a given input and the output it produces. The tools that exist today are tools for creating LLMs, not tools for exhaustively understanding a specific one after training. Until that changes, “just write better rules” runs into a system whose internal behavior cannot be fully mapped, on top of a language problem that admits no complete filter in the first place. Both limits point the same direction: the LLM itself cannot be made 100% secure by anything built into it.
What actually helps: controls built around the model, not into it
None of this is an argument that AI security work is pointless. It is an argument for where that work has to live. If the model’s internal filtering can never reach 100%, the answer is not to keep tightening it until the product stops being useful. The answer is external controls that do not depend on the model getting every judgment call right: isolating what data a given deployment can reach in the first place, restricting access to trusted users rather than the open internet, monitoring what goes in and out independently of the model’s own behavior, and keeping the most sensitive workloads off a shared, general-purpose assistant entirely. That is also the reason an entire industry of AI security tooling exists rather than being unnecessary noise – it is not competing with the model to fix an unfixable problem, it is building the fence around a system that was never going to fence itself.
The practical takeaway for a business evaluating an AI deployment is to ask a different question than “is this model secure.” Ask instead what it can reach, who can reach it, and what is watching it from the outside – because those are the questions that actually have answers.
Itwerx Corp is a service-disabled veteran-owned small business providing IT services across Seattle, Bellevue, Everett and Snohomish County. This is the kind of thing our AI integration work deals with – talk to us about yours.
