Security warnings have always been part of the software landscape. But something has shifted recently. The latest wave of reports is different – and it is not just the usual noise. The Threat is Real – “The question is no longer whether your application will be attacked. The question is whether your data is still safe after the attack succeeds.”

AI-assisted attacks are changing the rules of the game. Where a human attacker once needed hours or days to analyze application code, identify vulnerabilities, and craft an exploit, an AI-powered tool can do the same in minutes. Automated reconnaissance, pattern-based vulnerability detection, intelligent fuzzing – what used to require deep expertise is becoming increasingly accessible.

For those of us building open source software, this hits particularly close to home. Our source code is public by design. That is our strength – transparency, community review, and trust. But it also means that every architectural decision we have ever made is visible to anyone, including those who want to find weaknesses.

Imixs-Workflow is used in environments where business data is genuinely sensitive. HR processes, contract negotiations, legal case management, financial approvals. Data that should only be visible to exactly the right people at exactly the right time. We have always built our security model with this in mind.

But the current discussion goes beyond application-level security: What happens when the database is stolen? Not breached through the application. Not exploited via an API. Simply taken. A stolen backup. A compromised storage volume. A malicious insider with direct database access. In that moment, every access control list that was carefully defined in your BPMN models becomes irrelevant. The data is just data – readable by anyone who has it.

Let’s think through that problem.

Security by Design

Security in most applications is an afterthought. It is added after the core functionality is built, layered on top as middleware, configuration, or a separate service. The result is what security professionals call “perimeter security” – a hard shell around a soft core. Once the perimeter is breached, everything inside is exposed. Imixs-Workflow was designed differently from the start.

Access Control Lives in the Process Model

The central concept of Imixs-Workflow is simple but powerful: security rules are not defined in application code or configuration files. They are defined directly in the BPMN process model – the same model that describes the business process itself. This means that every Task in a BPMN model carries its own Access Control List. Who can read a process instance? Who can write to it? Who owns it? These questions are answered by the model, not by the developer. And they are answered individually for every single process state.

The practical consequence is significant. A vacation request that is writable by the employee in the first step automatically becomes read-only for that same employee once it moves to the approval stage. No code change required. No redeployment. The process model is the security policy. You will find more details about this conecpt in the section Imixs Security.

A Subtle but Important Security Decision

When a user tries to load a workitem they have no read access to, the DocumentService does not throw an exception. It returns null. This is not laziness – it is a deliberate security decision. An AccessDeniedException would confirm to an attacker that a document with a given ID exists. A null return reveals nothing. The document might exist, or it might not. This pattern effectively prevents enumeration attacks where an attacker systematically probes for document IDs to map out sensitive data.

Transparent and Auditable by Design

Perhaps the most important property of this model is its transparency. Because security rules live in the BPMN model, they are visible to every stakeholder – developers, business analysts, auditors, and compliance officers. There are no hidden permission tables in a database, no access control logic buried in application code.

For GDPR compliance in particular, this is genuinely valuable. Every access rule is documented, traceable, and adjustable without touching a single line of code. The process model is not only the executable business process – it is also the living documentation of the security policy.

Where This Model Stops

But every security model has a boundary. And the boundary of this one is clear: it lives entirely within the application layer. The DocumentService is the gatekeeper. The BPMN model defines the rules. The Lucene search index enforces them at query time.

What lies beneath – the raw data in the relational database – is outside the reach of this model entirely. That is the gap we need to care about.

The Weak Spot

Let us look in detail about something that most software projects prefer not to discuss publicly. Every security mechanism as described so fare lives in the application layer. It is enforced by a central data layer depending on one critical assumption: that all access to the data goes through that service. But that assumption can be broken.

One Layer Too High

The database itself knows nothing about our ACL model. There are no row-level security policies, no database-native encryption tied to user identity. To the database, every document is just a blob of bytes identified by a UUID. Anyone with direct database access sees everything – completely unprotected, regardless of what the BPMN model defines.

The Scenarios That Matter

This is not abstract. A stolen backup. A compromised database administrator. A reporting tool with direct database credentials. Any of these puts the entire dataset in the hands of someone who never touched the application layer – and for whom our carefully crafted ACL model is simply irrelevant.

