Your security stack authenticates users, credentials, and infrastructure. It does not authenticate the model. A substituted model, a distilled copy, a silently updated checkpoint — every credential stays valid. Every audit log looks normal. Only the model has changed.
Every model already carries a structural fingerprint. We built the instrument that reads it.
This is what your policy engine consumes.
The visible edge of 13 papers, 3 technical notes, and 350+ machine-verified theorems.
A modern AI deployment stack typically answers two identity questions well. Artifact identity — what was shipped — is handled by registries, version control, and bills of materials. Agent identity — what software is making this request — is handled by OAuth, SPIFFE, mTLS, and the new agent identity suites from Okta, Microsoft Entra, and NIST's concept paper on software agent identity.
These are real controls. But they authenticate the software harness — the orchestration code, the API gateway, the service mesh. They do not verify the neural network inside it.
The software identity layer can work perfectly while the model identity layer is entirely absent. This is not a future risk — it has already produced public incidents in which authenticated agents served undisclosed model foundations, and poisoned packages passed every integrity check using legitimate credentials.
We have measured this directly: three substitution scenarios executed against a live gateway with real HTTP requests, signed attestation JWTs, and OPA policy enforcement. In every scenario, the workload identity, artifact integrity, and API authentication remained valid. In every scenario, the structural identity measurement detected the substitution and the policy gate denied the request.
Technical notes: Agent Identity Is Not Model Identity · Measured Model Substitution · Zenodo, 2026
Three engagement modes. One escalation path.
Every neural network carries a unique structural fingerprint — not from what it says, but from the geometry of how it decides what to say. The fingerprint is a mathematical consequence of the architecture, not something anyone inserted.
This end-to-end path — from forward pass through signed claim to policy decision — has been validated at 70 billion parameters in approximately 30 seconds.
Not a replacement. The layer none of them provide.
Watermarks require insertion at training time and are removed by fine-tuning. Model cards describe artifacts, not running systems. Behavioral tests measure what a model says, not what it is. Output monitoring watches downstream effects without verifying upstream identity. Each solves a real problem. None answer the structural question.
| Property | Watermarks | Model Cards | Behavioral Tests | Output Monitoring | Structural Fingerprint |
|---|---|---|---|---|---|
| Works without training-time insertion | ✗ | — | ✓ | ✓ | ✓ |
| Survives fine-tuning | ✗ | — | Partial | — | ✓ |
| Survives distillation | ✗ | ✗ | ✗ | ✗ | ✓ |
| Works without weight access | ✗ | ✓ | ✓ | ✓ | ✓ |
| Verifies the running model, not a document | Partial | ✗ | Partial | ✗ | ✓ |
| Cryptographically verifiable | ✗ | ✗ | ✗ | ✗ | ✓ |
| Formally proved unforgeable | ✗ | ✗ | ✗ | ✗ | ✓ |
| Composable with existing auth stack | ✗ | — | ✗ | Partial | ✓ |
The best deployment uses several of these together. Watermarks where you control training. Behavioral tests for capability monitoring. Output monitoring for safety. And structural fingerprinting for the one question the others can't answer: is this still the model you approved?
Admitted.Model-identity attestations compose with existing enterprise authorization infrastructure — OAuth 2.0, SPIFFE, SCIM — without protocol modifications. The fingerprint travels as a compact claim inside a standard JWT or SPIFFE SVID.
Report ID: FR-2026-5B127509 Date of Measurement: 2026-03-17T08:43:15Z Verification Result: PASS MODEL Identifier: Mistral-7B Architecture: transformer Weight File Hash: [redacted] Evidence Class: Structural (individual model identity) Trust Mode: TEE-backed (hardware-attested measurement) MEASUREMENT Fingerprint Dims: 64 Valid Measurements: 64/64 (0% failure) FINGERPRINT VERIFICATION Fingerprint Digest: [redacted] Bundle Digest: [redacted] Match: UNIQUE (0 collisions across 6-model zoo) ATTESTATION CHAIN CPU (Intel TDX): CC State ON, Ready state ready GPU (NVIDIA CC): H100 80GB HBM3, CC mode active Binding: gpu_nonce = SHA256(bind_root) [verified] TRUST BOUNDARY DISCLOSURE This certificate verifies STRUCTURAL IDENTITY only. It does NOT verify: performance, safety, fitness for purpose, training data, or regulatory compliance. ISSUED BY: Fall Risk AI, LLC | integrations@fallrisk.ai | fallrisk.ai
Sensitive fields redacted for public display. Full certificate issued to authorized parties only.
| Deployment Mode | Who Measures | Who Signs | Who Trusts |
|---|---|---|---|
| SaaS | Fall Risk | Fall Risk issuer | Customer configures Fall Risk as trusted issuer (like Auth0 or Okta) |
| Enterprise | Fall Risk | Customer-scoped key | Customer trusts only their scoped key — full tenant isolation |
| Sovereign | Fall Risk (measuring authority) | Customer signs | Customer owns the trust chain — Fall Risk provides measurement only |
Ten security properties of the composition are formally classified: four proved in Coq, three traced to existing standards, one implemented, two design-constrained. Zero silent assumptions. Download technical brief →
A Fall Risk Advisory is a structured operational record. It documents a measured threat to model identity continuity, names the affected models, describes the detection method, and recommends actions for relying parties. Where the papers establish what is provable, advisories establish what has been observed in the wild.
Each advisory carries a stable identifier of the form FRA-YYYY-NNN. The canonical home is attest.fallrisk.ai/advisories/ — the same authority surface that issues the signed registry.
Every scenario below succeeds while the agent identity stack reports green. The credentials are valid. The attestation passes. The audit log looks normal. The model changed.
Scenarios A, B, and C have been measured against a live gateway with real HTTP requests, signed attestation JWTs, and OPA policy enforcement. Three substitutions tested, three detected, zero false accepts.
Abliterated checkpoints across two model families and three toolchains are structurally detectable at hardened measurement depth: Gemma 317.5–2,319.4×ε, Llama 7.6–53.1×ε. Sentinel panel 5/5 PASS across four families.
In April 2026, the LiteLLM supply-chain compromise escalated: Mercor, a $10B AI recruiting startup working with OpenAI and Anthropic, confirmed breach via the poisoned LiteLLM package. Over 1,000 SaaS environments affected. LiteLLM routes AI model requests for an estimated 36% of cloud environments — the model-routing layer that CAT-1 named as an incident class two days after the initial compromise.
These scenarios are grounded in public incident patterns and the architecture described in draft-klrc-aiagent-auth-01 (IETF, March 2026). They do not resolve by strengthening agent authentication. They resolve when structural model identity is composed into the existing agent identity infrastructure.
Four capabilities. Each answers a different question about the model in your deployment.
Not every endpoint is attestable. Some providers do not expose logprobs, some expose too few, and some produce degenerate distributions. The first step in any engagement is an INTAKE assessment: a free eligibility check that determines whether the endpoint supports measurement and at what confidence tier. A "cannot attest" finding is itself a compliance-relevant result — it means no one can verify which model is running, including you.
Each headline is an instance of the problem this system was built to solve. Tags mark the threat class.
The EU AI Act and NIST Generative AI Profile are moving toward requiring cryptographic model traceability — not just documentation, but verifiable identity. The four-level framework maps directly to those requirements. Paper VIII in this series extends the mapping into a formal admissibility standard: each compliance question has an evidence class that can answer it, and evidence from the wrong class incurs inferential debt. Documentation identifies artifacts. Evidence identifies models.
| Framework level | What it establishes | EU AI Act | NIST GenAI Profile (AI 600-1) |
|---|---|---|---|
| Structural fingerprinting IT-PUF · weights regime |
Unambiguous, unforgeable model identity — independent of operator claims | Art. 11 (technical documentation), Art. 49 + Annex VIII (unambiguous identification and traceability) | GV-6.2: contracts specifying provenance expectations; MS-2.5: monitoring adherence to provenance standards |
| Hardware-attested binding TEE · enclave measurement |
Cryptographic binding of fingerprint to specific weight artifact — tamper-evident deployment record | Art. 12 (automatic logging, audit trail integrity), Annex IV §2 (system description with sufficient detail to assess conformity) | MS-2.6: detection of unauthorized changes; GV-1.7: organizational risk policies covering third-party model supply chain |
| Verified computation path ZK circuit · hybrid verifier |
Proof that the identified model computed honestly — not just that some weights were used | Art. 13 (transparency, output traceability for downstream providers), Art. 17 (quality management: verification that deployed system matches documented system) | MS-2.5: provenance of model outputs; MP-2.3: documenting AI system decisions in regulated contexts |
| Output binding Token logit · evidence bundle |
Traceable link from verified identity through verified computation to a specific output — the audit record closes | Art. 12 §1(d): logs must enable identification of input data and attribution of outputs; Art. 26 (deployer obligations: monitor, log, maintain records) | GV-6.2: content provenance at output level; MS-4.2: real-time monitoring of deployed model behavior against documented baseline |
This mapping is descriptive. It identifies where the framework's technical capabilities are relevant to stated regulatory requirements — it does not constitute a compliance certification. The EU AI Act high-risk provisions take full effect August 2026.
EU AI Act — Regulation (EU) 2024/1689, Official Journal of the European Union.
eur-lex.europa.eu
NIST AI 600-1 — Generative Artificial Intelligence Profile, National Institute of Standards and
Technology.
doi.org/10.6028/NIST.AI.600-1
Each paper opened a question the previous one could not answer. Thirteen papers. Three technical notes. Zero retracted.
Admitted.Admitted.
Fall Risk AI, LLC · New Orleans, Louisiana
Anthony Coslett is an independent researcher studying the structural identity
of neural networks. He is the sole principal investigator of the Fall Risk AI
research program. Evidence from the research has been placed into proceedings
at the EU AI Office, NIST, and the IETF.
The name Fall Risk comes from the inherent fragility of identity itself. Whether human or artificial, identity has the capacity to suddenly collapse. By labeling the AI as a “fall risk,” we are acknowledging that vulnerability and building the structural measurement tools necessary to ensure its safety — and the safety of the enterprises built around it.
One model family. One integration point. One governance outcome.
Includes: enrollment of your model(s), signed attestation, integration with one policy engine (OPA, Cedar, Envoy, or SPIFFE), and a governance assessment.
Mutual NDA available on request — legal@fallrisk.ai