How to Build a Government Platform That Can't Leak Your Data

There's a question I get asked whenever I talk about AEGIS: "Where do you store the citizen data?"

The answer is: we don't.

Not in a database. Not in a backup. Not in a log file. Not encrypted at rest. Not anywhere. The data passes through RAM, gets delivered to the government agency on the other end, and then it's gone. Permanently.

This isn't a feature we added after the architecture was done. It's the architecture itself. And it changes everything about how you think about security for government platforms.

The problem with promises

Every government IT system promises data security. They all have encryption. They all have access controls. They all have compliance certificates on the wall. And yet, data breaches in public administration keep happening.

The reason is simple: if data exists on a server, someone can eventually access it. An insider. A misconfigured backup. A zero-day. A subpoena from a foreign government under the CLOUD Act. The attack surface is proportional to the data you store.

So we asked ourselves: what if we stored nothing?

Zero-Persistence: RAM-only processing

Here's how it works in practice.

When a citizen submits an application through AEGIS, the data is encrypted end-to-end from their device to the receiving government agency. AEGIS sits in the middle as what we call a "blind courier." We transport the package. We never open it.

Personally identifiable information only exists in volatile memory (RAM) during the brief moment of processing, things like validating document completeness or checking format requirements. The moment the transaction completes or fails, the data is gone. Not deleted. Gone. RAM doesn't survive a power cycle, and we don't write PII to disk. Ever.

This is a fundamentally different security model. Instead of "we protect your data with 17 layers of security," it's "we physically cannot have your data." You can't hack what isn't there.

The Compliance Stack

Running a government platform in Europe means meeting a long list of requirements. Here's what the AEGIS infrastructure is built on:

ISO/IEC 27001 for information security management. Not ours to claim (it's the hosting provider's certification), but it's the baseline for everything we run on.

BSI C5 (Cloud Computing Compliance Criteria Catalogue). This one matters most in Germany. Federal agencies increasingly require C5 attestation from their cloud providers. Our infrastructure runs on providers with current C5 attestation.

TISAX Assessment Level 3. This is actually stricter than most government security standards, developed for the automotive industry where supply chain espionage is a real threat. I've been through the TISAX certification process at four sites. It's thorough.

eIDAS compliance for electronic identification and trust services. This is what makes the identity layer work across EU borders.

GDPR full compliance, obviously, including Data Processing Agreements (DPA) per Article 28. Though with zero-persistence, the DPA conversation gets interesting. There's not much to process if you don't keep anything.

No US access. Period.

This one is non-negotiable for any serious European government platform.

All AEGIS infrastructure runs in data centers in Germany (Frankfurt, Munich) or the EU (Strasbourg). We use exclusively European cloud providers: Open Telekom Cloud, IONOS, OVH. Not a single byte leaves the European legal jurisdiction.

Why does this matter? Because of the US CLOUD Act. If your data sits on infrastructure operated by a US-headquartered company (including their EU subsidiaries), US authorities can compel access. It doesn't matter that the server is in Frankfurt. The legal jurisdiction follows the company, not the hardware.

By choosing sovereign European providers, we remove this vector entirely. Our cryptographic keys live in dedicated Hardware Security Modules (HSMs) at Open Telekom Cloud, physically separated from the internet. Nobody gets to those keys without physical access to the hardware.

The Kill Switch

Government agencies need control. Absolute, instant, no-questions-asked control. We designed for that.

API Sovereignty: Every agency retains full control over its own interfaces. AEGIS doesn't own any government endpoints. We connect to them.

Emergency Stop: If an agency suspects a security incident, they revoke the AEGIS API key in real time. Data flow stops immediately. Not "within 24 hours." Not "after review." Immediately. One click.

Audit Logs: Every transaction generates a pseudonymized audit log, who initiated what, when, with what result, that the agency can review independently. They don't need to trust us. They can verify.

This is a deliberate design choice. Trust in infrastructure should be verifiable, not assumed.

Threat modeling: what keeps me up at night (and what doesn't)

When we did the threat modeling for AEGIS, some scenarios just didn't apply. Which is a strange feeling.

Data breach? Not possible for PII. There's no database to breach. The "crown jewels" don't exist on our side. This eliminates the most common and most damaging attack category entirely.

Man-in-the-middle? We enforce mutual TLS 1.3 (mTLS) between the citizen's app, AEGIS, and the agency. Both sides authenticate. Intercepting the connection requires compromising both certificate chains simultaneously.

DDoS? Multi-layer scrubbing through our sovereign providers. This is the one area where we rely on traditional defense. DDoS is an availability problem, not a data security problem, so the zero-persistence model doesn't help here. But it's a solved problem.

Insider threat? This is the one that usually keeps IT managers awake. A rogue admin with database access can do enormous damage in traditional systems. In AEGIS, admins can't access RAM contents because we use confidential computing enclaves. All critical operations require a four-eyes principle. There's nothing to exfiltrate because there's nothing persisted.

The threat model isn't "we've built higher walls." It's "we've removed what the walls were protecting."

End-to-end encryption, actually

"End-to-end encryption" has become a marketing term. Everybody claims it. Very few implement it properly.

In AEGIS, E2EE means: data is encrypted on the citizen's device (the CIVOS app) using the citizen's key. It stays encrypted through every hop. The receiving government agency decrypts it with the corresponding key. AEGIS, the platform in the middle, never has access to the plaintext.

We can't read your application. We can't read your documents. If someone put a gun to our heads and demanded we hand over citizen data, we would genuinely have nothing to hand over. Not because we're brave. Because the architecture makes it impossible.

The citizen controls their private key. They decide what gets shared with whom. We transport encrypted blobs, validate formats and completeness through zero-knowledge proofs where possible, and deliver.

Why this matters beyond compliance

Compliance is table stakes. You need the certificates, the attestations, the audit trails. But compliance doesn't equal security. I've seen plenty of compliant systems that were fundamentally insecure in practice.

What zero-persistence gives you is something deeper: it removes entire categories of risk. You don't need to worry about data retention policies if you don't retain data. You don't need to worry about cross-border data transfer regulations if data never lands on disk. You don't need to worry about backup encryption if there are no backups of citizen data.

Security isn't a feature you bolt on. It's the foundation you build on. For a platform that handles the most sensitive interactions between citizens and their government, there is no acceptable alternative.

This is the fourth post in a series about AEGIS. The first, "Bureaucracy Shouldn't Separate Families", explains why this project exists. The second, "Inside AEGIS: A First Look at the Architecture", covers the technical foundation. The third, "Why Government Portals Fail", explores the game theory behind incentive design. The next post will explore the financial and technical architecture, from funding models to infrastructure costs.