The AI security risk is not a rogue model, but the tools it can reach

As organisations connect AI agents to business systems, attackers can turn untrusted emails, webpages and documents into instructions for privileged actions. Security depends on limiting what models can do, rather than trusting them to behave.

The central security lesson for organisations adopting agentic AI is not that the model must be malicious to cause damage. According to coverage by TechRadar, IBM and Microsoft, the more common risk is that an AI system is placed in front of sensitive tools, then follows untrusted instructions embedded in emails, webpages or documents. Once that happens, a model that simply makes the wrong choice can still trigger data loss, unauthorised actions or service disruption.

That is why the distinction between model behaviour and application authority matters. As the IBM explanation of prompt injection makes clear, attacker-controlled content can cause an LLM to ignore its intended guardrails and act in ways the user never authorised. Microsoft has separately warned that frontier models can pursue goals in unpredictable ways, which is one reason it is developing so-called guardian agents to supervise other systems before harmful actions are taken.

The same principle applies whether a model is described as uncensored or abliterated. Abliteration.ai says abliteration is a process that dampens refusal-related behaviour in open-weight models, but it also stresses that such models still need policy controls enforced by the application. In practical terms, fewer refusals do not amount to more safety. They merely change how the model responds, which is useful only if the surrounding software has strict limits on what the model is allowed to do.

That separation becomes critical when an agent is connected to real infrastructure. TechRadar has warned that AI systems tied into accounting, customer relationship management and similar business platforms can be manipulated through prompt injection if the underlying workflow is too permissive. The problem is not limited to bad answers. It is the chain from untrusted content to privileged action, especially when the toolset includes file access, database queries or external messaging.

Security therefore depends on designing the application so that the model proposes, but does not authorise. A useful workflow is one in which the model can suggest an action in structured form, while the software independently checks whether the user, the resource and the operation are permitted. That approach aligns with Microsoft’s concerns about unreliable agent behaviour and with IBM’s description of prompt injection as a technique that exploits the model’s trust in instructions it should not treat as authoritative.

The risk is heightened by broad-purpose tools. A general shell, for example, can do far more than a document reader needs to do, which is why narrow interfaces are preferable. Likewise, if secrets are loaded into the model’s context, they may appear in the output or be redirected through another tool. This is one reason security guidance increasingly treats sensitive-information disclosure and excessive autonomy as separate but connected hazards rather than as abstract AI safety issues.

Commercial providers are already responding to demand for less restrictive models. Unrestricted.sh markets uncensored coding and chat models without prompt logs, while Outrun offers prepaid API access to a range of models, including uncensored and abliterated ones, through a single key. Those services may be attractive to developers, researchers and teams conducting authorised testing, but they do not change the underlying governance requirement: the application still needs access controls, logging, execution limits and an independent stop mechanism.

That is especially important because prompt injection is not only about stealing secrets. It can also be used to make an agent send messages, alter data or escalate a workflow beyond what the user intended. In systems that combine internal documents with outbound communication, the path from disclosure to exfiltration can be very short. The safest design is one that prevents information from moving from one trust domain to another unless the user has explicitly authorised that transfer.

There is also a resource-management angle. Unchecked agent loops can consume time, compute and API credits long after a human would have stopped the task. In that sense, an AI incident can be financial or operational even when no data is stolen. Budget limits, step caps and request quotas are therefore part of security architecture, not just cost control.

The practical conclusion is straightforward. Organisations can experiment with uncensored or abliterated models, and there may be good reasons to do so. But the system around the model must assume the model will sometimes be wrong, sometimes be manipulated and sometimes be too willing to comply. The right question is not whether the model sounds safe. It is whether the application can prevent a bad model decision from becoming a real-world incident.