Proteus - An autonomous Post-Quantum Migration Engineer

Proteus migrates an enterprise application's cryptography to post-quantum standards on its own — then proves it, with a running sandbox and nine tool-established checks. Not a scanner. An engineer.

Comment

Inspiration

Post-quantum migration is becoming a very large engineering problem.

NIST has already published the first PQC standards, including FIPS 203, 204 and 205, and organisations now have to start moving away from quantum-vulnerable public-key cryptography such as RSA and ECC.

For a large enterprise, this can mean hundreds or even thousands of applications, APIs, certificates, HSMs and infrastructure components that need to be understood and migrated.

And the problem goes beyond enterprise IT. Industrial OT and critical infrastructure also depend on cryptography across control systems, gateways, industrial devices, firmware, secure communications and hardware-backed keys. These environments are often harder to change because of long asset lifecycles, vendor dependencies and limited upgrade windows.

Even a single application can take several weeks of engineering effort, while more complex applications involving PKI, HSMs, external protocols or hardware dependencies can take months to migrate safely.

At enterprise scale, that quickly becomes years of engineering effort across the application and infrastructure portfolio.

The problem is that discovery is only the first step.

A scanner can tell you that RSA exists somewhere in the code. But somebody still has to work out what that RSA is doing, whether it is used for key transport or signatures, what depends on it, what should replace it, how to change the code, how to test it, and how to prove that nothing broke.

That is the gap we wanted to solve with Proteus.

We built it as an Autonomous Post-Quantum Migration Engineer, an end-to-end migration engineering agent.

What it does

Proteus takes an application repository from discovery all the way to a migrated and verified application.

The flow is:

Discover → Assess → Human Approval → Migrate → Verify → Live Sandbox

During discovery, Proteus scans the repository, identifies cryptographic implementations and dependencies, and builds a dependency graph.

It also tries to understand what the cryptography is actually being used for.

That distinction is important.

For example:

  • RSA used for key transport may be a candidate for ML-KEM.
  • RSA used for a digital signature is a completely different problem and should not be migrated to ML-KEM.
  • Cryptography inside HSMs, protocols or external systems may need to be flagged rather than changed automatically.

Proteus creates an assessment and migration plan, and the engineer approves that plan once.

After approval, the Migration Engineer takes over. It creates its own Git branch, captures the current behaviour, creates or extends tests, changes code and dependencies, builds the application, runs the tests, diagnoses failures, repairs them, and tries again.

Once the migration is complete, Proteus runs deterministic verification and deploys the migrated application into a live sandbox for review.

So the output is not just a recommendation or a code diff. It is a working migrated application, with the evidence showing what changed and why.

In our reference run, Proteus completed the flow from repository to verified sandbox in around 9 minutes, with only one human decision: approving the migration.

How we built it

The main principle behind Proteus is simple:

Gemini reasons. Deterministic tools establish truth.

We use Gemini where reasoning is useful — understanding the repository, planning the migration, writing code, diagnosing failures and repairing them.

But Gemini is not allowed to decide whether the migration succeeded.

Build status, test results, Git state, crypto detection, verification and deployment status all come from tools.

PQC knowledge

We also did not want the system to rely only on what the model happens to know about post-quantum cryptography.

We collected guidance from published standards and references including:

  • NIST FIPS 203 — ML-KEM
  • NIST FIPS 204 — ML-DSA
  • NIST FIPS 205 — SLH-DSA
  • NIST IR 8547
  • NIST SP 1800-38
  • NIST SP 800-227
  • CNSA 2.0 and related guidance

We converted that knowledge into machine-readable deterministic rules.

Those rules help Proteus decide:

  • what is actually quantum-vulnerable,
  • what kind of cryptographic usage it is,
  • what migration is valid,
  • what must not be changed,
  • and when the system should stop and ask for a human decision.

We also created a separate set of execution rules for baseline capture, test generation, mocks, failure diagnosis, repair, retry limits and escalation.

