Ein ganz normaler Sonntag auf unserem Server: 2.822 Anmeldeversuche von fremden Rechnern, dazu automatisierte Scanner auf der Suche nach vergessenen Zugangsdaten. Alle abgewehrt, keiner erfolgreich, kein Ausfall. Wir zeigen die echten Zahlen — und erklären, warum Sicherheit bei einer KI-Plattform anders funktioniert als bei einer Webseite.
Der Bericht, den sonst niemand veröffentlicht
Am Morgen des 27. Juli 2026 haben wir unseren Server durchgesehen — Routine, wie jeden Tag. Was dabei herauskam, ist so unspektakulär wie aufschlussreich:
| Gemessen in 24 Stunden | Wert |
|---|---|
| Fremde Anmeldeversuche | 2.822 |
| Davon erfolgreich | 0 |
| Automatisch gesperrte Angreifer (gesamt) | 60 |
| Anfragen an die Plattform | 6.244 |
| Fehlerhafte Antworten (Serverfehler) | 0 |
| Ungeplante Ausfälle | 0 |
| Laufzeit ohne Neustart | 6 Tage, 18 Stunden |
Die meisten Anbieter veröffentlichen so etwas nicht. Nicht, weil ihre Zahlen schlechter wären — sondern weil Angriffszahlen beunruhigend klingen, wenn man sie nicht einordnet.
Wir machen es trotzdem. Denn die Zahl 2.822 bedeutet nicht, dass wir besonders bedroht sind. Sie bedeutet, dass wir im Internet erreichbar sind. Jeder Server, der eine öffentliche Adresse hat, bekommt diesen Verkehr. Ihre Fritzbox zu Hause auch. Der Unterschied liegt nicht darin, ob man angegriffen wird — sondern darin, was danach passiert.
Was da eigentlich passiert
Zwei Sorten von Besuchern, beide unerwünscht, beide automatisiert:
Die Türklinkenrüttler. Programme, die reihenweise IP-Adressen durchgehen und bei jedem antwortenden Rechner Benutzernamen und Passwörter durchprobieren. „admin/admin", „root/123456", tausende Kombinationen. Menschen sitzen da nicht dahinter — das läuft rund um die Uhr, vollautomatisch, auf Millionen Zielen gleichzeitig.
Die Schatzsucher. Die zweite Gruppe sucht nicht nach Passwörtern, sondern nach Schlamperei. Sie fragt gezielt Dateien ab, die auf schlecht gepflegten Servern versehentlich öffentlich liegen: Konfigurationsdateien mit Datenbank-Zugangsdaten, vergessene Entwicklungsverzeichnisse, Diagnoseseiten, die verraten, welche Software in welcher Version läuft.
Bei uns hat diese zweite Gruppe gestern durchgehend dieselbe Antwort bekommen: 404 — gibt es nicht. Keine Konfigurationsdatei, kein Entwicklungsverzeichnis, keine Diagnoseseite. Nicht, weil wir sie versteckt hätten. Sondern weil sie auf einem Produktivsystem schlicht nichts verloren haben und deshalb gar nicht erst existieren.
Das ist der ganze Trick. Der beste Schutz gegen „vergessene Datei gefunden" ist, nichts zu vergessen.
Warum Passwörter bei uns gar nicht erst zur Debatte stehen
Die 2.822 Versuche haben eine Gemeinsamkeit: Sie waren strukturell chancenlos. Nicht, weil unsere Passwörter besonders gut wären — sondern weil der administrative Zugang zu unserem Server überhaupt nicht mit Passwörtern funktioniert.
Der Zugang läuft ausschließlich über kryptografische Schlüsselpaare. Vereinfacht gesagt: Sie brauchen nicht das richtige Wort, sondern den richtigen physischen Schlüssel, der auf genau einem Rechner liegt und diesen nie verlässt. Ein Angreifer kann Milliarden Passwörter durchprobieren — er probiert an einem Schloss, in das gar kein Schlüsselbart passt.
Dazu kommt eine automatische Sperre: Wer es zu oft falsch versucht, fliegt für eine Weile komplett raus — noch bevor die Anfrage überhaupt beim Anmeldedienst ankommt. 60 Adressen sind auf diese Weise bereits gesperrt worden. Das kostet Angreifer Zeit und Ressourcen und macht unseren Server als Ziel unattraktiv.
Und der gesamte öffentliche Verkehr läuft ohnehin nicht direkt auf unsere Maschine, sondern durch einen vorgeschalteten Filter, der einen Großteil des Unsinns abfängt, bevor er uns überhaupt erreicht.
Mehr Details nennen wir hier bewusst nicht. Ein Sicherheitsbericht soll Vertrauen schaffen, keine Bauanleitung sein.
Der eigentliche Punkt: Ihre Daten liegen nicht im selben Raum
Das Abwehren von Anmeldeversuchen ist Handwerk. Jeder ordentliche Betreiber kann das. Der interessantere Teil beginnt eine Ebene höher — und dort unterscheiden sich KI-Plattformen erheblich voneinander.
Bei den meisten Diensten teilen sich alle Kunden dieselbe Anwendung. Ihre Daten und die Ihres Wettbewerbers liegen in derselben Datenbank, getrennt nur durch eine Prüfung in der Software: „Gehört dieser Datensatz zu diesem Nutzer?" Diese Prüfung funktioniert — bis sie es einmal nicht tut. Ein Programmierfehler in genau dieser Abfrage genügt, und fremde Daten werden sichtbar. Genau so entstehen die Datenpannen, über die man liest.
Bei uns bekommt jeder Kunde eine eigene, technisch abgeschottete Arbeitsumgebung. Kein gemeinsamer Topf, aus dem nach Berechtigung ausgeteilt wird, sondern getrennte Bereiche, die einander schlicht nicht erreichen können. Aktuell laufen elf davon nebeneinander. Ein Fehler in der Rechteprüfung — sollte er je auftreten — kann bei uns keine fremden Daten freilegen, weil die fremden Daten technisch außer Reichweite liegen.
Dazu kommt: Jeder Bereich hat eine feste Speicherobergrenze. Ein Kunde, dessen Auftrag entgleist, kann den Server nicht lahmlegen und damit auch nicht die Arbeit der anderen stören.
Wie wir das im Detail nachweisen — inklusive der Frage, was mit Ihren Daten bei der eigentlichen Sprachverarbeitung passiert —, steht in unserem Beitrag zu KI-Sicherheit und DSGVO.
Alle zehn Minuten fragt das System sich selbst, ob es noch gesund ist
Sicherheit ist kein Zustand, den man einmal herstellt. Deshalb prüft sich unser System selbst — automatisch, ohne dass jemand einen Knopf drückt:
- Alle zehn Minuten kontrolliert eine Prüfroutine sämtliche Kundenumgebungen: Läuft alles? Sind die Verbindungen korrekt? Stimmen die Einstellungen? Kleinere Abweichungen repariert sie selbständig und schreibt mit, was sie getan hat.
- Täglich in der Nacht entsteht eine verschlüsselte Sicherung des gesamten Bestands.
- Einmal am Tag läuft zusätzlich eine Tiefenprüfung, die keine Statusmeldungen abfragt, sondern echte Aufträge durch das System schickt — weil „der Dienst antwortet" und „der Dienst arbeitet" zwei verschiedene Dinge sind.
Diese Selbstprüfung ist auch der Grund, warum ein Vorfall im Juli, bei dem eine automatische Aktualisierung falsche Einstellungen in eine Kundenumgebung schrieb, innerhalb von Minuten von selbst repariert wurde — protokolliert, nachlesbar, ohne dass ein Mensch eingreifen musste.
Warum wir überhaupt Zahlen veröffentlichen
Ein Sicherheitsbericht, in dem nur steht, dass alles gut ist, ist kein Bericht — das ist Werbung. Deshalb nennen wir gemessene Werte mit Datum und Zeitraum statt Beteuerungen. Jeder kann nachrechnen, was 2.822 abgewehrte Versuche bedeuten; niemand kann nachrechnen, was „höchste Sicherheitsstandards" bedeutet.
Dass wir unsere eigene Plattform grundsätzlich mit den Augen eines Angreifers ansehen, gehört bei uns zum Betrieb: Wir greifen sie regelmäßig selbst an, bevor es jemand anders tut — und was dabei auffällt, wird behandelt wie ein echter Vorfall: Ursache suchen, beheben, protokollieren. Wie sich Angriff und Verteidigung gerade beide automatisieren, steht in unserem Beitrag „KI gegen KI". Und wenn Sie Ihre eigenen Systeme prüfen lassen wollen: Dafür gibt es bei uns SMarTrPenTester.
Was das für Ihre Anbieterwahl heißt
Sie können die Sicherheit eines Anbieters nicht selbst nachmessen. Aber Sie können fragen — und die Antworten sagen viel:
1. „Liegen meine Daten mit denen anderer Kunden in derselben Datenbank?" Wenn ja: Was passiert bei einem Programmierfehler in der Rechteprüfung? 2. „Wo genau wird verarbeitet?" Serverstandort und Ort der KI-Verarbeitung sind zwei verschiedene Fragen. Anbieter, die das vermischen, tun das selten aus Versehen. Wir trennen es ausdrücklich — auch dort, wo die Antwort für uns unbequem ist. 3. „Wie oft prüft sich Ihr System selbst — und was passiert bei einem Fund?" 4. „Wann wurde zuletzt etwas gefunden?" Die beste Antwort ist nicht „nie". Die beste Antwort ist ein Datum und eine Beschreibung. 5. „Wie lange dauert die Wiederherstellung nach einem Totalausfall?" Wer Sicherungen hat, sie aber nie zurückgespielt hat, hat keine Sicherungen, sondern Dateien.
Punkt fünf ist übrigens der, an dem wir selbst gerade arbeiten. Unsere Sicherungen laufen täglich und verschlüsselt — aber eine vollständige Wiederherstellung haben wir noch nicht geprobt. Sie steht auf unserer Liste, und wir werden auch darüber berichten.
Sicherheit als Teil des Produkts, nicht als Fußnote
Unser Gründer ist ausgebildeter Ethical Hacker und Google-AI-Professional — und selbst schwerbehindert. Beides prägt, wie diese Plattform gebaut ist: Sie muss von Anfang an ohne Maus und ohne gutes Sehvermögen bedienbar sein (wie das aussieht, steht hier) — und sie muss angegriffen werden können, ohne dass etwas passiert.
Beides ist kein Zusatzmodul. Es ist der Grund, warum das Produkt so aussieht, wie es aussieht.
Wollen Sie die Plattform selbst ausprobieren? Alle neun Assistenten stecken in jedem Tarif, ohne Freischaltgebühr — zur Übersicht im Shop. Oder schreiben Sie uns direkt: [email protected].
Alle Zahlen in diesem Beitrag stammen aus der Systemdurchsicht vom 27. Juli 2026, 24-Stunden-Fenster. Wir veröffentlichen bewusst keine Angaben, die einem Angreifer die Arbeit erleichtern würden — also keine Versionsnummern, keine Schwellenwerte, keine Angaben zur Netzwerkstruktur.
SMarTrAgents — Cloud-first KI-Agenten und SMarTrHybrid-Lösungen. Made in Germany.
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:
1. "Is my data in the same database as other customers'?" If yes: what happens when there's a bug in the permission check? 2. "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. 3. "How often does your system check itself — and what happens on a finding?" 4. "When did you last find something?" The best answer is not "never". The best answer is a date and a description. 5. "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 — Cloud-first AI agents and SMarTrHybrid solutions. Made in Germany.