The recent announcement from NEAR AI regarding a third-party security attestation for their "IronClaw" runtime is, on its surface, a welcome development. In an industry rife with theatrical vendor demos and self-commissioned "audits," an external review is a step towards accountability. However, before we accept this as validation of a truly secure system, we must scrutinize the unstated foundation of any such attestation: the threat model.

A security attestation is only as meaningful as the parameters under which it was conducted. The press release and accompanying blog post are conspicuously silent on the specifics of the evaluated threat model, which renders the entire exercise of limited utility. My primary concerns revolve around three likely—and problematic—assumptions baked into such a commercial evaluation:

* **The Cloud-Centric Assumption:** The attestation likely evaluates IronClaw within a standard cloud deployment, where the runtime's integrity is contingent on the security of the hypervisor, the host OS, and the cloud provider's own controls. This does not address the threat of a compromised cloud infrastructure provider, nor does it satisfy the requirements for handling truly sensitive intellectual property or personal data. An air-gapped, on-premises deployment presents a fundamentally different attack surface.
* **The Telemetry Blind Spot:** Does the attestation consider the data exfiltration potential of the runtime's own telemetry and logging channels? Many "secure" runtimes maintain phoning-home functions for diagnostics and usage metrics, which can become a channel for prompt leakage or model inversion attacks. A robust evaluation must treat these outbound connections as part of the trusted computing base.
* **The Simplified Adversary:** Vendor-sponsored assessments often model an external attacker attempting classic prompt injections. They frequently neglect more sophisticated, realistic threats such as:
* A malicious insider with partial system access.
* Supply-chain attacks compromising the model weights or the runtime's own tooling dependencies.
* Lateral movement from a compromised adjacent service in a microservices architecture.
* Physical access scenarios relevant to edge deployments, which NEAR's blockchain-adjacent context might imply.

Without public access to the attestation report's scope of work, we are left to guess. I propose that for any such announcement to be taken seriously within a security community, the following must be disclosed:

* The exact version and configuration of the IronClaw runtime that was tested.
* The full System Under Test (SUT) diagram, detailing all components considered in-scope and, critically, those declared out-of-scope.
* The specific trust boundaries defined for the assessment.
* The classes of attack that were simulated (e.g., direct prompt injection, indirect injection via retrieved context, tool/output interference, etc.).
* The attestation company's methodology for evaluating runtime integrity and isolation guarantees.

The move towards third-party review is positive, but it is merely a beginning. We must demand transparency that allows for peer review and independent verification. Otherwise, we are merely trading one form of marketing—the flashy demo—for another: the opaque seal of approval. The field of on-device and confidential AI requires benchmarks and evaluations that are ruthlessly honest about their limitations, and that begin with a comprehensively documented threat model. This announcement, as it stands, does not meet that bar.