The day my AI agent created a project in Russian (and why it was not a hack)

Monday, 6:41 in the evening. I open one of our internal systems and, among the usual projects, there is a new one.

It is called «Пунка?».

Just like that, in Cyrillic, with a question mark. Description: three dots. Zero content. Nobody on the team created it.

The first reaction is not technical, it is physical: your stomach tightens. A Russian name that nobody typed, inside a system that only we use. Anyone who has read two cybersecurity news stories knows how that story ends: stolen credentials, someone inside, and the question no business owner wants to ask: what else did they touch?

This article tells what really happened. To get ahead of it: there was no hacker. There was something that is happening right now in thousands of companies that already use artificial intelligence agents, and that almost nobody is checking.

First, rule out the worst

Faced with something like this, the temptation is to panic or, worse, delete the project and carry on as if nothing happened. Both are bad ideas. The right move is to treat it as what it looks like, a possible security incident, and answer four questions with evidence, not intuition:

And the final piece: in that agent's history was, word for word, the instruction it executed itself. Create project. Name: «Пунка?». Description: «...».

Verdict within minutes: there was no breach. Nobody got in. One of our own agents did it, with a legitimate key, from the inside.

We breathed. And then we realized that this was almost worse.

Because an intruder is an external problem: you shut the door and change the locks. An agent of your own that makes things up with write permission is a design problem, and it lives inside every day.

The chain: how a small error becomes permanent junk

None of this was a single failure. It was a chain of seven links, and each one, on its own, looked harmless.

1. A weekly job that ran six times. The agent had a task scheduled once a week: preparing the visual campaign. That Monday it ran six times, once automatically and five more times that nobody remembers launching. The incident happened on the fifth.

2. The model we asked for was not the one that worked. The task was configured to use a large, capable AI model. That run started with a different one.

3. The fallback was never going to work. The alternate model was outside the plan contracted with the provider. It was not a matter of balance: that model had never been included. It was always going to fail, and nobody had tested it.

4. The silent switch. When the fallback failed, the system did what it was configured to do: look for another model, a smaller and cheaper one. Nobody chose it for this task, and the final report did not mention it.

Stop here for a second, because this is the link that matters most. The task was designed and tested with one brain, and another, much smaller one ran it without anyone finding out. It is like hiring an engineer, testing them for weeks, and discovering that on delivery day they sent the intern.

5. The small model gets tangled. The agent's tools are used through an intermediary, and the small model did not know how to use it. Within a few minutes it called tools that were not on its list, misspelled a field name, nested calls inside calls and received three warnings that it was going around in circles.

6. A real tool fails too. In the middle of that chaos, a legitimate query to the team's task board broke because of a technical detail: a file path arrived with an invisible character where it should not have been. A real infrastructure error, and not the model's fault.

7. The invention. And this is where it happened. After reading how the projects tool worked, the model called it with arguments it made up: name «Пунка?», description «...». A second later it did the same with another tool: it tried to write a file to a path that did not exist, with the content «...».

Notice the signature: an ellipsis as a value. The model was not attacking anyone and had no agenda. It was filling in blanks, like a student who does not know the answer and writes anything so the exam is not left empty.

The most unsettling part: it wanted to read, not create

When we reviewed the reasoning the agent had saved, the detail appeared that turns this story into a lesson: the agent never wanted to create anything.

It wanted to look up the project data, the brand's visual identity, to do its job. Asking for the list of projects would have been enough.

But the tool had a design problem: the same function served to read and to create, and the only fields it offered were the creation fields. A small, confused model with an error in the middle saw two empty fields and filled them.

Filling in a form turned a read into a write.

That sentence should be pinned on the wall of every company that is connecting AI to its systems.

"And why in Russian?" The trap of looking for meaning

This is the part everyone asks about, and the answer is disappointing on purpose.

«Пунка» is not even correct Russian: "punk" is spelled differently in Russian. We ran it through an automatic translator and not even the translator agreed with our suspicion: it detected it as Serbian and translated it as "A punk?".

It can be read as "a punk?", as a juvenile insult or as the name of a colonial Indian fan. A word that allows three readings has none: the meaning is supplied by whoever reads it.

At first we suspected a keyboard set to Russian. Not that either: the model emitted the characters directly, with no keyboard involved.

Psychology has a name for this: apophenia, the tendency to see patterns and intentions where there is only noise. A Cyrillic name that sounds like a taunt looks like a hacker's signature or a machine's rebellion. It was neither. It was noise shaped like a word, and the question mark at the end gave away the doubt.

What was really missing was a way out for the model to say "I don't know". It had no way not to make the call, and the design of the tool pushed it to write something.

The delivery: "everything went fine"

The end of the run was what hurt us most. The agent delivered its report as if nothing had happened:

• It claimed to have used a tool it did not use.
• It said a service was free without having checked.
• It included marketing figures with no source at all.
• It invented a color palette that does not belong to any of our brands.
• It worked for the wrong brand that week.
• It did not report that one of its tools had failed, even though its instructions said explicitly: if something failed, say so plainly.

It graded itself 14 out of 15.

The only honest warning in the whole run was not written by the model. It was written by the system that was watching it: "1 file was NOT modified".

The five rules that came out of that Monday

We are not telling this to scare anyone. We are telling it because this pattern, an agent that silently degrades, gets confused, makes things up and reports success, is going to be the most common incident in companies adopting AI over the next few years. And almost all of it is prevented with design decisions, not with more budget.

1. The model that does the work must appear in the delivery. If the task was designed for one model and another one ran it, you need to know. A silent fallback is a blind spot. Better still: in tasks that write data, if the chosen model is not available, the task should stop instead of degrading.

2. Reading and writing cannot be the same tool. Functions that query must be separate from functions that modify. And the ones that modify must validate: a required name, no filler values such as «...» or bare symbols. We fixed it the same day. Today, that same call is rejected as invalid.

3. An infrastructure failure pushes the model to improvise. The invention came right after a real tool failed. When an agent cannot get what it needs, it starts going in circles and making things up. Monitoring tool errors is not optional.

4. Before assuming an attack, follow the evidence. We went from "we were hacked" to "it was our agent" in minutes, because every action left a trail: who called, from where and with what instruction. If your systems do not keep that trail, all you can do after a scare like this is guess.

5. An agent's self-assessment is not a verification. An agent that grades itself 14 out of 15 is telling you nothing. What counts is what gets checked against reality: the database, the file and the live site.

What this means for your company

If your company has already connected, or is about to connect, an AI agent to your email, your CRM, your inventory or your appointment system, ask yourself three questions today:

• Do I know which model is actually working on each task, or only which one I configured?
• Can my agents write to systems where they should only read?
• If tomorrow a record appears that nobody created, can I find out within ten minutes who, when and why?

If any answer is "I don't know", that is no reason to panic. It is a reason to review.

At miscloud we build custom systems, and we design them assuming that AI is going to make mistakes, because it does. The difference is whether the error stays contained, visible and correctable, or buried in a report that says "everything went fine".

Would you like us to review how the agents in your operation are connected? Tell us about your case.