Sovereignty Is Engineered, Not Procured

Europe often asks whether it can build a company like Palantir: a software champion capable of serving intelligence, defence, law enforcement, crisis response, cyber defence, and public-sector decision-making at scale.

The usual answer is that Europe lacks data, capital, talent, or legal room. I do not think this is the full story.

The capacity is there. The data is there. The technical talent is there. The public-sector problems are real, urgent, and interesting. What is often missing is the will to tackle complex programmes seriously, over time, with teams that are allowed to build, fail, iterate, and take responsibility.

Europe does not need a Palantir clone and definitely does not want such a proprietary tool. It needs the capacity to build strategic software for intelligence and security missions without outsourcing the core of its thinking.

The problem is not only procurement

European intelligence and security organisations often buy American intelligence products, American analytics platforms, American cloud stacks, and American operational software. This is sometimes justified by speed, maturity, interoperability, or political convenience. Those arguments are not always false.

But they hide a deeper problem: dependency becomes culture.

Once an organisation accepts that the difficult software will be bought elsewhere, internal teams slowly lose the habit of building. Procurement becomes a substitute for strategy. Legal review becomes a substitute for leadership. Risk management becomes a substitute for execution.

In such environments, the safest answer is always “no”: No, we cannot expose this. No, we cannot publish this. No, we cannot collaborate. No, we cannot build it ourselves. No, legal will not allow it. No, procurement will take too long. No, it is too sensitive.

Some of these objections are valid. Many are excuses.

The result is predictable: Europe keeps producing excellent policy documents about sovereignty while buying the operational substrate of sovereignty from others.

Intelligence software is not magic

The mystique around intelligence software is harmful. Much of the work is not magical. It is hard engineering, data modelling, workflow design, access control, auditability, graph analysis, entity resolution, case management, knowledge management, search, enrichment, automation, feedback loops, and user experience.

These are difficult problems, but they are not impossible problems.

The difficult part is not only technical. It is organisational.

You need teams that understand the mission and the technology. You need product owners who know the analysts’ work. You need engineers who are trusted with real problems, not toy datasets. You need security and legal teams that help build safe ways forward instead of only producing reasons to stop. You need leadership willing to accept that serious internal capacity cannot be built through one-year projects, rotating committees, or PowerPoint roadmaps.

A European intelligence champion would not emerge from a single procurement framework. It would emerge from a culture that rewards building.

The counterexample: agencies that publish

There are public counterexamples.

The NSA has released and maintained open-source software. Ghidra, its reverse-engineering framework, is one of the most visible examples. Apache NiFi and Apache Accumulo also show a pattern: internal capabilities can be released, reused, governed, and improved outside the original classified context. SELinux is another historical example of a security capability that moved into the broader ecosystem.

National Geospatial-Intelligence Agency (NGA) produces a significant numbers of geo-spatial open-source tooling such as MAGE.

GCHQ released CyberChef, a widely used browser-based tool for encoding, decoding, transformation, and data analysis. It also published Gaffer, a graph database framework designed for large-scale entity and relationship analysis.

In Europe, ANSSI has published tools and policy around open source, including CLIP OS and digital forensics tooling. CIRCL’s MISP is a strong European example of an open-source threat intelligence and sharing platform built by practitioners for practitioners.

These examples matter because they show that “sensitive mission” and “public engineering” are not mutually exclusive. You do not publish secrets. You publish reusable infrastructure, generic tooling, schemas, libraries, documentation, and lessons learned.

The public artefact is not the operation. It is the scaffolding that makes the operation more mature.

Open source is not charity; it is capacity building

When an intelligence or cyber agency releases useful software, it is not doing charity. It is doing industrial policy, recruitment, standardisation, quality assurance, and ecosystem building at the same time.

Open source can:

• attract engineers who want to work on real problems;
• create common standards across agencies and partners;
• reduce duplicated development;
• allow universities and SMEs to contribute;
• make procurement less dependent on single vendors;
• improve trust through inspectable code;
• turn internal tools into shared infrastructure;
• create a training path for future analysts and developers.

This is not about publishing everything. It is about knowing what can be safely published and having the institutional courage to do it.

The irony is that secrecy is often used to protect weak engineering, not sensitive capability. If a tool cannot be shown, documented, tested, or reused, sometimes the reason is not classification. Sometimes the reason is that it is fragile, badly governed, or too dependent on a contractor.

Europe has data, but not enough product culture

