ยง Compliance ยท Security Integration

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.

1

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.
No software-only nodes in production
Nodes without a hardware-backed keystore cannot register for production mesh participation. They may run local inference only โ€” never receive dispatched tasks from the Coordinator.

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 haveHardware-backed device keypair (TPM / Secure Enclave / Keystore). Always required.
Something you know / arePasskey (FIDO2) or biometric (Face ID / Touch ID / fingerprint) for step-up. Required for privileged operations.
Step-up triggerPrivileged operation requested โ†’ Identity Fabric issues a step-up challenge โ†’ user satisfies biometric/passkey โ†’ short-lived elevated token (5 min TTL) issued.
Re-authenticationElevated 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 lifetimeInference session tokens are short-lived. Long-running sessions refresh via the Identity Fabric with continuous validation.
Continuous validationEvery request re-validates the token against the Identity Fabric revocation list. A revoked node is rejected within one request cycle.
Automatic revocationNodes that miss consecutive heartbeats, fail verification sampling, or trigger anomaly detection are automatically revoked. No manual intervention required.
Token scopeSession tokens are scoped to a single inference session. They cannot be used for administrative operations or cross-session replay.

Identity lifecycle management

Key rotationAutomated rotation on a configurable schedule (default: 90 days). Old keys remain valid for a grace period to prevent disruption, then are permanently retired.
Revocation listsDistributed revocation list (CRL) checked on every authentication. Revoked keys are rejected immediately, even if the token is otherwise valid.
Node deregistrationAdmin-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 responseSuspected key compromise triggers immediate revocation, node quarantine, and forensic audit. Replacement keys require fresh hardware attestation.
bash
# 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-audit
2

Secure 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 claimsExtracted from the OIDC token at the Gateway. Determine the maximum task class, model tier, and privacy policy the caller may request.
Attribute claimsOrganization ID, subscription tier, data classification, declared purpose, and consent state. Evaluated as ABAC conditions against the routing policy.
Policy evaluationSynchronous at the Gateway, before the Router Engine is invoked. A request that fails policy evaluation is rejected with a 403 and logged.
Deny-by-defaultIf no policy explicitly permits the request, it is denied. There is no implicit allow for any request class.
Client-supplied values are never trusted
The subscription tier, data classification, and privacy policy used for routing are always taken from the verified token โ€” never from the request body. A client cannot escalate its own privileges by modifying request parameters.

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:

  1. Identity & authentication โ€” token signature, expiry, revocation status.
  2. Authorization โ€” RBAC role + ABAC attributes against the routing policy.
  3. Privacy gate โ€” structural check: does the declared privacy policy permit the requested route tier?
  4. Model eligibility โ€” is the requested model available on at least one eligible node or cloud provider?
  5. 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.

Audit eventCaptured fieldsRetention
Inference requestrequest_id, caller identity, org, model, privacy policy, declared purpose, timestamp7 years
Node selectionrequest_id, selected node_id, selection criteria, reputation score, timestamp7 years
Routing decisionrequest_id, route tier, decision signature, policy version, timestamp7 years
Model shardingrequest_id, shard assignments, node set, shard redundancy flag, timestamp7 years
Policy enforcementrequest_id, policy_id, decision (allow/deny), evaluated conditions, timestamp7 years

Deterministic routing with versioned configuration

Versioned policiesEvery routing policy is versioned and immutable once published. The active version is referenced by hash in every routing decision audit entry.
Deterministic selectionGiven the same input state (policy version, node pool, request attributes), the Router produces the same selection. Exploration is opt-in and logged.
Rollback capabilityAny policy version can be reactivated instantly. Rollback is itself an audited event with the rolling-back admin identity and reason.
Canary & staged rolloutNew policy versions can be rolled out to a percentage of traffic with automatic rollback on guardrail breach.

Mesh-wide monitoring

