For Hackers, AI Has Turned the Clock Back to the 1990s

In the early days of the internet, a website was an open book. Nothing was encrypted, few pages asked for a password, and anyone curious enough could poke around wherever they liked. Over two decades, logins, administrator privileges, and security guardrails gradually closed that door.

According to Marcin Szczepka, Senior Software Engineer at Softability, AI chatbots have quietly reopened it.

“For hackers, it’s the 90s again. Everything is open. They can play around with chatbots and get them to do, technically, whatever they want.”

Marcin works in R&D, builds AI tools for his own development work, and follows closely how attackers break them. What he sees there matters for every company building with AI. Every chatbot, connector, and AI-assisted workflow is a new way in, and getting through often takes nothing more than the right words. Keeping it safe comes down to control: what the AI can reach, what it reads, what it costs and what people hand over to it.

1. Assume your chatbot will be tricked, and limit what it can reach

The most common attack is called prompt injection. The attacker writes a message that tricks the chatbot into ignoring its rules. Simply asking for an administrator password won’t work. But most chatbots run on one of the big AI models, and each has known weak spots. An attacker who knows which model a company uses also knows which tricks are likely to work.

Injection doesn’t even have to happen in the chat window. Anything the AI reads can carry instructions: a web page, a LinkedIn profile, a CV with a line of white text that no human recruiter will ever see.

“Every time an AI provider releases a new model, someone in the audience asks when they’re going to fix prompt injection and jailbreaks. And there’s no answer. They can only patch the methods they already know about, and there are more ways to attack AI now than before.”

Since attacks can’t be reliably prevented, the defense is to limit the damage when one succeeds. Everything the chatbot has access to is at risk. Marcin’s advice is the approach security people call least privilege: start with no access at all and add permissions one by one until the AI can do its job.

“For example, a company might give the chatbot read access to the whole database. Maybe the passwords aren’t there, but the usernames and email addresses of all your other customers are. If it’s an FAQ bot, it should only see the FAQ.”

AI can help here too. Show it your design and ask it to look for weaknesses, and it will point out many of the obvious gaps. A person still has to review what it finds, and the deep, unknown vulnerabilities are harder. The easy ones, however, should always be closed, because someone will eventually find them.

2. Watch your bill: attacks can target your wallet

Most people know the denial-of-service attack, where a website is flooded with traffic until nobody can use it. AI has a cousin of this: denial of wallet. A company that builds its own chatbot usually pays the AI provider for every message it processes. An attacker can spam the chatbot with requests or trap it in an endless loop, and every message adds to the bill.

Marcin recalls a YouTuber, Kitboga, who makes a hobby of wasting phone scammers’ time. When he noticed that the scammer calling him was an AI, he got it stuck repeating itself, put the phone down and let it run. The bill went to the scammers. The same trick can be turned against a company’s chatbot.

Why would anyone bother? “For fun,” Marcin says. Or because they dislike the company. In gaming, for example, some big brands face organized attacks almost daily.

The attack can go unnoticed because a rising AI bill is easy to read as good news.

“The bill is a bit higher than expected, and it’s easy to think: great, there must be a lot of interest in our service.”

Protection starts with assuming this can happen to you. “If you don’t think about it, someone will do it, even just for fun.” Typical safeguards are limits on how many messages one user can send, how long a single conversation can run, and how much the service can cost per day.

3. Everything you type into a chatbot is stored

Consumer versions of services like ChatGPT, Gemini and Copilot store everything you write and upload, including photos. Depending on the service and your settings, that material may be used to train future models. It can also be requested by courts and authorities, particularly in the country where the provider is based. In 2025, a US court ordered OpenAI to preserve users’ ChatGPT conversations, including deleted ones.

People share a great deal with chatbots, including things they would never write in an email. Marcin can imagine situations, such as a divorce case, where that data surfaces somewhere nobody expected, although he hasn’t seen it happen yet.

“If you use your company’s Copilot subscription to write your CV and a cover letter, it’s stored in company systems. Everything you write in the company chatbot belongs to the company.”

Technically, adding monitoring to a company chatbot is, in Marcin’s words, “just a matter of changing the chatbot’s instructions and giving it a few extra tools.” In Finland, how employers may use that data is regulated, and employees must be told about monitoring. Marcin’s advice is still simple: don’t write anything in the company AI that you wouldn’t want your employer to read.

Employees can also put company and customer data at risk. The risk is highest in companies without an official AI tool, where people turn to public ones. In 2023, Samsung banned public AI tools after engineers pasted source code into ChatGPT. In 2026, even the acting head of the US cybersecurity agency was reported to have uploaded internal government documents to the public version of ChatGPT. Small things count too. Asking a public chatbot to help with a blog post that mentions a colleague by name means sending personal data to a third party, which raises GDPR questions.

A company-provided AI keeps the data inside contractual guardrails, with promises not to use it for training and not to let it leave.

“Those promises exist, but they are promises. It’s software like everything else, and software has bugs.”

In Marcin’s view, you can go crazy about privacy, or you can accept that some things simply don’t belong in a chatbot. For work that must stay truly private, such as his own side project, he runs AI on his own hardware at home.

4. Give AI access on your terms

Companies can also connect AI to their own systems.

One way is a standard called the Model Context Protocol, or MCP. It lets a company give AI access to its own systems through clearly defined tools. Each tool has a name and a plain-language description of what it does and what it needs. The AI reads the list, picks the tool that matches the request and can only ask for the operations that tool offers.

“What I like about it is how human it is. The AI basically asks: what can I do? I have these options, and this one does that. Traditional programming interfaces are often cryptic and the documentation is out of date. Here everything is written out, because the AI needs it.”

Building one is quick. You can ask AI to build the connector, called an MCP server, for a tool your company already uses, then go through the operations it offers and remove the ones it shouldn’t have. An internal assistant can be given broader rights; a public-facing one gets a much tighter set of permissions. In his own R&D work, Marcin has built a tool that lets the AI in his coding environment run commands on a real device when he asks it to.

Defining the tools yourself also shows you clearly what you are handing over to the public. What really limits the tool is the permissions it runs with, and code generated by AI needs a human review before it goes live. MCP isn’t meant to replace ordinary integrations between systems, which are faster and lighter. It is built for one job: giving AI the context it needs.

5. Give the AI your manuals before it answers

AI makes things up when it doesn’t know. The architecture known as RAG – retrieval-augmented generation – reduces this. Before the AI answers, the system looks up the right information in sources you trust and gives it to the AI together with the question. Many public AI services likely do this already, for example, when they check map reviews to recommend a restaurant.

A company can do the same with its own product documentation and manuals.

“Someone asks how to do a factory reset. The AI has the manual, so it doesn’t have to guess. It gives the answer and can even tell the user where in the manual to find it.”

RAG reduces errors but doesn’t remove them, which is why the source reference matters. A customer service agent or engineer can check the answer against the source. The material also needs vetting: a document can carry hidden instructions just like the CV in the first section. Without RAG, the work falls back on the user, who has to give the AI the right material and check the result. A RAG solution can be built in-house or bought.

Your people are your best firewall

Every risk discussed becomes easier to manage once people know about it. “Both the company and its people need to be aware,” Marcin says. A team that understands the risks is far less likely to click the wrong link or plug in a random USB stick.

Many smaller companies have had no AI training at all, not even for leadership. Building that knowledge is the employer’s job. Our colleague Kim Meyer writes more about training and AI governance in Building Secure R&D with AI.

Until training is in place, anyone can ask the AI itself what could go wrong with a solution. It makes a useful first check.

“AI is very good at helping you build something. It’s much less likely to tell you why you shouldn’t.”