Introducing DeviceProphet AI Assistant

Embedded-security reviews often begin with a familiar pile of evidence: a boot diagram, a SoC manual, key-provisioning notes, an update design, and several statements that almost, but not quite, agree. The difficult part is rarely finding the phrase “secure boot.” It is tracing what is actually verified, which key authorizes it, where that key came from, and what happens when the product changes in the field.

DeviceProphet AI Assistant was built to make that first analysis faster and more disciplined. It is now released as a separate product alongside the online Device Prophet Digital Auditor. The assistant runs as a local workflow and is available by direct contact rather than as a public self-service tool.

From documents to an evidence map

The assistant works with architecture and security material deliberately supplied for a review: boot-flow descriptions, platform documentation, provisioning and PKI designs, key-management rules, firmware-update and recovery plans, and remote-attestation evidence. It does not need private signing keys, and it is not presented as a source-code scanner.

Its first job is to turn fragmented material into a structure an engineer can challenge:

  • security facts tied to the source that supports them;
  • boot, identity, key, and attestation dependencies;
  • contradictions and unsupported assumptions;
  • missing evidence and questions for the engineering team; and
  • an explicit validation state for facts that were extracted, independently checked, or left for human confirmation.

This matters because a feature list is not an implementation. A datasheet may say that secure boot is supported while the product evidence never shows that the production fuse state enables it. A bootloader may be verified while a later image is loaded without authentication. A device certificate may exist while ownership enrollment, revocation, or recovery remains undefined. A move from today’s PKI to post-quantum algorithms may affect boot ROM, secure elements, factory tooling, HSM policy, update formats, and backend services at the same time.

The assistant helps expose those hand-offs early. It can distinguish “supported” from “enabled and enforced,” trace who controls each key, highlight missing rollback or recovery evidence, and map cryptographic dependencies that make future migration difficult.

Faster, and more useful to review

In applicable internal analyses, the assistant has reduced first-pass analysis time by more than 50 percent. This is an internal workflow observation, not a benchmark, customer promise, or service-level target.

The more important improvement is what the saved time buys. First passes are more complete and consistent. Evidence is easier to trace. Contradictory statements are less likely to disappear inside long documents. Follow-up questions arrive earlier, when an engineer can still answer them or find the missing artifact. The result is not an automatically correct architecture or compliance verdict; it is a stronger, reviewable starting point.

Models assist; evidence decides

DeviceProphet AI Assistant supports multiple LLM APIs and customer-local or customer-controlled endpoints. With customer-local inference, supplied evidence stays inside that environment. If a customer selects a remote model API, the context sent to it crosses into that provider’s trust boundary; the deployment discussion must make that explicit. Enclave-isolated delivery can also be arranged for sensitive environments, with the precise guarantees depending on the selected platform.

Models accelerate extraction, retrieval, comparison, and the preparation of useful questions. They do not receive final authority. Consequential facts are checked against original evidence, deterministic rules remain deterministic, and an engineer decides what is accepted.

DeviceProphet AI Assistant is released and available by contact. If you want to discuss an embedded boot, device-identity, attestation, or cryptographic-architecture review, ask about access.