2,822 Attacks in a Single Day, and Why No Customer Noticed a Thing

An ordinary Sunday on our server: 2,822 login attempts from foreign machines, plus automated scanners hunting for forgotten credentials. All repelled, none successful, no downtime. Here are the real numbers, and why security on an AI platform works differently than on a website.
The report nobody else publishes
On the morning of 27 July 2026 we reviewed our server, routine, like every day. What came out of it is as unspectacular as it is revealing:
| Measured over 24 hours | Value |
|---|---|
| Foreign login attempts | 2,822 |
| Successful ones | 0 |
| Automatically blocked attackers (total) | 60 |
| Requests to the platform | 6,244 |
| Faulty responses (server errors) | 0 |
| Unplanned outages | 0 |
| Uptime without restart | 6 days, 18 hours |
Most providers don’t publish this. Not because their numbers would be worse, but because attack figures sound alarming when nobody explains them.
We publish anyway. Because 2,822 doesn’t mean we’re under particular threat. It means we are reachable on the internet. Every server with a public address gets this traffic. So does your home router. The difference isn’t whether you get attacked, it’s what happens next.
What’s actually going on out there
Two kinds of visitors, both unwelcome, both automated:
The doorknob rattlers. Programs that walk through IP addresses one after another and, on every machine that answers, try usernames and passwords. “admin/admin”, “root/123456”, thousands of combinations. There are no humans behind this, it runs around the clock, fully automated, against millions of targets at once.
The treasure hunters. The second group isn’t looking for passwords, it’s looking for sloppiness. It requests specific files that sit publicly on poorly maintained servers by accident: configuration files containing database credentials, forgotten development directories, diagnostic pages revealing which software runs in which version.
Yesterday this second group got the same answer every single time: 404, doesn’t exist. No configuration file, no development directory, no diagnostic page. Not because we hid them. Because they have no business on a production system in the first place, and therefore never existed.
That’s the whole trick. The best protection against “forgotten file discovered” is not forgetting anything.
Why passwords aren’t even part of the conversation here
The 2,822 attempts share one thing: they were structurally hopeless. Not because our passwords are especially good, but because administrative access to our server doesn’t use passwords at all.
Access runs exclusively on cryptographic key pairs. Put simply: you don’t need the right word, you need the right physical key, which lives on exactly one machine and never leaves it. An attacker can try billions of passwords, they are picking at a lock that has no keyhole for their kind of key.
On top of that sits an automatic block: try too often and you’re shut out entirely for a while, before the request even reaches the login service. Sixty addresses have been blocked this way so far. That costs attackers time and resources, and makes our server an unattractive target.
And all public traffic doesn’t reach our machine directly anyway. It passes through an upstream filter that absorbs a large share of the nonsense before it ever gets to us.
We deliberately stop short of more detail here. A security report should build trust, not hand out blueprints.
The real point: your data isn’t in the same room
Repelling login attempts is craft. Any competent operator can do it. The more interesting part starts one level up, and that’s where AI platforms differ substantially.
With most services, all customers share the same application. Your data and your competitor’s sit in the same database, separated only by a check in the software: “does this record belong to this user?” That check works, until one day it doesn’t. A single programming mistake in exactly that query is enough for foreign data to become visible. That’s precisely how the data breaches you read about happen.
With us, every customer gets their own technically isolated workspace. Not a shared pot handed out by permission, but separate environments that simply cannot reach one another. Eleven of them currently run side by side. A flaw in permission checking, should one ever occur, cannot expose foreign data here, because foreign data is technically out of reach.
There’s more: every workspace has a fixed memory ceiling. A customer whose job runs away with itself cannot take the server down, and therefore cannot disrupt anyone else’s work.
How we demonstrate this in detail, including what happens to your data during the actual language processing, is covered in our piece on AI security and GDPR.
Every ten minutes, the system asks itself whether it’s still healthy
Security isn’t a state you establish once. So our system checks itself, automatically, without anyone pressing a button:
- Every ten minutes, a check routine inspects all customer environments: is everything running? Are the connections correct? Are the settings right? Minor deviations it repairs on its own, and writes down what it did.
- Every night, an encrypted backup of the entire estate is created.
- Once a day, a deep check runs on top of that, one that doesn’t query status messages but sends real jobs through the system, because “the service responds” and “the service works” are two different things.
That self-checking is also why an incident in July, where an automatic update wrote wrong settings into a customer environment, repaired itself within minutes, logged, auditable, without a human stepping in.
Why we publish numbers at all
A security report that only says everything is fine isn’t a report, it’s advertising. So we give measured values with a date and a time window instead of assurances. Anyone can work out what 2,822 blocked attempts mean; nobody can work out what “highest security standards” means.
Looking at our own platform through an attacker’s eyes is part of how we operate: we attack it ourselves, regularly, before someone else does, and whatever turns up is handled like a real incident: find the cause, fix it, log it. How attack and defence are both automating right now is the subject of our piece “AI versus AI”. And if you want your own systems tested: that’s what SMarTrPenTester is for.
What this means for choosing a provider
You can’t measure a provider’s security yourself. But you can ask, and the answers tell you a lot:
- “Is my data in the same database as other customers’?” If yes: what happens when there’s a bug in the permission check?
- “Where exactly is processing done?” Server location and place of AI processing are two different questions. Providers who blur them rarely do so by accident. We separate them explicitly, including where the answer is inconvenient for us.
- “How often does your system check itself, and what happens on a finding?”
- “When did you last find something?” The best answer is not “never”. The best answer is a date and a description.
- “How long does recovery from a total loss take?” Anyone who has backups but has never restored them doesn’t have backups, they have files.
Point five, incidentally, is the one we’re working on ourselves. Our backups run daily and encrypted, but a full restore is something we have not yet rehearsed. It’s on our list, and we’ll report on that too.
Security as part of the product, not a footnote
Our founder is a trained ethical hacker and Google AI Professional, and severely disabled himself. Both shape how this platform is built: it has to be operable without a mouse and without good eyesight from day one (here’s what that looks like), and it has to be attackable without anything happening.
Neither is an add-on module. It’s the reason the product looks the way it does.
Want to try the platform yourself? All nine assistants are included in every plan, with no unlock fees, see the shop. Or write to us directly: [email protected].
All figures in this piece come from the system review of 27 July 2026, 24-hour window. We deliberately publish nothing that would make an attacker’s work easier, no version numbers, no thresholds, no details about network structure.
SMarTrAgents, nine AI agents in one shared workspace. Accounts and files are held in the EU.
AI agents and GDPR
EU storage, one container per customer, no model training and processing under Art. 28 GDPR, explained on one page.