This is the public witness for one of Gentian's three product capabilities: a presence-bound record for an answer. Check it offline, against a public key you hold. The verifier states its own limits as fields in its output, so the boundary of the claim travels with the record instead of living in our marketing.
The repository linked below holds a real signed record of an AI response, and a tampered copy of the same record. Verify both on your own machine. The first passes. The second refuses, and tells you why.
No account, no form, no email address. No GPU or network connection. The verifier is included; no additional cybiont software or service is required.
Run it
Clone the repository, or use Download ZIP on the repository page. Then, from inside it:
$ cd device-presence-bound-v1
$ python3 standalone_verify.py valid
{"terminal_status":"PASSED","device_presence_profile":"DEVICE_PRESENCE_BOUND",
"device_locality_claim":false,"workload_execution_claim":false,
"performance_claim":false,"vendor_code_used":false,
"device_certificate_revocation_status":"NOT_COLLECTED",
"signing_key_revocation_status":"NOT_COLLECTED",
"nvidia_spdm_measurement_blocks":52, …} # exit 0
$ python3 standalone_verify.py tampered
{"refusal_code":"PAYLOAD_DIGEST_MISMATCH","terminal_status":"REFUSED"} # exit 2
The only things you install are Python 3 and cryptography. The verifier is a single readable
Python file in the repository; it imports nothing else, and it uses no cybiont library. That is the
"vendor_code_used": false field above, and you can confirm it by reading the file.
Note what the rest of that output is. The boundary of the claim comes back as fields —
workload_execution_claim, device_locality_claim, performance_claim are all false, and both
revocation statuses say NOT_COLLECTED. You are told what this does not cover by the tool, in
machine-readable form, before you have read a word of our prose.
Get the records and the verifier → · Clone or Download ZIP. No account, no form.
The verifier source and both signed records live in one public repository, cybiont/device-presence-bound-record, under the MIT licence. You can read every line before you run it.
Why the failing one matters more
valid/ is a byte-exact sealed record from a real vLLM response on stock, non-confidential NVIDIA
Blackwell hardware.
tampered/ is that same bundle with the response text changed — and then made internally
consistent: the receipt was updated to describe the new text, and the package manifest was
recomputed to match. Everything a forger controls has been made to agree.
It still refuses, because the signature binds the response payload and that cannot be reproduced without the key. The valid record shows the check passing. The altered one shows that a changed response is caught and refused by name — which is how you know the check is doing work, and not simply agreeing with whatever it is handed.
The claim, and its boundary
Establishes: integrity of the retained request-and-response record, and the presence of an enrolled NVIDIA device authorising the signature at the documented point — still checkable after the device and the signing process are gone.
Does not establish: that the named device executed the model, that it was physically local, continuous presence, firmware appraisal, revocation status, or any performance property.
Those same boundaries come back as fields in the verifier's own output, so the tool tells you before we do.
For compliance and internal audit
The package demonstrates one bounded control: an independently checkable integrity record for an AI request and response, which can form part of an audit trail and an internal control system.
- Traceability: the signed commitments identify the recorded model, input, and response.
- Audit trail: the valid and negative-control bundles give a reviewer a repeatable test and a named refusal reason.
- Record integrity: later payload changes are detectable; operational retention and availability remain the deployer's responsibility.
- Internal control: the control has explicit claims, limits, and acceptance behaviour that an auditor can evaluate and rely on within the agreed scope.
What it needs from you
Nothing beyond an existing NVIDIA serving stack is needed for this witness: no secured enclave, hardware change, special mode, or re-platforming. A customer pilot must separately agree record custody, retention, trust coordinates, and key ownership; this public package does not establish a production custody model. Within its stated boundary, it is a control an auditor can evaluate and rely on.
If you want to see it running against your own workload, that is a bounded paid pilot: one workflow, named devices, agreed claims, and acceptance criteria written down in advance.