What happened to McDonald's with AI bots and how businesses can avoid repeating these mistakes

McDonald's had not just one emergency with AI, but two different stories. They are often mixed up, and because of this, an article about security can easily turn into a bunch of general words. In fact, everything is simpler.

The first story was in restaurants. In June 2024 AP News wrote that McDonald's is ending its voice order test with IBM. This was the same AI in drive-thru that took the order instead of an employee. According to AP and Restaurant Business, the pilot has been running since 2021, and the network has accumulated many examples where the system confused the order, added unnecessary things and simply did not understand people.

The second story was not about orders, but about hiring. In July 2025 WIRED reported on the issue on McHire's website, where chatbot Olivia interacted with job seekers. Researchers found a password that was too simple 123456, logged into a test account and, through a vulnerability in the API, were able to view chat records. Then Paradox has released its analysis. The company confirmed both the old password and the problem in the endpoint. At the same time, she clarified that the researchers themselves looked at seven records, five of which contained personal data.

These are two different situations. In the first, the AI ​​did a poor job of the task. In the second, the system missed a very common, almost everyday security hole.

What exactly happened in each case

The drive-thru story is quite simple. McDonald's tested IBM's voice assistant at self-service locations. The idea was clear: speed up order processing and relieve employees. But in practice the system was wrong. AP News gives examples from viral videos. Somewhere a bot added extra nuggets to the order. Somewhere I collected strange combinations like ice cream with ketchup and butter. Somewhere he was generally reacting to voices from another car. McDonald's did not directly say that the problem was precisely the recognition accuracy, but the company stopped the pilot with IBM.

With McHire it was all about safety. WIRED describes how the researchers started a regular job application, then tried to guess the password to the admin account and found test access. After that, they noticed a problem in the API: if you change request IDs, you can see someone else’s data. Paradox in the official update writes that this test account has not been used since 2019, the password on it has not been updated, and the vulnerability was closed within a few hours after notification.

And here is an important point. McDonald's didn't have one mysterious "crazy chatbot" story. There were two very mundane problems:

• the bot may not work well and irritate customers;
• a service with a bot may store and protect data worse than it should.

Why this story is useful for business

Usually, when they talk about AI bots, they discuss prompts, scripts and “how to make it smarter.” And McDonald's shows that the problem area is often not there at all.

In the drive-thru story, it was not the safety that let us down, but the quality of the product. The system did not hear people as it should. For business, this means direct losses: longer service, more errors, more irritation, more manual corrections.

In the story with McHire, it was not the bot’s intelligence that failed, but basic hygiene. No complex attack was needed. Essentially, it all started with an old account and a weak password, and then an error occurred in the API. This is an unpleasant reminder: a vulnerability around an AI service often turns out not to be a “magical AI threat”, but an ordinary hole that would be dangerous without any model.

What conclusions should be drawn from this?

The first conclusion: there is no need to name any problem around AI with a word prompt injection. In the case of McDonald's, this would simply be inaccurate. The story with orders was about poor recognition and poor user experience. The McHire story was about access control and APIs.

Second conclusion: guardrails for an AI bot do not start with a beautiful system prompt. They start with what the bot can and shouldn’t do.

And one more conclusion. If the bot works with people, applications, resumes, contacts, payments or internal tools, it should be treated as a normal part of the working system. Not like a cute add-on that you can later “add on.”

What you need to check if you already have an AI bot

The easiest and most useful way to look at your project is to split the review into two parts.

1. Does the bot even cope with its task?

If the bot is talking to a client, you need to check the basic things:

• does he understand the requests correctly?
• whether the scripts are confusing;
• whether he answers too confidently where he does not know the answer;
• knows how to call a person when he is stuck.

McDonald's had a problem with drive-thru here. The bot seemed to perform an understandable function, but did not do it reliably enough.

2. Is the service itself secure around the bot?

This is where the McHire-level story begins. Very simple checks are needed:

• are there any old test accounts;
• is MFA enabled for admins?
• who has access to logs and chats;
• Is it possible to pull out other people’s records via ID, query parameters or export;
• whether the bot stores more personal data than it really needs.

These are boring questions. But they are the ones who most often save from real incidents.

Where are prompt injection and guardrails?

Topic prompt injection You still can't throw it away. You just don’t need to attract it to a case where it is not proven. OWASP writesthat prompt injection occurs when external input changes the behavior of the model in a way that is not intended, and can lead to data leakage, dangerous behavior, or bypassing restrictions. OpenAI in material about agent protection makes an important emphasis: you cannot rely only on a filter of harmful phrases; you need to build the architecture so that even successful manipulation does not lead to big trouble.

Simply put, guardrails are not for beauty. They are needed for the bot to:

• had no extra rights;
• did not pull out sensitive data without reason;
• did not perform dangerous actions silently;
• I was not left alone with a difficult case where a person was needed.

What should be implemented first?

If you already have an AI bot in recruiting, support or sales, I would start with the most practical one.

First, limit powers. A bot should not have access to everything at once.

Secondly, separate untrusted and trusted content. Anything that comes from the user, from an email, a file, a form, or an external page should be considered potentially dangerous input.

Thirdly, set up a clear handoff for the person. A good bot doesn’t act like a hero until the end, but passes the conversation on in a timely manner.

Fourth, put things in order in the technical base: old accounts, tokens, test environments, access to logs, export of chats.

Fifth, separately check all the places where the bot does something on behalf of the company: writes to CRM, sends letters, changes the status of an application, gives a discount, creates a task.

What metrics are really useful here?

With such systems, it is useful to look not only at conversion or CSAT.

More down-to-earth indicators are also needed:

• how many times the bot made a mistake and the conversation had to be saved manually;
• how many dialogues did the person take;
• how quickly the team sees the problem and fixes it;
• are there any attempts to obtain unnecessary data;
• how many really active integrations does the bot have and which of them are the riskiest.

Then the conversation about the safety of AI bots becomes substantive. Not “it seems to us that everything is fine,” but “we see where the system is weak and what has already been corrected.”

If a company needs not just a bot for a website, but a work circuit with logging, restriction of rights and transfer of complex cases to a person, this is more like a task integration of AI into business processesthan for a one-time prompt setup.

Useful on the topic

• Google AI Mode and query fan-out: why one strong page is no longer enough for SEO
• How to get into ChatGPT answers: GEO and AI SEO
• Case on the topic
• Profile service

FAQ

So what happened at McDonald's?
There were two different stories. First, McDonald's stopped its voice order pilot with IBM after noticeable errors in the system. Second, a weak password and API vulnerability were found on the McHire platform, which allowed researchers to gain access to some of the applicants’ data.

Was this prompt injection?
There was no publicly confirmed prompt injection in these stories. The McHire story was about an old password and an API. The story with drive-thru is about the poor performance of voice AI.

What is the main conclusion for business?
Don’t expect the AI project to “settle down on its own.” You need to separately check the quality of the bot’s work and separately check the security of the service around it.