AI security has become a much bigger topic than “is the chatbot giving safe answers?”
Modern AI systems can read documents, search knowledge bases, call tools, write code, access business data and, in some cases, take actions on behalf of a user. Once AI is connected to real data and real systems, its security becomes part of normal cybersecurity.
That is the simplest way I think about it: AI security is the work of protecting AI systems, the data around them, and the people and systems that depend on their decisions or actions.
It includes familiar security problems such as access control, secrets management and software vulnerabilities. It also includes problems that are much more specific to generative AI, such as prompt injection, unsafe model outputs and agent hijacking.
In 2026, this is no longer a niche concern. NIST has an AI Risk Management Framework and a Generative AI Profile, while OWASP now maintains dedicated security guidance for LLM applications and agentic AI systems.
What are we actually trying to protect?
An AI application is usually more than a model. A real system may include a web application, an API, a model provider, a vector database, files, user accounts, plug-ins or tools, logging systems and other services.
That means there are several things worth protecting.
1. The data
AI systems may process personal information, company documents, source code, financial records, support tickets, credentials or other sensitive material.
A security problem can happen when sensitive data is sent to a model unnecessarily, stored in the wrong place, exposed through logs, retrieved by the wrong user or included in an output that should never have contained it.
Data minimisation matters here. If the model does not need a piece of sensitive information to complete the task, there is a good argument for not sending it at all.
2. The instructions and context
Generative AI systems work with instructions and data in the same general context. That creates a new attack surface.
A malicious input can try to change how a model behaves. This is the idea behind prompt injection. The attack may come directly from a user, or indirectly from a document, webpage, email or other content that the AI system reads.
I have a separate guide on prompt injection and how to reduce the risk.
3. The tools and permissions
The risk becomes more serious when an AI system can do more than generate text.
Imagine an agent that can read email, create files, run code, update a database or send a message. A wrong answer is inconvenient. A wrong action can be a security incident.
This is why least privilege is so important for AI agents. An agent should have only the access it genuinely needs, for only as long as it needs it.
4. The model and AI supply chain
AI applications depend on models, datasets, libraries, APIs, embeddings, third-party services and sometimes externally supplied tools.
Traditional supply-chain security still applies. Teams need to know what they are using, where it came from, what permissions it has and how updates are managed.
AI also introduces risks around poisoned data, manipulated model behaviour and compromised components in the AI pipeline.
5. The people relying on the system
A technically secure application can still create risk if people trust its output too much.
Models can produce incorrect information. An AI-generated answer can sound confident even when it is wrong. That matters when the result affects security decisions, finance, health, legal work, software changes or other high-impact tasks.
Security therefore includes designing the human workflow around the AI, not just protecting the model endpoint.
The main AI security risks to understand
There is no single list that describes every AI security problem, but a few themes appear repeatedly in current NIST and OWASP guidance.
Prompt injection
An attacker places instructions in content that reaches the model and tries to override or redirect its intended behaviour.
Prompt injection is especially important when AI systems read untrusted external content or can use tools.
Sensitive information exposure
The application may disclose personal data, credentials, confidential business information or other material through prompts, retrieved context, logs or model output.
This is one reason I strongly prefer masking or removing unnecessary sensitive data before it reaches an AI system.
Too much agency
An AI system can become dangerous when it has broad permissions and can take actions without enough checks.
The safer approach is usually to give the agent narrow permissions, restrict the tools it can use and require human approval for sensitive or irreversible actions.
Unsafe output handling
AI output should be treated as untrusted data.
For example, an application should not automatically execute generated code, database queries or system commands simply because they came from a model. Normal validation and security controls still apply.
Data and model poisoning
If attackers can influence training data, fine-tuning data, retrieved knowledge or other trusted sources, they may be able to change system behaviour.
The exact risk depends heavily on how the AI system is built, but source integrity and data governance matter.
Identity and access problems
An AI agent may act using a service account, API token or user’s delegated access. If that identity has excessive privileges, any model mistake or successful attack can have a much larger impact.
AI does not remove the need for good identity security. It makes it more important.
AI security is still cybersecurity
It is easy to treat AI security as a completely separate field. I do not think that is useful.
A secure AI system still needs strong foundations:
- authentication and authorisation
- least privilege
- secure software development
- secrets management
- logging and monitoring
- dependency and supply-chain security
- network and cloud security
- data classification
- incident response
- backup and recovery
The AI-specific controls sit on top of these foundations.
If the web application has broken access control, protecting the prompt will not fix it. If an API key is hardcoded in a public repository, an AI guardrail will not fix that either.
A practical way to secure an AI application
For a real project, I would start with a few questions.
What data can enter the system?
List the sources: user prompts, uploaded files, databases, websites, email, internal documents and third-party APIs.
Then classify which sources are trusted, untrusted or sensitive.
What can the AI do?
There is a major difference between an assistant that drafts text and an agent that can send email or change production data.
Write down every tool and permission available to the AI. Remove anything it does not need.
What happens before data reaches the model?
This is a good place for controls such as data minimisation, secret detection, PII masking, file validation and policy checks.
The safest sensitive value is often the one that never enters the model context.
What happens after the model responds?
Validate important outputs before another system uses them.
If the model proposes a security rule, command, transaction or code change, the application should not assume it is correct just because the output looks convincing.
Which actions need a human?
Human approval is valuable for actions that are expensive, destructive, external-facing or difficult to reverse.
A confirmation step may feel less “autonomous”, but autonomy is not automatically a security benefit.
Can you see what happened?
Good logs should record useful security events without leaking secrets.
Teams need enough visibility to answer questions such as: What input reached the agent? Which tool did it call? What identity was used? What action was attempted? Was it blocked or approved?
What normal users should do
You do not need to be an AI engineer to practise basic AI security.
A few habits make a real difference:
- Do not paste passwords, private keys or API keys into a chatbot.
- Avoid sharing sensitive personal or business data unless it is genuinely required and the service is approved for that use.
- Check the data-handling terms and settings of the product you are using.
- Verify important AI-generated information before acting on it.
- Be careful when an AI system asks for broad account permissions or access to files.
- Treat AI-generated code and commands as suggestions that still need review.
I cover the data side in more detail in how to protect sensitive data, API keys and credentials when using AI tools.
Where AI security is heading
The interesting change is that AI is moving from answering to acting.
That changes the security question from “Can the model say something unsafe?” to “Can the system do something it should not do?”
As agentic systems become more common, identity, tool permissions, external content, memory, auditability and human approval will become even more important.
That is why AI agent security deserves to be treated as its own design problem.
AI security is still developing quickly, and no framework can remove every risk. But the basic direction is already clear: keep privileges narrow, keep sensitive data under control, assume model inputs and outputs can be manipulated, and build normal cybersecurity controls around the AI rather than trusting the model to secure itself.