SignalSourceAlert thresholdResponse
Node healthHeartbeats + health checksDegraded/offline transitionTraffic weight reduced; eviction after sustained failure
Inference latencyPer-request telemetryp95 exceeds SLOReputation penalty; node deprioritized
Anomaly detectionBehavioral telemetry streamStatistical deviation from baselineInvestigation flag; auto-quarantine if critical
Security alertsAuth failures, policy denials, signature mismatchesSpike above baselineRate-limit escalation; admin notification
3

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 routingPHI-tagged requests route to local execution. No network I/O occurs unless the Permission Manifest explicitly permits mesh or cloud routing for PHI.
Structural enforcementThe 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.
Raw PHI never leaves the originating device by default
This is a structural guarantee, not a configurable preference. The only way to route PHI to mesh or cloud is through an explicit Permission Manifest declaration reviewed and approved by the organization compliance officer.

Encrypted inference channels

Transport layerTLS 1.3 with certificate pinning for all PHI-related traffic. mTLS for Coordinator-to-node dispatch.
Application layerAES-256-GCM envelope encryption on top of TLS. Task envelopes are encrypted to the destination node public key; only that node can decrypt.
Key derivationPer-session symmetric keys derived from the TLS channel via RFC 5705 exporter. No persistent key material stored on the client.
At-rest protectionNo 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:

