Compliant inference, by structure.
MeshInfer.AI satisfies NIST 800-63B, SOC 2, HIPAA, and GDPR through unified identity, routing, privacy, and observability controls โ enforced across inference routing, workload sharding, node selection, and model execution.
Identity & Authentication for Inference Nodes (NIST 800-63B)
Every inference node in the mesh is a first-class identity principal under the DOSFI Identity Fabric. Node identity is hardware-backed, cryptographically verifiable, and bound to every routing decision and inference session token it participates in. Authentication strength is calibrated to NIST 800-63B Authenticator Assurance Levels (AAL), with privileged inference operations requiring AAL3-equivalent proof.
Hardware-backed keypairs
| TPM 2.0 (desktop / server) | RSA-3072 and ECDSA P-256 keys generated inside the TPM. Private key never leaves the chip. Attestation measurement included in node registration. |
| Secure Enclave (iOS / macOS) | P-256 keys sealed to the Secure Enclave. Biometric-gated key release for privileged operations. Key migration between devices prohibited by design. |
| Android Keystore (StrongBox / TEE) | Hardware-isolated key storage with attestation. StrongBox-backed keys required for server-tier nodes; TEE acceptable for client-tier. |
| Browser (WebAuthn) | Platform authenticator (TPM/Secure Enclave) or roaming authenticator (FIDO2 security key). Required for browser-based node registration. |
Multi-factor authentication for privileged operations
Privileged inference operations โ model deployment, policy changes, node deregistration, audit log access โ require step-up authentication beyond the baseline session. The DOSFI Identity Fabric enforces this through a layered authenticator model:
| Something you have | Hardware-backed device keypair (TPM / Secure Enclave / Keystore). Always required. |
| Something you know / are | Passkey (FIDO2) or biometric (Face ID / Touch ID / fingerprint) for step-up. Required for privileged operations. |
| Step-up trigger | Privileged operation requested โ Identity Fabric issues a step-up challenge โ user satisfies biometric/passkey โ short-lived elevated token (5 min TTL) issued. |
| Re-authentication | Elevated token expires after 5 minutes or on session idle. Re-challenge required for the next privileged operation. |
Node identity bound to routing and session tokens
A node's hardware identity is not a static credential โ it is bound into every routing decision and inference session it touches. This binding is structural:
- Routing decisions carry the selected node's public key fingerprint. The SDK verifies the decision signature and the node identity match before dispatching.
- Inference session tokens are bound to the node's device key via DPoP (Demonstrating Proof-of-Possession). A stolen token cannot be replayed from a different device.
- Result attestation is signed by the same device key that registered the node. Signature mismatch triggers investigation and reputation penalty.
Short-lived session tokens with continuous validation
| Token lifetime | Inference session tokens are short-lived. Long-running sessions refresh via the Identity Fabric with continuous validation. |
| Continuous validation | Every request re-validates the token against the Identity Fabric revocation list. A revoked node is rejected within one request cycle. |
| Automatic revocation | Nodes that miss consecutive heartbeats, fail verification sampling, or trigger anomaly detection are automatically revoked. No manual intervention required. |
| Token scope | Session tokens are scoped to a single inference session. They cannot be used for administrative operations or cross-session replay. |
Identity lifecycle management
| Key rotation | Automated rotation on a configurable schedule (default: 90 days). Old keys remain valid for a grace period to prevent disruption, then are permanently retired. |
| Revocation lists | Distributed revocation list (CRL) checked on every authentication. Revoked keys are rejected immediately, even if the token is otherwise valid. |
| Node deregistration | Admin-initiated or automatic. Deregistration invalidates all active sessions, evicts the node from the registry, and archives its audit history. In-flight tasks fail over to eligible peers. |
| Compromise response | Suspected key compromise triggers immediate revocation, node quarantine, and forensic audit. Replacement keys require fresh hardware attestation. |
# Rotate a node's device key (admin)
meshinfer-admin nodes rotate-key --node-id node_f9a3e2b1 --reason scheduled
# Revoke a compromised node immediately
meshinfer-admin nodes revoke --node-id node_f9a3e2b1 --reason compromise --force
# Deregister and archive a decommissioned node
meshinfer-admin nodes deregister --node-id node_f9a3e2b1 --archive-auditSecure Routing, Sharding & Policy Enforcement (SOC 2)
The DOSFI Policy Fabric governs every inference request from ingress to execution. Role-based and attribute-based access control (RBAC/ABAC) is evaluated before any routing decision is honored, and every enforcement outcome is written to an immutable, append-only audit chain for SOC 2 evidence.
RBAC / ABAC enforcement on inference requests
| Role claims | Extracted from the OIDC token at the Gateway. Determine the maximum task class, model tier, and privacy policy the caller may request. |
| Attribute claims | Organization ID, subscription tier, data classification, declared purpose, and consent state. Evaluated as ABAC conditions against the routing policy. |
| Policy evaluation | Synchronous at the Gateway, before the Router Engine is invoked. A request that fails policy evaluation is rejected with a 403 and logged. |
| Deny-by-default | If no policy explicitly permits the request, it is denied. There is no implicit allow for any request class. |
Pre-execution request validation
Every inference request passes through a validation pipeline before the Router Engine assembles the candidate node pool. Validation is ordered so that the cheapest checks run first:
- Identity & authentication โ token signature, expiry, revocation status.
- Authorization โ RBAC role + ABAC attributes against the routing policy.
- Privacy gate โ structural check: does the declared privacy policy permit the requested route tier?
- Model eligibility โ is the requested model available on at least one eligible node or cloud provider?
- Rate & quota โ per-key and per-organization usage limits.
A failure at any stage short-circuits the pipeline. No downstream component ever sees a request that failed an earlier check.
Immutable audit logs
The Observability Fabric maintains an append-only hash chain for every compliance-relevant event. Entries cannot be modified or deleted โ only appended. The chain is periodically anchored to external timestamp authorities for non-repudiation.
Deterministic routing with versioned configuration
| Versioned policies | Every routing policy is versioned and immutable once published. The active version is referenced by hash in every routing decision audit entry. |
| Deterministic selection | Given the same input state (policy version, node pool, request attributes), the Router produces the same selection. Exploration is opt-in and logged. |
| Rollback capability | Any policy version can be reactivated instantly. Rollback is itself an audited event with the rolling-back admin identity and reason. |
| Canary & staged rollout | New policy versions can be rolled out to a percentage of traffic with automatic rollback on guardrail breach. |
Mesh-wide monitoring
PHI-Safe Inference & Healthcare Compliance (HIPAA)
Protected Health Information (PHI) receives the strictest routing guarantees in the platform. PHI-tagged workloads are structurally constrained to local-first execution, and any deviation requires explicit, auditable permission declared in the app's Permission Manifest.
Local-first inference for PHI
| Default routing | PHI-tagged requests route to local execution. No network I/O occurs unless the Permission Manifest explicitly permits mesh or cloud routing for PHI. |
| Structural enforcement | The privacy gate resolves synchronously before any dispatch. For PHI with local-only policy, no fetch, no WebSocket message, and no peer dispatch is ever initiated. |
| Mesh routing (opt-in) | Permitted only when the app declares PHI mesh routing in its Permission Manifest AND the user consents. Routed to HIPAA-eligible nodes only. |
| Cloud routing (restricted) | Permitted only for de-identified data explicitly tagged as such. Raw PHI never routes to cloud providers. |
Encrypted inference channels
| Transport layer | TLS 1.3 with certificate pinning for all PHI-related traffic. mTLS for Coordinator-to-node dispatch. |
| Application layer | AES-256-GCM envelope encryption on top of TLS. Task envelopes are encrypted to the destination node public key; only that node can decrypt. |
| Key derivation | Per-session symmetric keys derived from the TLS channel via RFC 5705 exporter. No persistent key material stored on the client. |
| At-rest protection | No PHI is persisted at rest by the platform. Local inference artifacts are ephemeral and cleared on session end. |
Permission Manifest PHI declarations
Apps that process PHI must declare their data usage in a machine-readable Permission Manifest registered with the DOSFI Identity Fabric. The Coordinator enforces these declarations as hard routing constraints:
{
"data_classes": ["phi"],
"phi_routing": {
"local": "always",
"mesh": "opt_in_with_consent",
"cloud": "deidentified_only"
},
"retention": "session_only",
"audit_level": "full",
"consent_required": true,
"purpose_limitation": ["clinical_decision_support", "summarization"]
}PHI-specific audit trails
HIPAA-eligible node gating
Nodes that process PHI must meet elevated security requirements. The Coordinator blocks PHI routing to any node that does not satisfy all of the following:
- Hardware-backed keypair (TPM / Secure Enclave / StrongBox) โ no software-only keys.
- Verified attestation measurement matching a HIPAA-eligible node profile.
- Sandboxed inference process with no network access, no disk write, and no IPC.
- Reputation score above the HIPAA eligibility threshold.
- Geographic region permitted by the organization data residency policy.
Privacy-by-Design Inference Controls (GDPR)
GDPR principles are enforced as structural routing constraints, not runtime policy checks. Data minimization, purpose limitation, and the data subject rights to deletion and export are built into the inference request lifecycle from ingress.
Data minimization
| Manifest-scoped payloads | Inference requests may only contain data fields explicitly declared in the app Permission Manifest. Undeclared fields are stripped at the Gateway before routing. |
| Field-level classification | Each declared field carries a data class (public / personal / sensitive / phi). The class determines eligible route tiers. |
| No metadata leakage | Headers, telemetry, and audit entries carry only the minimum identifiers needed for tracing. No prompt content is logged. |
| Token minimization | Input is tokenized and trimmed to the declared context window. Oversized payloads are rejected, not truncated. |
Consent and purpose tagging
Every inference payload carries a purpose tag and a consent token. The Coordinator blocks routing outside the declared purpose โ this is enforced at the privacy gate, before any node selection occurs.
| Purpose tag | Declared in the Permission Manifest (e.g., summarization, translation, clinical_decision_support). The request purpose must match a manifest-declared purpose. |
| Consent token | Issued by the DOSFI Identity Fabric after user consent capture. Validated at the Gateway. Expired or withdrawn consent โ request rejected. |
| Purpose limitation | A request tagged summarization cannot be routed to a node configured only for translation. The node declared purposes must include the request purpose. |
| Consent withdrawal | Users can withdraw consent at any time. Withdrawal invalidates active sessions and prevents new requests under that consent. |
Right to delete (erasure)
| Local inference data | Cleared on session end by default. On erasure request, any persisted local artifacts (cache, logs) are wiped and the wipe is audited. |
| Cached derivatives | KV-cache, embeddings, and intermediate representations derived from the user data are invalidated. Derivative invalidation is logged. |
| Audit entries | Audit entries are retained for compliance (GDPR Art. 17(3)(b) exemption) but pseudonymized โ the user direct identifiers are replaced with an irreversible hash. |
| Settlement records | DIU settlement records are retained for financial compliance but decoupled from personal identifiers. Erasure does not compromise settlement integrity. |
| Erasure confirmation | A signed erasure receipt is issued to the user and recorded in the audit chain. |
Right to export (portability)
Users can export their inference-related data in machine-readable format through an authenticated endpoint. The export is user-controlled and scoped to the requesting identity:
# Request a personal data export
curl -X POST "https://api.meshinfer.ai/v1/privacy/export" \
-H "Authorization: Bearer msk_live_..." \
-d '{"format": "json", "scope": "all"}'
# Request erasure of personal inference data
curl -X DELETE "https://api.meshinfer.ai/v1/privacy/erase" \
-H "Authorization: Bearer msk_live_..." \
-d '{"scope": "all", "confirm": true}'Privacy-preserving sharding
| Raw personal data | Never sharded. If a request contains raw personal data, it routes to a single node (local or HIPAA-eligible mesh) โ never split across peers. |
| Derived features | May be sharded across mesh nodes only when the Permission Manifest permits it and the data class is not sensitive or phi. |
| Shard isolation | Each shard is encrypted to its destination node. No shard contains enough information to reconstruct the original input without the other shards. |
| Shard audit | Shard assignments, node set, and redundancy flags are logged for every sharded request. |
Inference Engine Security & Trust Controls
Trust in inference outputs depends on trust in the models that produce them. The platform enforces model integrity verification, secure loading, and continuous behavioral monitoring before any model is permitted to execute inference requests.
Model integrity verification before execution
| Hash validation | Every model bundle carries a SHA-256 content hash. The hash is verified against the signed manifest before the model is loaded into memory. |
| Signature check | Model bundles are signed with Ed25519 by the Model Distributor. The signature is verified against the Coordinator published public key. Unsigned or signature-mismatched bundles are rejected. |
| Manifest binding | The signed manifest binds the hash, signature, model identity, quantization level, and compatible runtimes. Any mismatch between manifest and bundle blocks loading. |
| Verification timing | Integrity is verified at load time and re-verified on a schedule. A bundle that fails re-verification is evicted from the node cache. |
Secure model loading
| Sandboxed loading | Model weights are loaded into a sandboxed process with no network access, no disk write, and no IPC. The model cannot exfiltrate data or persist artifacts. |
| Runtime isolation | Each inference session runs in an isolated execution context. Sessions cannot access each other memory, KV-cache, or intermediate state. |
| Memory zeroing | On session end, the inference context memory is zeroed. No residual prompt data remains in the node address space. |
| Supply chain provenance | Model provenance โ base model, fine-tuning dataset hash, quantization pipeline version โ is recorded in the Model Registry and auditable. |
Continuous monitoring for malicious patterns
Mesh-wide policy compliance before execution
No inference request is executed until it has passed every applicable policy check across all four DOSFI fabrics. The enforcement order is fixed and non-bypassable:
- Identity Fabric โ authenticate the caller and verify node identity.
- Policy Fabric โ evaluate RBAC/ABAC and routing policy.
- Privacy/Data Fabric โ enforce data minimization, consent, and purpose limitation.
- Observability Fabric โ emit audit entries for every enforcement outcome.
Only after all four fabrics pass does the request reach the Router Engine for node selection. A failure at any stage produces an audited denial โ never a silent fallback.
Integration with DOSFI & MeshNativeExchange
MeshInfer.AI is the inference fabric layer of the unified DOSFI ecosystem. Its compliance controls are not standalone โ they are the runtime enforcement points for policies defined across the Identity Fabric, Policy Fabric, Privacy/Data Fabric, and Observability Fabric, with economic settlement governed by MeshNativeExchange.
Identity Fabric integration
| Token validation | Every inference request OIDC token is verified against the DOSFI Identity Fabric JWKS. No token from another system is accepted. |
| Node identity | Inference nodes register their hardware-backed keypairs with the Identity Fabric. The Coordinator trusts only Identity-Fabric-attested nodes. |
| Step-up auth | Privileged inference operations trigger step-up authentication through the Identity Fabric, issuing short-lived elevated tokens. |
| Revocation propagation | Identity revocations (user or node) propagate to the Coordinator within one request cycle. Revoked principals are rejected immediately. |
Policy Fabric integration
| Policy source | Routing, privacy, and access policies are authored and versioned in the DOSFI Policy Fabric. The Coordinator consumes published policy versions โ it never authors policy. |
| Evaluation | The Gateway evaluates each request against the active policy version. The policy version hash is recorded in every routing decision audit entry. |
| Federated policies | Cross-organization federated policies (e.g., shared mesh participation rules) are resolved by the Policy Fabric and enforced by the Coordinator. |
| Dry-run & rollback | Policy changes can be dry-run against historical traffic before activation. Rollback to any prior version is instantaneous and audited. |
Privacy/Data Fabric integration
| Permission Manifest | Apps register their data usage declarations with the Privacy/Data Fabric. The Coordinator enforces these as hard routing constraints. |
| Data classification | Field-level data classes (public / personal / sensitive / phi) flow from the Privacy/Data Fabric into routing decisions. |
| Consent state | User consent grants and withdrawals are managed by the Privacy/Data Fabric. The Coordinator treats consent as a routing precondition. |
| Erasure & export | Right-to-delete and right-to-export requests are fulfilled through the Privacy/Data Fabric, which coordinates with the Coordinator to wipe local artifacts and invalidate derivatives. |
Observability Fabric integration
| Audit chain | Every compliance-relevant event is written to the Observability Fabric append-only hash chain. The chain is the system of record for SOC 2, HIPAA, and GDPR evidence. |
| Real-time monitoring | Node health, inference latency, anomaly detection, and security alert streams are published to the Observability Fabric for mesh-wide monitoring. |
| Compliance reporting | Scheduled and on-demand compliance reports are generated from the Observability Fabric audit store, scoped to the requesting organization. |
| Evidence export | Audit evidence packages (for SOC 2 auditors, HIPAA compliance officers, or GDPR DPOs) are exported from the Observability Fabric with cryptographic integrity proofs. |
MeshNativeExchange integration
| App permissions | App-level permissions (rate limits, tier-gated model access, feature flags) are defined in MeshNativeExchange and enforced by the Coordinator before routing or sharding. |
| DIU settlement | Inference metering events flow from the Coordinator Billing Meter to MeshNativeExchange for DIU settlement. Settlement integrity is verified via signed batch hash chains. |
| Spend caps | Per-organization spend caps are checked synchronously at the Gateway. A request that would exceed the cap is rejected with a 402 before any inference begins. |
| Economic compliance | Self-dealing caps, Sybil limits, and conservation checks are enforced at settlement. No inference request benefits from economic exploitation. |
Cross-fabric request lifecycle
Unified Compliance Matrix & Final Requirement
MeshInfer.AI satisfies NIST 800-63B, SOC 2, HIPAA, and GDPR through a single set of unified controls enforced across identity, routing, privacy, and observability. The matrix below maps each framework's requirements to the platform control that satisfies it.
Cross-framework control matrix
Unified fabric enforcement
| Identity Fabric | Single source of truth for user, node, and service identity across all four frameworks. Hardware-backed keys, step-up auth, revocation. |
| Policy Fabric | Versioned, deterministic routing and access policies. RBAC/ABAC evaluation, dry-run, rollback. Enforced identically for NIST, SOC 2, HIPAA, and GDPR. |
| Privacy/Data Fabric | Permission Manifests, data classification, consent state, erasure, and export. Enforces data minimization and purpose limitation structurally. |
| Observability Fabric | Append-only audit chain, real-time monitoring, compliance reporting, evidence export. Single audit store for all four frameworks. |
| MeshNativeExchange | App permissions, spend caps, DIU settlement integrity. Economic compliance layered on top of inference compliance. |
