What Is AI Security and Why Is It Different From Traditional Cyber Security?
Every organisation that has deployed an AI system has also taken on a new class of risk. The firewalls, vulnerability scanners, and penetration testing methodologies that underpin most security programmes were designed for a world of deterministic software, fixed logic, and static code. An AI system is none of those things. Its behaviour emerges from statistical patterns in training data, it responds to natural language, and it can be manipulated through the very inputs it is designed to accept.
AI security is the discipline that addresses those risks. It is not a subset of application security, though it overlaps with it. It is not purely a data science concern, though it draws on that field. It is a distinct practice with its own threat models, testing techniques, and governance requirements. Understanding what makes it different is the first step to taking it seriously.
The Attack Surface Is Fundamentally Different
Traditional application security focuses on things like authentication flaws, injection vulnerabilities in SQL or OS commands, insecure deserialisation, and misconfigured access controls. These are meaningful concerns for AI systems too, but they sit in the scaffolding around the model, not in the model itself. The model introduces attack surfaces that have no equivalent in conventional software.
A language model accepts natural language as input and produces natural language as output. That means an attacker does not need to find a buffer overflow or bypass a firewall. They need to craft text that causes the model to behave in ways the developer did not intend. The input is expressive, the behaviour is probabilistic, and there is no patch that definitively closes the attack surface the way a code fix closes a SQL injection vulnerability.
The Threat Models Are Different
In traditional security, the primary concern is an attacker gaining access to systems or data they should not be able to reach. AI security introduces threat models that look quite different. An attacker might manipulate a model's outputs to spread misinformation, extract sensitive training data without ever breaching a database, or exploit an AI agent's tool-use capabilities to take actions on behalf of the attacker in connected systems.
There are also threats that originate before the system is deployed. Dataset poisoning involves manipulating the data used to train or fine-tune a model so that it behaves predictably badly in certain conditions. Model supply chain attacks target pre-trained weights distributed through public repositories. These are not threats that a traditional penetration test, focused on running infrastructure, would identify.
Testing Requires Different Methods
Automated vulnerability scanning works by matching known signatures against known conditions. It works well for traditional software because the vulnerabilities are relatively well-categorised and the system behaviour is deterministic. AI systems are neither. Testing an LLM application requires adversarial prompting techniques, red-teaming against specific behaviours, and evaluation of outputs across a wide range of inputs that probe edge cases in model behaviour.
At Cyberlinx, our AI security assessments cover six layers: dataset integrity, model behaviour, scaffolding and integration security, governance controls, exploitability under adversarial conditions, and privacy risks including training data extraction. No single tool covers all of that. It requires a combination of automated probing, manual adversarial testing, and governance review. The result is a very different kind of report than a traditional penetration test produces.
Governance and Frameworks Are Still Catching Up
The governance landscape for AI security is developing quickly. Internationally, the NIST AI Risk Management Framework provides a structured approach to AI risk. ISO 42001 establishes requirements for an AI management system. In Australia, APRA has written to regulated entities about AI risk, and the government has published a Voluntary AI Safety Standard that sets out expectations for responsible AI deployment.
What these frameworks share is an acknowledgement that AI risk cannot be addressed by bolting AI systems onto existing IT governance processes without modification. The risk categories are different, the assurance mechanisms are different, and the accountability structures need to reflect the way AI systems are built, deployed, and monitored. Organisations that treat AI security as just another item on a traditional IT audit checklist will consistently miss the risks that matter most.
- AI systems are probabilistic, not deterministic -- the same input can produce different outputs
- The primary attack surfaces include the model, training data, prompts, and orchestration layer
- Adversarial testing techniques are fundamentally different from traditional vulnerability scanning
- Governance frameworks like ISO 42001 and NIST AI RMF address AI-specific risk categories
- Australia's regulatory context is evolving, with APRA and the Voluntary AI Safety Standard setting expectations
If your organisation is deploying AI systems and you are not sure how to assess the security implications, we can help. Cyberlinx brings hands-on AI security assessment capability to Australian organisations. Contact us at info@cyberlinx.com.au to talk through your situation.
Related Articles







