The ML attack surface spans three planes — the model, the data, and the infrastructure it runs on. Most defenses live in the first two. A whole class of attacks lives in the third, and that is where a hardware-rooted identity changes the game.
When people say "ML security," they usually mean the model plane: adversarial examples that fool a classifier, prompts that jailbreak a chatbot, poisoned training data that plants a backdoor. Those are real, and they deserve the attention they get. But they aren't the whole picture. Underneath every model is a physical machine, a set of weights, and an execution — and a growing share of the most damaging attacks target that layer: stealing the model, swapping it, running it somewhere it was never authorized to run, and leaving no evidence behind.
That third plane — infrastructure, provenance, and integrity — is exactly what a silicon-rooted identity is built to defend. It won't make your model robust to adversarial inputs. It will make it impossible to run your model on a machine that can't prove it's the approved one, and impossible to alter what ran without leaving a tamper-evident trace. Here's the honest map of what that covers, and what it doesn't.
What unites this first group is that each one is, at heart, an identity, provenance, or integrity question — "is this the approved machine?", "is this the approved model, unaltered?", "who is accountable for this run?" Software alone can't answer those, because the thing doing the answering is the same software an attacker may already control.
Most infrastructure-plane ML attacks reduce to one of two claims being false: "this is the approved machine," or "this is the approved model, unchanged." UBIQS makes both provable.
Being precise about the boundary is what makes the rest credible. A silicon-rooted identity does not make a model robust to adversarial inputs, clean up a poisoned training set, or stop a prompt injection. Those are model- and data-plane problems, and they need model- and data-plane defenses: robustness training, data governance and provenance at training time, application guardrails, differential privacy and output controls.
What UBIQS adds underneath them is a substrate those defenses can stand on and be measured against. If you deploy a hardened, tested model, UBIQS lets you prove that that model — the one you validated — is the one that actually ran, on an approved machine, and nothing was quietly swapped in afterward. And where confidential computing protects the data while it's in use, UBIQS binds that protection into a persistent node identity and a signed record rather than leaving it as a point-in-time assertion.
Every model-level defense you build assumes the model you hardened is the model in production, running where you think it is. That assumption is precisely what infrastructure-plane attacks break. A hardware-rooted identity turns that assumption into something you can verify on demand — and hand to a regulator, an auditor, or an incident responder as evidence. It doesn't replace the ML security you already do. It gives it a foundation that can't be copied, forged, or quietly swapped out from underneath.
Confidential computing protects what runs. UBIQS proves which enrolled machine ran it — and composes with the TEE.
Read →The portable, tamper-evident record that ties the physical node, the model, and the policy to a result.
Read →We're talking with teams who want provenance, integrity, and accountability rooted in hardware — underneath the model-level defenses they already run.