European public institutions and trusted national operators already sit close to enormous amounts of relevant data. This includes cyber incident data, vulnerability data, malware metadata, abuse reports, phishing reports, domain and certificate data, passive DNS, DNS telemetry, routing information, NetFlow and other network metadata from trusted infrastructure or ISP-level cooperation, honeypot data, sinkhole data, scanning results, open-source intelligence, sanctions data, company registers, procurement data, satellite data, customs data, border data, law-enforcement data, and diplomatic reporting.

There are also many other sources that do not need to be publicly listed. The point is not to expose them. The point is to recognise that Europe does not lack raw material.

The problem is rarely the absence of data. The problem is the ability to lawfully collect, govern, correlate, enrich, protect, and transform that data into operational products.

A product is not a database. A product is not a dashboard. A product is not a tender. A product is not a pilot. A product is not a research prototype.

A product has users, maintenance, documentation, security boundaries, onboarding, training, ownership, metrics, feedback, and a roadmap. A product survives beyond the first grant. A product has a team.

This is where many European initiatives fail. They are funded as projects, not built as products. They are coordinated as programmes, not operated as capabilities. They produce deliverables, not infrastructure.

The strategic challenge is not only to collect data. It is to build the institutional and technical capacity to turn legally accessible data into timely intelligence, while keeping strong boundaries around sensitive sources, methods, and protected information.

The legal excuse

Europe is very good at finding legal complexity. This is sometimes necessary. Intelligence, defence, cyber defence, and law enforcement must operate under democratic control, fundamental rights, proportionality, and auditability.

But legal complexity cannot become a permanent excuse for inaction.

The role of legal teams should not be to restrict the mission by default. Their role should be to help the organisation achieve its mission lawfully, creatively, and responsibly.

Good legal work is not only about saying what cannot be done. It is about designing the conditions under which useful work can be done: minimisation, compartmentalisation, access controls, retention rules, audit logs, purpose limitation, synthetic data, redaction, disclosure processes, and clear governance.

Law should be part of the architecture. Legal teams should be close enough to the mission to understand the operational need, and close enough to the engineers to help design systems that respect the law while still delivering capability.

The question should not be: “Can we avoid all risk?” The question should be: “How can we use the law to support the mission, reduce risk, and create a defensible path to action?”

A risk-free intelligence system does not exist. Buying a foreign platform does not remove risk. It merely changes who controls it.

The fear of exposure

Many intelligence and security organisations fear exposing how they work. Some of that fear is legitimate. Methods, sources, tasking, and operational priorities must be protected.

But hiding everything creates a second-order weakness: nobody outside the wall can help, and nobody inside the wall is forced to improve.

Open-source publication, public APIs, shared schemas, public documentation, and controlled community engagement do not require revealing operations. They require discipline. They require separating the generic from the sensitive.

That separation is itself a sign of maturity.

If an organisation cannot separate reusable engineering from classified activity, it probably does not understand its own architecture well enough.

What is missing?

What is missing is not a European lack of intelligence. It is a lack of institutional appetite.

More precisely, Europe is missing:

1. Mission-driven product teams Small, stable teams with engineers, analysts, security people, legal support, and operational ownership.

2. Long-term technical leadership People who can say no to bad architecture, bad outsourcing, and fake innovation.

3. A willingness to publish non-sensitive components Open-source software, schemas, libraries, test datasets, documentation, and reference implementations.

4. Procurement that rewards capacity, not dependency Contracts should build internal competence, not replace it.

5. Creative legal engineering Lawyers and technologists working together from day one to use the law as a framework for action, not as a default reason for refusal.

6. Acceptance of managed risk No serious capability is built without risk. The goal is not to eliminate risk but to govern it or even accept it.

7. A culture of reuse across European agencies Europe does not need twenty incompatible platforms solving the same problem badly.

8. Operational feedback loops Analysts and investigators must shape the tools they use. Otherwise software becomes theatre.

The strategic choice

Europe can keep buying intelligence software from others and call it pragmatic. Sometimes that will be necessary. But if it becomes the default, Europe should stop pretending that it is building sovereignty.

Sovereignty is not declared. It is engineered.

It is engineered in code repositories, data models, deployment pipelines, documentation, audit logs, and teams that know how to operate under pressure. It is engineered when public institutions learn to build again.

The lesson from NSA, NGA, GCHQ, ANSSI, CIRCL, and others is not that everything should be open. The lesson is that strong institutions can expose selected parts of their engineering without exposing their secrets.

That is what confidence looks like.

Europe has the people. It has the data. It has the problems. It even has successful examples.

What it still needs is the desire to build serious programmes, the courage to accept managed risk, the creativity to use the law as an enabler, and the discipline to turn public-sector software from procurement artefacts into operational capabilities.

A European intelligence champion will not appear because a minister announces one.

It will appear when European organisations decide that building is part of the mission.