Knowing when to fall : Kahiether Cybersecurity patterns🏰🏯

「壊れぬべき時知りてこそ世の中のシステムもシステムなれ、アプリもアプリなれ」 It's in knowing when to fall that systems become systems, and architecture becomes architecture - taken from a famous poem, the simple meaning behind is that you don't really know how solid is an architecture until it breaks

With the increasing usage of AI based attacks, it felt worth documenting how a basic cybersecurity approach can be put together for a small system like this.

The story begin when the first major attakc hit the infrastructure, at that time everything was mutualized in a php simple instance. The atack was leaded though Wordpress vulnerabilities. Just after the Kahiether structure was imagined, : dockers, analytics, monitoring.

The 2 main rules

1 - The best protection is to have no data

The most valuable thing today is data. But No system is impenetrable, and this is even more true lately where AI lowers the cost of attacks. Data security is not a new field. For millennia, we humans have dealt with it. And the most reliable method they found back at that time : when a message had been read, they destroyed it (burn the paper, destroy the carved stone, etc..) . No storage, no exposure, the data remains temporarily in the mind of those who need it.

The practical consequence here is that light apps dont't want not to hold valuable data server-side at all. If there is nothing worth stealing, the attacker's motivation shrinks considerably.

2- Adapt and be resilient

There is one main assumption to take : when the system started it was already vulnerable and infiltrated (zero day threat). In fact, there will always be new techniques, new vectors, new tools on the red team (attackers). The real objective is not to keep up with all of them or to anticipate, that is a losing race, it is to build something that fall gracefully (like flower) and recovers on its own. Part of how Kahiether approaches this is the offline-first architecture discussed previously: the frontend is a service that can function without the backend, meaning a service going down does not necessarily mean the user loses access entirely. Resilience by design, rather than resilience by patching.

The Kahiether philosophy

When building the architecture, there were two main directions to consider.

• The first : fortify the castle over time, repair and reinforce every breach, run PenTests, and try to make it impenetrable.
• The second : build a keep that has little value, one that can be raised and torn down without much loss.

Let systems fall

One of the principles that guides the architecture is to not fight failure, to accept it.

• If a service is consuming too much CPU or RAM, it crashes.
• If it receives too many requests in a short burst, it gets temporarily cut.

Docker Compose resource limits handle this at the container level : each service is given a ceiling, and if it exceeds it, the container restarts automatically.

The reasoning is partly philosophical and partly practical. Systems that never break tend to accumulate hidden fragility : when they finally go down, the failure is unexpected and the fallout is hard (in term of time and investment) to solve. Controlled, predictable failure is easier to reason about. An attacker generating load will eventually trigger the circuit breaker, not melt the server.

Make the defense cheaper than the attack

Make the attack more expensive for the attacker than for the defender. The idea comes from the ancient general Pyrrhus of Epirus, who won his battles but at such cost that he considered a victory too much paid that he could afford more victories. Here the goal is to consider that the attacker is spending bandwidth, RAM, and increasingly AI tokens to probe the system and look for exploits. The keep is cheap to rebuild. The assault is not.

This shapes a few concrete decisions : no personal data stored, no session data worth intercepting, no server-side state that would make a breach rewarding. The attack surface exists, but the reward for crossing it is minimal.

But, that doesn't prevent from controlling and monitoring events.

3 / Knowledge and monitoring

「知彼知己，百战不殆 」 孙子 (Zhibi zhiji, baizhan budai) : Know yourself and your opponent, and you will survive a hundred battles.

The monitoring stack for Kahiether is orchestrated by various tools : Google Apps Script, node-red, n8n, etc... The reason is simple, we don't want to rely on one single solution.

Performance checks : Google Apps Script and n8n

For example, we have a daily Apps Script call checks the HTTP status and response time of all exposed frontend applications. If anything returns an error or a duration outside of the expected range, an alert gets triggered. This is intentionally simple : no infrastructure overhead, no third-party SaaS dependency. Apps Script runs on Google's servers on a schedule, meaning it is external to the system it is checking. That is actually useful : a self-monitoring system that lives inside the thing being monitored is less reliable (does represent real) than one that observes from outside.

n8n is used alongside this for more complex workflows. It is built around a node-based interface where each step in a workflow is a configurable block. The license is worth knowing : n8n uses the Sustainable Use License, a "fair-code" model. Self-hosting for internal use is free and allowed. What is restricted is reselling n8n as a service. The docker-compose template for n8n is part of the kahiether docker-compose library.

Node-RED is also in the stack, used for some orchestration flows, especially AI related communication. It is Apache 2.0 licensed, fully open source, no restrictions.

Traffic analytics patterns : Umami

Umami is our self-hosted web analytics platform. It tracks pageviews, traffic sources, referrers and custom events without cookies and without collecting personal data. This means it is GDPR-compliant by design, not by configuration. No consent banners, no PII to protect, no data to hand over. The license is MIT : clean, permissive, no constraints. The docker-compose template is also available in the library. In practice, Umami is used to understand traffic spikes and seasonal patterns. When something unusual appears, a sudden burst from an unexpected region, a specific endpoint being hammered, it becomes visible in the dashboard.

Docker controls for Resource limits and CORS

Each container in the stack is assigned a CPU and RAM ceiling. If the ceiling is exceeded, Docker restarts the container automatically. This keeps a misbehaving or exploited service from degrading the rest of the system. CORS controls are enforced at the reverse proxy level, not inside each application, which keeps the policy consistent and harder to bypass at the app layer. ex : this is very good to break the kind of silent penetrations that try to mine bitcoin silently or tries to find if they can use gpu, cpu, or ram silently.

Rate limiting and burst control at proxy level

Rate limits and burst limits are configured in the reverse proxy as well. The intent is not to stop every attack, it is to make sustained attacks expensive. A legitimate user hitting a rate limit once in a while is a manageable UX problem. An automated scanner getting rate-limited on every request quickly becomes a cost problem for the attacker.

Sentinelle : integrity checking

2026-sentinelle is a small Node.js probe that checks the content signatures and performance of frontend services. It is called regularly by a workflow, and the idea is simple : if the content of a page or asset changes unexpectedly, an injected script, a modified dependency, something that was not there before, the signature check should raise something. It is still a system in evaluation, but it covers some case of silent supply-chain or content tampering especially in monolithic applications like Wordpress. It's MIT licensed.

Standard security measures

Above these measures standards security measures are applied

• API keys and technical auth
• CORS for all frontends
• Restriction of iFrame communication for frontends that are sensitive (triggered programmatically in the browser)

Code audit : AI-assisted, human-decided

The last but not the least. A workflow periodically triggers an AI review of the codebase on GitHub. The main objective of this is not security but continuous improvement (decide whether its useful or not to improve the code) but it can also raise some security problems. The proposals are analyzed latter but most of them are non relevant in a no backend and no database architecture. The AI is used as an auditor, not an operator.

Wrap-up

Since we accept the possibility of being attacked, there is limited value in investing further in heavy defense. That's why we must build systems that can be rebuilded as fast as they were destroyed and bring all around the monitoring, observability and security measures. The thing is, once a service is distributed, it becomes a node, and that node is stored in the user device with all his data. So, the next big question is how to allow that node to distribute itself within a local network, without internet access. But before talking about that, we might review the AI workflows that run under Kahiether.