NiaShield

Security Architecture

Most AI vendors answer a security questionnaire with policy. NiaShield answers it with architecture — properties that hold even if you assume the vendor is hostile. That assumption is the design requirement.

01In-tenant deploymentYour subscription, your boundary

The control plane runs inside your own Azure subscription — Commercial, GCC High, Azure Government, or a European region. Data never crosses your security boundary, because there is no other side to cross to: Heaviside AI operates no servers in the data path.

02Memory-only executionVolatile by construction

Prompts, responses, and intermediate state are processed in volatile memory. Nothing is written to disk, cache, or log storage during AI session handling. Non-retention isn’t a deletion job that runs later — it’s the absence of a write.

03SDIP-6 sanitizationSix passes before reclamation

On session termination, a six-pass cryptographic sanitization routine overwrites session buffers before memory is reclaimed — informed by NIST 800-88 media-sanitization principles, applied to volatile memory. The protocol is the subject of two U.S. provisional patent applications.

04Certificate of IncinerationEvidence, not assurance

Every session closes with a SHA-256 signed receipt attesting to session start, termination, and sanitization. An auditor or a court can verify it without asking us anything. Since May 2026, receipts are non-repudiable — attested by the customer’s own identity provider, with the vendor excluded from the trust chain by architecture.

05American-only model routingBinary-locked on Federal tiers

On the Federal tier, routing is binary-locked to U.S.-headquartered frontier providers. Non-approved SDKs are not in the bundle — the lock is SBOM-verifiable, not a configuration setting. API keys stay with you. Which providers make the roster is governed by the published AI Provider Admission Standard.

06Zero-trust operator postureWe designed ourselves out

Heaviside AI holds no customer keys, no customer data, no session content. We cannot be subpoenaed for what we structurally do not possess — and neither can anyone who compromises us. The vendor is not in your threat model because the vendor is not in your data path.

For the CISO

“Where is your FedRAMP? Where is your SOC 2?”

Asked in every security review. Answered here, plainly — because the honest answer is the strongest one we have.

FEDRAMPThe authorization is Microsoft’sInherited by running in your boundary

NiaShield is not a SaaS, and there is no Heaviside cloud to authorize. The control plane deploys into your own Azure subscription — Commercial, GCC High, or Azure Government — so the infrastructure it runs on is the infrastructure you already accredited: Azure’s FedRAMP High authorization, and the DoD impact levels of Azure Government. We borrow Microsoft’s boundary instead of asking you to trust a new one. The usual question — is the vendor’s cloud authorized? — dissolves, because there is no vendor cloud.

SOC 2No data environment to auditWe hold nothing a report would cover

A SOC 2 report attests to how a vendor protects the customer data it holds. We hold none. No keys, no session content, no telemetry from your sessions, no servers in your data path — there is no Heaviside data environment for an auditor to walk through. In its place you get evidence per session instead of attestation per year: a Certificate of Incineration your own auditor can verify with any independent tool, and an SBOM-verifiable binary for the software itself.

MICROSOFTThe gate we pass throughCertification is enforced, not voluntary

Microsoft does not take software into its marketplace on the vendor’s word. Every offer listed on Azure Marketplace passes Microsoft’s commercial marketplace certification policies — security, privacy, and content requirements checked at publication and again at every update — and Microsoft ISV Co-Sell Ready status adds Microsoft’s own partner vetting on top of that. The security and privacy bar described on this page is not self-imposed; it is enforced by the store we ship through.

MODELShared responsibility, redrawnThe riskiest layer is deleted

The classic model: the cloud secures the infrastructure, the vendor secures its service, you secure your data. Here, Microsoft secures the infrastructure under its own authorizations. You keep custody — your tenant, your keys, your identity provider. And the layer where AI vendors normally accumulate risk — the vendor’s stored copy of your data — does not exist. We did not harden that layer. We removed it.

What we will never do is imply that Microsoft’s certifications are ours. They are Microsoft’s. They cover the infrastructure your deployment runs on, and we name them only so you know whose boundary you are standing in. Our own contribution is architectural and verifiable per session — we would rather hand a CISO one receipt they can check than ten badges they have to trust.

What we claim — and what we don’t

We never claim compliance or accreditation. We hand you the architecture and the evidence — independently verifiable — and the legal conclusions belong to your counsel.

See how the architecture maps to GSAR 552.239-7001, the Presidential AI doctrine, and the EU AI Act →

Prove it yourself

Type anything, incinerate it, and inspect a real SHA-256 receipt. Nothing leaves the page — which is the entire point.