Together, Proteus currently uses 114 deterministic rules.

Agent architecture

We separated the responsibilities instead of giving one agent everything.

The main roles are:

  • Discovery & Assessment — understands the repository and prepares the migration plan.
  • Migration Engineer — creates tests and performs the approved code changes.
  • Diagnostic reasoning — looks at failures and decides what should be repaired.

That separation matters because the same agent that writes a change should not simply be able to declare its own work correct.

Verification

At the end, Proteus calculates the migration result from nine deterministic checks.

These include:

  • baseline behaviour preserved,
  • build successful,
  • required tests passed,
  • prohibited crypto removed,
  • required PQC present,
  • approved scope respected,
  • no critical blockers,
  • sandbox deployed,
  • end-to-end behaviour verified.

The verifier does not ask Gemini for the verdict.

Technology

Proteus is built using:

Frontend: React, TypeScript, Firebase Authentication
Backend: Node.js, Fastify, Genkit
AI: Gemini through Vertex AI
Data: MongoDB Atlas
Google Cloud: Compute Engine, Cloud Storage, Secret Manager, Cloud Logging
Engineering: GitHub, Docker and Maven

The complete system is running on Google Cloud.

Challenges we ran into

The hardest part was making the agent autonomous without making it unsafe.

A migration can compile and still be wrong. Tests can also pass for the wrong reasons — for example, if an assertion was weakened or a mock was changed in a way that hides the real problem.

So we had to be very clear about what the agent is allowed to reason about and what must be checked independently.

Another challenge was that crypto migrations often touch several related files at once. If you judge every intermediate file change separately, the application may look broken even though the migration is only halfway through.

That led us to introduce change sets, so related changes can move together before the system decides whether the migration failed.

We also found several cases where stale build or test artifacts could make a failed run look successful. That pushed us to make the evidence much stricter and tie every result to the current execution.

Accomplishments that we're proud of

The biggest thing for us is that Proteus actually completes the loop.

It can:

Discover → Understand → Plan → Migrate → Fail → Diagnose → Repair → Verify → Deploy

without needing an engineer to guide every step.

We are also proud that it knows when not to change something.

In our reference application, Proteus found 12 cryptographic findings and migrated only 4.

The rest — including RSA signatures, hashing, symmetric encryption and unrelated protocol configuration — were identified and intentionally left alone.

That is important because blindly replacing every RSA occurrence would be dangerous.

We also like that the final result is easy to verify.

You get the migrated branch, the rule decisions, the test and verification results, and a live sandbox where the migrated application can actually be used.

What we learned

One of the biggest lessons was that PQC migration is not really an algorithm replacement problem.

The difficult part is understanding all the relationships around the cryptography:

application code, purpose, dependencies, tests, protocols, certificates, HSMs and external systems.

We also learned that giving an agent more autonomy actually requires stronger boundaries.

Gemini is very good at reasoning, code generation and dealing with unexpected failures. But basic facts — did the build pass, did the test run, is the old crypto still present — should come from tools.

And finally, observability matters a lot. Recording the model inputs, outputs, rule decisions and tool results made the system much easier to debug and improve.

What's next for Proteus - An autonomous Post-Quantum Migration Engineer

The current version proves the application-level migration loop.

Next, we want to expand into:

  • ML-DSA signature migration
  • certificate and PKI migration
  • HSM and hardware-backed cryptography
  • more programming languages and crypto libraries
  • protocol and interoperability analysis
  • more graph-driven migration planning

The bigger opportunity is fleet-scale migration.

An enterprise may have hundreds or thousands of applications that need to move to PQC. Proteus can evolve from handling one repository at a time into a system that prioritises an entire estate and runs many migrations safely in parallel.

The goal is simple:

What used to take months of specialised engineering work should take days.

Proteus is our attempt to make enterprise-scale PQC migration actually feasible.

Built With

Share this project:

Updates