Press Release

The AI dilemma we don't have

Sep 30, 2026
Saadya Chevan
This is some text inside of a div block.
This is some text inside of a div block.
–
This is some text inside of a div block.
,
This is some text inside of a div block.
This is some text inside of a div block.
This is some text inside of a div block.
This is some text inside of a div block.
–
This is some text inside of a div block.
,
This is some text inside of a div block.
This is some text inside of a div block.
This is some text inside of a div block.
No items found.

This is Chapter 1 of a blog series on how AI fits into secure element development, with new chapters released on Wednesdays in the upcoming weeks. Today we set out why openness and AI-assisted review fit together. Next week Chapter 2 will show it running as a release gate: the version-controlled AI skills we use to audit every bootloader release candidate.

‍

How will you review the firmware you shipped today, ten years from now?

Secure elements are now the fastest-growing segment in embedded security. The capability of AI assisted analysis of these components, especially any unknown security weaknesses they have, does not pause. ABI Research puts shipments at 352 million in 2025, rising to 859 million by 2029. Those parts will be in the field well into the 2030s, and for most secure element vendors, that raises an awkward question about how firmware shipped today gets examined a decade from now. Our secure element, TROPIC01, has firmware that’s been public from the start, so the question answers itself.

This is the first of three articles about how AI fits into secure element development as we approach the end of the 2020s. Here we set out why openness and AI-assisted review fit together. Chapter 2 shows it running in production — the version-controlled AI skills that we use to audit every bootloader release candidate. Chapter 3 turns to your side of the problem: how an open secure element shortens evaluation and integration, and where AI-assisted review reliably falls short.

1. How our transparent approach mitigates the dilemma

Transparency changes what AI can do for us in three concrete ways:

  1. What we can send a model
  2. How fast we can send it
  3. Who else can check the result

When we want a large language model to review our code, we can point frontier-grade LLMs at our GitHub. No new exposure, no new risk calculus, nothing left to leak. Being transparent about much of our product means our engineers don’t go through a compliance gauntlet to provide the code we have already published to these models. We trade months of red tape for immediate, unencumbered insight.

Closed vendors on the other hand choose between two options: frontier-model review of their firmware, or protection of the IP inside it. Choose the review and some of your most sensitive work leaves the building. Choose the IP and you accept weaker analysis than any competitor willing to take the risk. Large producers in the secure element space like Infineon and STMicroelectronics both maintain wide portfolios. Every one of those products represents a closed firmware that needs protecting and reviewing.

2. Openness is what makes AI-assisted work auditable

Code written with AI-assistance does not validate itself. It has a failure mode: confident output that is quietly wrong. A model can invent an API that does not exist, or produce logic that is structurally sound and functionally wrong. It is not guaranteed to throw an error, but at the same time can look like working code to anyone or anything that is not reading closely. The accepted fix is human-in-the-loop review, but that only functions if the reviewer can see the diff.

Closed firmware means the secure element vendor is the only party who can check AI-assisted work. Open firmware means customers, independent auditors and other models can each check it themselves.

The wider industry already concedes the principle. ABI Research reports rising demand for third-party attestation verification services such as Intel® Trust Authority, and notes zero-knowledge proofs also being used to enhance attestation — both of these methods have gained traction because self-attestation does not carry trust on its own. Open-source projects in the same space make the point in reverse: transparency builds trust, and proprietary or vendor lock concerns are what keep most players from choosing it anyway.

Where this leaves us

None of this changed how we build TROPIC01. What changed is everyone else's tooling. We do not ask permission to use AI on our own published code, and the reduced internal compliance needs for us gives a speed advantage. Every improvement in frontier models arrives as a review our firmware can immediately receive, whereas, for closed vendors, each new model is a cost to justify again. As AI capability keeps compounding, openness stops being a principle we hold and starts being infrastructure we rely on.

‍

Also read

No items found.
No items found.
Blogs
CAIM1 Integrates TROPIC01: The Resurrection of Objective Reality with Open Security Hardware and Infrastructure

Read more
Blogs
When Your Supplier's Flaw Becomes Your 24-Hour Problem

Read more
Blogs
Who updates the security chip in an EV charging station?

Read more

Get Tropic Square updates, blogs, and resources right to your mailbox

Subscribe to Tropic Square newsletter

For Technical Support

Talk to Technical Team

Get TROPIC01 Devboard

Order Devboard / Samples