AI-assisted attacks make this more urgent. An attacker who reaches the database can now analyze, correlate, and extract meaningful information at a speed and scale that was not possible just a few years ago. So the question is: Is there a way to push the security boundary down – below the application layer, all the way to the data itself? That question leads us to a piece of software history that was thinking about exactly this problem thirty years ago.

Why Disk Encryption Is Not Enough

A common response to the database threat scenario is straightforward: encrypt the disk. Full-disk encryption – LUKS on Linux, BitLocker on Windows – is widely deployed and well understood. So why is it not sufficient?

Disk encryption protects exactly one attack vector: the physical theft of a storage medium. If someone removes a hard drive from a server, they see nothing. That is valuable – but it is also the least realistic attack scenario in a modern cloud or data center environment.

The moment the system is running, the disk is decrypted. From that point on, a compromised database administrator sees all data in plaintext. A stolen backup – which is typically created from the running database – contains all data in plaintext. An attacker who gains access to the running database process sees all data in plaintext.

A Blast from the Past

Thirty years ago, a piece of software solved a problem that most of the industry had not even recognized yet. Lotus Notes – the legendary groupware platform of the 1990s – was built around a document-oriented database with one extraordinary property: the application was not the only line of defense. The data itself could be protected, independent of the server, independent of the application layer.

The mechanism was the Notes-ID – a personal asymmetric key pair, unique to every user. With it, a document could be encrypted for one or more specific recipients using their public keys. The encrypted data was stored in the database. But without the corresponding private key, that data was unreadable – even with full database access, even as a database administrator, even with a stolen backup.

The elegance of this approach was striking. Security was not enforced by the server checking permissions. It was enforced by mathematics. The server simply could not read what it was not supposed to read.

Encrypting data at the application layer – before it is written to the database – closes all of these gaps simultaneously. The database process itself only ever sees ciphertext. Backups contain only ciphertext. Direct database access reveals nothing meaningful. The encryption is not tied to whether the system is running or not. It is tied to the key – and only the application holding that key can read the data.

Why It Matters Today

This concept of Lotus Notes was ahead of its time then. Today, with AI-assisted attacks capable of extracting meaningful information from raw database content at unprecedented speed, it feels more relevant than ever.

But the context has changed fundamentally since the days of Lotus Notes. Imixs-Workflow is a web application – documents never leave the server as raw data. The browser receives only rendered, already filtered content. The existing ACL model already ensures that only authorized users can access their data. There is therefore no need to encrypt each document individually for every authorized recipient.

This raises a simpler but equally powerful idea: what if the encryption happens at the server level – before the data is written to the database? The database would contain only ciphertext. A stolen backup would be useless without the server key. And the existing ACL model would remain fully responsible for access control, exactly as before.

It is a compelling direction. But as we will see in the next chapter, even this simpler approach comes with a fundamental tension that needs to be resolved.

The Security Conflict

A workflow engine is not a passive document store. It processes documents automatically and server-side – plugins compute deadlines, adapters send notifications, escalation rules trigger state transitions. This creates a fundamental tension: if data is encrypted, the server must be able to decrypt it to do its work.

Lotus Notes faced exactly this problem. Its solution was pragmatic: the server itself held a key – the Server-ID – and was always added as an implicit recipient of every encrypted document. The server could therefore always decrypt and process documents transparently – while the database itself remained completely opaque to anyone without that key.

Conclusion

As we have seen, Imixs-Workflow already provides a solid, transparent, and auditable security model – access control defined in the process itself, not hidden in application code. For the vast majority of attack scenarios, this is the right approach.

But there is a boundary even this model cannot cross: the database layer. The idea of encrypting data before it reaches the database points in the right direction. And as we have seen, the fundamental conflict between server-side processing and encryption is not unsolvable. Lotus Notes showed a pragmatic way forward: a server-held key – a Server-ID – that allows the server to process encrypted data transparently, while keeping the database itself completely opaque to anyone who should not have access.

For Imixs-Workflow, this concept translates naturally. The existing ACL model remains fully responsible for access control. Encryption at the data layer can simply ensure that a stolen database is worthless without the server key – an additional line of defense that the application layer alone can never provide.

This is the direction we are thinking in – the conversation continues…