Developers have spent decades learning not to trust user input.

If a website asks for an email address, we don't simply assume someone will enter an email address. The application checks the input, limits what can be submitted, and makes sure unexpected data cannot accidentally become a command somewhere else in the system.

AI makes that principle much harder to apply.

A chatbot cannot simply reject everything that doesn't match a predefined format. The entire point is that people can type almost anything. They can ask questions, paste documents, change subjects halfway through a conversation, write in different languages, or deliberately try to confuse the system.

The AI then has to interpret what all of that means.

That creates a much larger attack surface than a traditional input field. Suddenly the application isn't only processing data. Part of the system is trying to understand the user's intention.

For a simple chatbot that only answers general questions, the consequences may be limited. But once that same chatbot can access customer information, internal documents, APIs, or administrative tools, unexpected input becomes much more interesting.

The oldest rule in web security still applies: never trust user input.

AI just made the input considerably more creative.

You've probably seen screenshots where someone tells an AI to "ignore all previous instructions" and convinces it to say something ridiculous.

It looks like a party trick. In the wrong application, it can become a security problem.

This type of attack is generally known as prompt injection. Instead of attacking traditional application code directly, someone tries to manipulate the instructions an AI model is following.

Imagine a support assistant that can search private company documentation. Its instructions might say that certain information should never be shown to customers. An attacker can still deliberately construct prompts designed to make the model reveal information, reinterpret its instructions, or use its available tools in unexpected ways.

There is also indirect prompt injection. Malicious instructions can be hidden inside content the AI is asked to process, such as a webpage, document, email, or database entry. The user doesn't even need to type the malicious instruction themselves.

That is what makes the problem unusual.

With traditional software, we can often define fairly strict boundaries between instructions and data. Large language models are designed to interpret both as language.

So telling the model "never reveal this" isn't enough.

Security boundaries need to exist outside the prompt too.

There is an important difference between an AI that can say something and an AI that can do something.

A basic chatbot might receive a question and generate an answer. If it behaves strangely, the result could be embarrassing or inaccurate, but its ability to cause damage is relatively limited.

AI agents change that equation.

Modern AI systems can be connected to tools that search databases, send emails, create support tickets, modify accounts, retrieve orders, generate refunds, update records, or communicate with other software.

Now a successful manipulation isn't just about making the chatbot say something funny.

It could potentially make something happen.

This is why permissions become incredibly important. An AI assistant should not automatically receive broad access simply because that access makes development easier. If it only needs to retrieve order status, it probably shouldn't also have permission to modify orders.

More importantly, critical actions should still be validated by normal application logic. The AI can suggest that a refund should happen, for example, but your backend should independently determine whether that user is authenticated and actually eligible for one.

Treat AI as a decision-making assistant, not as your security layer.

The more your AI can do, the less you should trust it.

Companies often focus on what their AI assistant is allowed to say.

A better question is what information it was allowed to receive in the first place.

Imagine an AI assistant that helps logged-in customers find invoices. When someone asks for an invoice, your application retrieves relevant information and gives it to the model so it can formulate an answer.

The dangerous shortcut is retrieving too much.

If the application gives the AI access to invoices from multiple customers and relies on a prompt saying "only show invoices belonging to the current user," the security boundary exists mainly as an instruction written in natural language.

That's not where authorization belongs.

The application should determine which records the authenticated user is allowed to access before anything reaches the model. If the customer can access three invoices, the AI should receive those three invoices, not three thousand invoices plus an instruction to behave itself.

The same principle applies to internal documents, customer records, emails, support conversations, and other private information.

This is especially important with systems using retrieval-augmented generation, often called RAG, where relevant documents are automatically retrieved before an AI generates its response.

The safest secret is still the one the AI never received.

AI introduces some genuinely new security problems, but many of the solutions are surprisingly old-fashioned.

Authenticate users properly. Check authorization on the server. Validate important actions. Limit permissions. Keep sensitive information away from systems that don't need it. Rate-limit expensive endpoints. Log unusual activity. Keep dependencies updated. Assume user input can be malicious.

In other words, good AI security starts with good software engineering.

The mistake is treating the language model as an authority because it appears intelligent. An LLM can interpret language and make useful decisions, but it should not decide whether someone is allowed to access a customer record or whether an administrative action is authorized.

Those decisions belong in deterministic application code where rules can actually be enforced.

There is also a useful principle from traditional security called least privilege: every part of a system should receive only the access it genuinely needs.

That principle becomes even more valuable with AI.

Give your assistant the minimum data, minimum tools, and minimum permissions required to complete its job. Then assume that someone will eventually try to make it use those capabilities in a way you didn't expect.

Because someone probably will.

What makes AI security interesting to me is how easy it is to forget that we're still dealing with software.

A chatbot talks like a person. It understands badly written questions, remembers context, explains itself, and sometimes even apologizes when it gets something wrong. That makes it surprisingly easy to start trusting it like a person too.

But underneath that friendly chat window is an application processing completely unpredictable user input.

I think the safest way to build AI into websites is therefore slightly boring: don't trust it.

Let AI understand the messy human stuff. Let it search, summarize, suggest, and assist. But keep authentication, permissions, sensitive data access, and important actions behind normal application logic that doesn't care how persuasive the chatbot sounds.

AI can be the smartest part of your application.

It just shouldn't be the part holding the keys.