Building software with AI has never been easier. Responding to an attack hasn't. That's the gap almost nobody sees until they need it.

The day we got tested

This afternoon, someone tried to destroy one of the platforms we operate. It wasn't a movie-style attack. It was something far more common — which is exactly why it's worth telling.

The person signed up in the app with a disposable email, like any user. Then they exploited a misconfigured permission rule to grant themselves an admin role. With that access, they started deleting data.

What matters isn't that it happened. It happens to everyone. What matters is what came next.

The method, in plain terms

In modern apps, the database is exposed directly as an API. It's fast and practical. But it means the only barrier between a user and your data is the security rules at the data layer.

When one of those rules has a gap, the attacker doesn't break anything. They use the same door and the same public key your app uses every day. That's why these flaws are so quiet: everything looks normal until it isn't.

It's also the exact kind of gap that slips through when you build at full speed and nobody reviews the security layer.

The uncomfortable question about "vibe coding"

Today you can describe an idea, and an AI hands you a working app in hours. It's genuinely powerful and it's here to stay. We use it every day.

But there's a catch. Building fast gives you something that works. It doesn't give you, by default, something that holds up. Those are two different things.

The real question for anyone shipping products with AI isn't whether their security is perfect. Nobody's is. The question is: when something breaks at 8 p.m., will you be able to respond?

Do you have backups that can actually restore your data?
Can you read the logs to understand what was touched, and when?
Can you recover what was lost without wiping what came in that same day?
Do you have someone who can do it under pressure?

Building with AI and responding to an incident are different muscles. The first one is trendy. The second one is the one that saves you.

What made the difference

Within minutes we cut off the attacker's access. We rebuilt the timeline from the logs to know exactly what they had touched. We recovered the data from backup and re-injected the day's activity so we wouldn't lose a single operation.

The result: the platform came back 100% operational, with no data loss. Then we closed the gap that allowed it and hardened the rest of the system so it can't happen the same way again.

The takeaway

Building fast is a huge advantage. But "from idea to production" includes the bad days, not just launch day.

If you're building with AI — and you should be — make sure you also have the other muscle: the one for responding. Because sooner or later, someone will knock on the door.

At Avanzia we build fast and we operate what we build. If you want a security review of your app, or to know how ready it is for an incident, let's talk.