AI security covers two related problems:
- Securing AI systems: protecting the models, data and applications you build or use from being attacked, manipulated or misused.
- Securing the organisation from AI risks: controlling how AI changes your exposure, from staff pasting secrets into chatbots to attackers using AI against you.
Traditional security still applies to AI: access control, patching and logging all matter. But AI adds new attack surfaces that classic controls weren’t designed for.
Why AI is different to secure
- Instructions and data are mixed. A language model reads everything as potential instructions, so text hidden in an email or web page can change what it does. That’s prompt injection.
- Behaviour isn’t fully predictable. The same input can produce different outputs, and models can be talked out of their rules. That’s jailbreaking.
- Training data shapes behaviour. If attackers influence the data, they influence the model. That’s data poisoning.
- AI is increasingly given access and actions. Agents can read files, send emails and call APIs, so a manipulated agent can do real damage. See AI agent security.
The main AI security risks
Prompt injection
Crafted input, direct or hidden in content the AI reads, that overrides the system’s instructions. It’s widely considered the number one risk for applications built on large language models.
Sensitive data disclosure
AI systems revealing personal data, confidential business information, system prompts or secrets, and users leaking data into AI tools. See AI chatbot data leakage.
Insecure output handling
Treating AI output as trusted and passing it straight into code, databases, browsers or other systems, which can lead to classic attacks like cross-site scripting or command injection.
Excessive agency
Giving an AI system more permissions, tools or autonomy than it needs, so a mistake or manipulation turns into real-world damage.
Supply chain risks
Compromised models, datasets, plugins or software packages. See AI supply chain risks.
Data and model poisoning
Manipulating training or fine-tuning data to plant backdoors or biases.
Misinformation and overreliance
Confident but false output, sometimes called hallucination, that people act on without checking.
Shadow AI
Staff using unapproved AI tools outside security’s view. See shadow AI.
The OWASP Top 10 for LLM Applications is the best-known list of these risks and a good map for security teams.
First controls to put in place
- Know your AI. Build an AI inventory, including SaaS AI features and shadow AI.
- Set data rules. An AI acceptable use policy that bans pasting secrets, personal data and client confidential data into unapproved tools.
- Use business-grade tools with clear data protection terms, single sign-on and admin controls.
- Limit what AI can do. Least privilege for AI agents and integrations, with human approval for high-impact actions.
- Treat AI output as untrusted input. Validate and sanitise it before it touches other systems.
- Test before launch. Red-team customer-facing AI for prompt injection, data leaks and unsafe answers.
- Log and monitor prompts, outputs and actions where appropriate and lawful, so you can investigate incidents.
AI security and AI governance
The two overlap. AI governance decides what AI you use and who’s accountable. AI security makes sure those systems can’t be turned against you. The EU AI Act also requires high-risk AI systems to have appropriate accuracy, robustness and cybersecurity, so security is part of compliance too.
Official sources
- OWASP Top 10 for LLM Applications: the OWASP GenAI Security Project’s list of the main LLM risks
- MITRE ATLAS: a knowledge base of real attack techniques against AI systems
- NIST AI 100-2 E2025, Adversarial Machine Learning: NIST’s taxonomy of attacks on AI systems and their mitigations
More primary sources, with a short note on each, are on our Sources page.
Last reviewed October 2026. This article is general information.