json
{
  "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

Audit fieldDescriptionHIPAA relevance
Accessed byIdentity of the caller (user or service) that initiated the PHI inference request164.312(b) โ€” Access control
Processing nodeNode ID and device identity that executed the inference164.312(b) โ€” Audit controls
TimestampPrecise UTC timestamp of access and processing164.312(b) โ€” Audit controls
PurposeDeclared purpose from the Permission Manifest164.312(c) โ€” Integrity
Route tierlocal / mesh / cloud โ€” with mesh/cloud requiring explicit consent164.312(e) โ€” Transmission security
Consent stateWhether user consent was captured and valid at request time164.312(a) โ€” Access control

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.
4

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 payloadsInference requests may only contain data fields explicitly declared in the app Permission Manifest. Undeclared fields are stripped at the Gateway before routing.
Field-level classificationEach declared field carries a data class (public / personal / sensitive / phi). The class determines eligible route tiers.
No metadata leakageHeaders, telemetry, and audit entries carry only the minimum identifiers needed for tracing. No prompt content is logged.
Token minimizationInput 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 tagDeclared in the Permission Manifest (e.g., summarization, translation, clinical_decision_support). The request purpose must match a manifest-declared purpose.
Consent tokenIssued by the DOSFI Identity Fabric after user consent capture. Validated at the Gateway. Expired or withdrawn consent โ†’ request rejected.
Purpose limitationA request tagged summarization cannot be routed to a node configured only for translation. The node declared purposes must include the request purpose.
Consent withdrawalUsers can withdraw consent at any time. Withdrawal invalidates active sessions and prevents new requests under that consent.
Consent is a routing precondition
Consent is not checked after routing โ€” it is a precondition for routing. A request without valid consent for its declared purpose never reaches the Router Engine.

Right to delete (erasure)

Local inference dataCleared on session end by default. On erasure request, any persisted local artifacts (cache, logs) are wiped and the wipe is audited.
Cached derivativesKV-cache, embeddings, and intermediate representations derived from the user data are invalidated. Derivative invalidation is logged.
Audit entriesAudit entries are retained for compliance (GDPR Art. 17(3)(b) exemption) but pseudonymized โ€” the user direct identifiers are replaced with an irreversible hash.
Settlement recordsDIU settlement records are retained for financial compliance but decoupled from personal identifiers. Erasure does not compromise settlement integrity.
Erasure confirmationA 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:

Export itemFormatScope
Inference request historyJSON / CSVAll requests initiated by the user, with timestamps, models, and route tiers
Consent recordsJSONConsent grants, purposes, and withdrawal events
Usage & billing summaryJSON / CSVToken counts, costs, and savings per period
Audit trail (personal)JSONAudit entries referencing the user, pseudonymized for third parties
bash
# 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 dataNever sharded. If a request contains raw personal data, it routes to a single node (local or HIPAA-eligible mesh) โ€” never split across peers.
Derived featuresMay be sharded across mesh nodes only when the Permission Manifest permits it and the data class is not sensitive or phi.
Shard isolationEach shard is encrypted to its destination node. No shard contains enough information to reconstruct the original input without the other shards.
Shard auditShard assignments, node set, and redundancy flags are logged for every sharded request.
5

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 validationEvery model bundle carries a SHA-256 content hash. The hash is verified against the signed manifest before the model is loaded into memory.
Signature checkModel 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 bindingThe signed manifest binds the hash, signature, model identity, quantization level, and compatible runtimes. Any mismatch between manifest and bundle blocks loading.
Verification timingIntegrity is verified at load time and re-verified on a schedule. A bundle that fails re-verification is evicted from the node cache.
No unsigned models execute
A model that cannot be verified โ€” missing signature, hash mismatch, or unknown signer โ€” is never loaded. There is no override, no bypass flag, and no admin escape hatch. This is a structural guarantee of the runtime.

Secure model loading

Sandboxed loadingModel 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 isolationEach inference session runs in an isolated execution context. Sessions cannot access each other memory, KV-cache, or intermediate state.
Memory zeroingOn session end, the inference context memory is zeroed. No residual prompt data remains in the node address space.
Supply chain provenanceModel provenance โ€” base model, fine-tuning dataset hash, quantization pipeline version โ€” is recorded in the Model Registry and auditable.

Continuous monitoring for malicious patterns

Detection classSignalResponse
Malicious inference patternPrompt injection signatures, output exfiltration attempts, jailbreak patternsRequest blocked; caller flagged; admin alert
Unauthorized routingRequests bypassing the Gateway, forged routing decisions, direct node-to-node trafficNode quarantined; identity revoked; forensic audit
Anomalous node behaviorStatistical deviation in latency, output distribution, or verification pass rateReputation penalty; traffic weight reduced; investigation
Model drift / tamperingOutput distribution shift beyond baseline, hash re-verification failureModel evicted from cache; re-distribution triggered
Credential abuseAPI key reuse across IPs, rate-limit evasion, token replayKey revoked; caller suspended; security alert

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:

  1. Identity Fabric โ€” authenticate the caller and verify node identity.
  2. Policy Fabric โ€” evaluate RBAC/ABAC and routing policy.
  3. Privacy/Data Fabric โ€” enforce data minimization, consent, and purpose limitation.
  4. 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.

6

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 validationEvery inference request OIDC token is verified against the DOSFI Identity Fabric JWKS. No token from another system is accepted.
Node identityInference nodes register their hardware-backed keypairs with the Identity Fabric. The Coordinator trusts only Identity-Fabric-attested nodes.
Step-up authPrivileged inference operations trigger step-up authentication through the Identity Fabric, issuing short-lived elevated tokens.
Revocation propagationIdentity revocations (user or node) propagate to the Coordinator within one request cycle. Revoked principals are rejected immediately.

Policy Fabric integration

Policy sourceRouting, privacy, and access policies are authored and versioned in the DOSFI Policy Fabric. The Coordinator consumes published policy versions โ€” it never authors policy.
EvaluationThe Gateway evaluates each request against the active policy version. The policy version hash is recorded in every routing decision audit entry.
Federated policiesCross-organization federated policies (e.g., shared mesh participation rules) are resolved by the Policy Fabric and enforced by the Coordinator.
Dry-run & rollbackPolicy changes can be dry-run against historical traffic before activation. Rollback to any prior version is instantaneous and audited.

Privacy/Data Fabric integration

Permission ManifestApps register their data usage declarations with the Privacy/Data Fabric. The Coordinator enforces these as hard routing constraints.
Data classificationField-level data classes (public / personal / sensitive / phi) flow from the Privacy/Data Fabric into routing decisions.
Consent stateUser consent grants and withdrawals are managed by the Privacy/Data Fabric. The Coordinator treats consent as a routing precondition.
Erasure & exportRight-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 chainEvery 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 monitoringNode health, inference latency, anomaly detection, and security alert streams are published to the Observability Fabric for mesh-wide monitoring.
Compliance reportingScheduled and on-demand compliance reports are generated from the Observability Fabric audit store, scoped to the requesting organization.
Evidence exportAudit 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 permissionsApp-level permissions (rate limits, tier-gated model access, feature flags) are defined in MeshNativeExchange and enforced by the Coordinator before routing or sharding.
DIU settlementInference metering events flow from the Coordinator Billing Meter to MeshNativeExchange for DIU settlement. Settlement integrity is verified via signed batch hash chains.
Spend capsPer-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 complianceSelf-dealing caps, Sybil limits, and conservation checks are enforced at settlement. No inference request benefits from economic exploitation.
Unified trust boundary
The five DOSFI ecosystem systems share a single identity fabric and a single audit chain. A compliance event in MeshInfer.AI is verifiable in the same audit store as an identity event in DOSFI.ai or a settlement event in MeshNativeExchange โ€” no cross-system reconciliation gaps.

Cross-fabric request lifecycle

StageFabricEnforced control
1. IngressIdentity FabricToken signature, expiry, revocation check
2. AuthorizationPolicy FabricRBAC role + ABAC attributes vs. routing policy
3. Privacy gatePrivacy/Data FabricData class, consent, purpose limitation
4. App permissionsMeshNativeExchangeTier-gated model access, spend cap, rate limit
5. RoutingCoordinator (MeshInfer)Node selection, reputation, model availability
6. ExecutionCoordinator (MeshInfer)Sandboxed inference, model integrity, result attestation
7. MeteringMeshNativeExchangeDIU issuance, spend debit, conservation check
8. AuditObservability FabricAppend-only hash chain entry for every stage
7

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

Control domainNIST 800-63BSOC 2HIPAAGDPR
Identity & authenticationHardware-backed keypairs, AAL3 step-up, short-lived tokensUnique user identification, authentication policyPerson/entity authentication (164.312(d))Lawful basis, accountability (Art. 5(2), Art. 32)
Access controlRBAC + ABAC, deny-by-defaultLogical access controls, least privilegeAccess control, role-based (164.312(a))Data minimization, purpose limitation (Art. 5)
Routing & policy enforcementNode identity bound to routing decisionsPolicy versioning, rollback, deterministic routingTransmission security, routing constraints (164.312(e))Purpose limitation enforced at routing (Art. 5(1)(b))
Audit & loggingSession token validation loggedImmutable audit logs, monitoring, alertsAudit controls, access logging (164.312(b))Accountability, records of processing (Art. 30, 32)
Privacy & data protectionConsent as routing preconditionData classification, retention policyPHI local-first, encrypted channels (164.312(e))Data minimization, consent, erasure, export (Art. 5, 7, 17, 20)
Model & engine trustHardware attestation for model loadingChange management, integrity verificationIntegrity controls (164.312(c))Integrity, confidentiality (Art. 5(1)(f), 32)
Monitoring & responseContinuous token validation, auto-revocationAnomaly detection, security incident responseAutomatic logoff, breach notificationBreach notification (Art. 33-34), DPIA (Art. 35)

Unified fabric enforcement

Identity FabricSingle source of truth for user, node, and service identity across all four frameworks. Hardware-backed keys, step-up auth, revocation.
Policy FabricVersioned, deterministic routing and access policies. RBAC/ABAC evaluation, dry-run, rollback. Enforced identically for NIST, SOC 2, HIPAA, and GDPR.
Privacy/Data FabricPermission Manifests, data classification, consent state, erasure, and export. Enforces data minimization and purpose limitation structurally.
Observability FabricAppend-only audit chain, real-time monitoring, compliance reporting, evidence export. Single audit store for all four frameworks.
MeshNativeExchangeApp permissions, spend caps, DIU settlement integrity. Economic compliance layered on top of inference compliance.
Final requirement โ€” satisfied
MeshInfer.AI is a fully compliant, enterprise-grade inference engine that satisfies NIST 800-63B, SOC 2, HIPAA, and GDPR through unified identity, routing, privacy, and observability controls. Every inference request โ€” from ingress to settlement โ€” passes through all four DOSFI fabrics before execution, with every enforcement outcome recorded in an immutable audit chain.

Compliance attestation & evidence

FrameworkEvidence sourceAttestation cadence
NIST 800-63BIdentity Fabric attestation logs, key rotation recordsAnnual + on key rotation
SOC 2 Type IIObservability Fabric audit chain, policy version historyAnnual
HIPAAPHI audit trails, access logs, encryption proofsAnnual + on incident
GDPRConsent records, processing logs, erasure receipts, DPIAContinuous + on request