Back to Home

Trust Center

Evidence for teams that need AI security to be provable.

NeutralAI combines a policy boundary, encrypted tokenization, audit evidence, and deployment choices for regulated teams adopting AI.

Request security reviewSecurity overview

Current posture

Readiness, not theater

SOC2 readinessIn progress

Mapped to Security, Availability, and Confidentiality. This is not a certification claim.

RuntimeLive

Public gateway endpoints are available behind TLS for launch and customer evaluation.

EvidencePrepared

Readiness report and questionnaire prefill are available for enterprise review under NDA.

Control Areas

Security, availability, and confidentiality controls.

Policy boundary

NeutralAI sits before external AI providers so sensitive prompt data can be inspected, masked, and governed before egress.

Data minimization

The product is designed around masking, tokenization, and zero-retention operating patterns rather than broad prompt storage.

Encrypted tokenization

Vault payloads use encrypted tokenization with tenant-bound context for governed restore paths.

Audit evidence

Control events, benchmark artifacts, readiness reports, and evidence manifests support security review conversations.

Availability posture

Health checks, readiness endpoints, rollback procedures, and measured latency evidence are part of the operating model.

Incident response

Escalation, containment, post-incident review, and customer communication workflows are documented.

Data Flow

Where your data goes — and what stays inside.

Every prompt passes through the NeutralAI gateway boundary before reaching an external model. Raw PII is detected, tokenized, and audited inside that boundary. Only the sanitized version ever leaves.

Prompt egress — outbound

Prompt Egress Data-Flow DiagramA data-flow diagram showing how a user prompt passes through the NeutralAI Gateway. The flow is: User / Client sends a prompt to the Gateway; within the gateway boundary, Presidio NER and pattern matching detect PII entities; detected entities are masked or tokenized and the tokens are stored in an AES-256-GCM encrypted Token Vault with a TTL; an immutable Audit Trail records every detection event; and only the sanitized prompt (with no raw PII) is forwarded to the external LLM Provider.NEUTRALAI GATEWAY BOUNDARY — RAW PII DOES NOT CROSS THIS LINEUser / ClientApp or extensionpromptDetectPresidio NER+ Pattern matchMask / TokenizeAES-256-GCM vaultReversible tokensanitized onlyLLM ProviderOpenRouter / BYOK🔐Token VaultAES-256-GCM encryptedTenant-bound · TTL 15 minGoverned restore path onlystore token📋Audit TrailDetection eventsEntity types loggedImmutable append-onlylog event🚫Raw PIInever crosses boundarymasked before egresszero retention defaultMain flowToken storeAudit eventGateway boundaryFig 1 — NeutralAI prompt egress: PII detected, tokenized, and audited inside the gateway boundary before LLM forwarding.

Response ingress — unmask path

LLM Response Ingress and Unmask Flow DiagramA data-flow diagram showing how an LLM response is processed on the way back to the user. The LLM Provider sends a response containing masked tokens to the NeutralAI Gateway. Inside the gateway boundary, the stream unmasker checks each token. If a token is present, it performs a governed vault lookup against the AES-256-GCM encrypted Token Vault using the tenant-bound context and TTL check. If recovery is authorised, the original PII value is re-inserted and the unmasked response is streamed back to the User. If recovery is not authorised or the token has expired, the masked placeholder is preserved and delivered as-is. The audit trail records all unmask events.NEUTRALAI GATEWAY BOUNDARYLLM ProviderOpenRouter / BYOKresponse(masked tokens)Stream UnmaskerToken detectionAuthorisation checkVault LookupTenant-bound contextTTL + authz checkUser / ClientUnmasked responsestreamed back🔐Token VaultAES-256-GCM encryptedTenant-bound · TTL 15 minAuto-expire on TTLquery tokenrecover value✓If authorisedOriginal value re-insertedAudit event writtenStreamed to client🛡If NOT authorisedToken TTL expired, orauthz check failedMasked placeholder keptauthz failMain flowVault queryToken recoveryAuthz fail / redactFig 2 — NeutralAI response ingress: tokens recovered only via governed vault lookup; expired or unauthorised tokens remain masked.

Token vault lifecycle

Token Vault Lifecycle DiagramA four-stage lifecycle diagram for tokens in the NeutralAI Token Vault. Stage one: Tokenize — a PII entity is detected and replaced with a reversible token. Stage two: Store Encrypted — the token and its original value are stored in the AES-256-GCM vault with a fifteen-minute TTL and tenant-bound context. Stage three: Recover — only an authorised governed restore call can retrieve the original value before TTL expiry. Stage four: Expire — after TTL elapses the token and value are automatically purged; no recovery is possible after expiry.01 / TOKENIZEPII detectedEntity replaced withreversible token IDe.g. <EMAIL_abc12>02 / STOREAES-256-GCMTenant-bound contextTTL: 15 min defaultRedis w/ key rotation03 / RECOVERGoverned restoreAuthorised path onlyBefore TTL expiryOriginal value re-inserted04 / EXPIREAuto-purgeTTL elapses → token deletedNo recovery after expiryZero-retention by defaultFig 3 — Token vault lifecycle: tokenize → store encrypted with TTL → governed recovery → automatic expiry and purge.VAULT KEY ROTATION SUPPORTED · LEGACY KEY DECRYPTION VIA VAULT_LEGACY_ENCRYPTION_KEYS · FAKEREDIS IN LOCAL DEV MODE

Enterprise Evidence

Ready for security review.

The public site keeps claims conservative. For procurement and security teams, NeutralAI can provide structured readiness materials through the review process.

SOC2 readiness report for enterprise security review
Security questionnaire prefill for common procurement questions
PII detection benchmark narrative and holdout benchmark guardrails
Latency benchmark summary that separates NeutralAI overhead from model generation
Pen-test readiness and remediation SLA tracker
Compliance evidence cadence and monthly package automation

Claim Boundary

SOC2 readiness is in progress.

NeutralAI has not completed a formal SOC2 audit.

Detailed evidence is shared through Security and Legal review, usually under NDA.

Public claims are intentionally narrower than internal readiness artifacts.

Customer Proof Framework

Publish proof only after approval gates clear.

We keep public trust copy conservative until customer evidence is approved. Publication gates, approved proof types, and wording guardrails are documented in the customer proof framework before any public customer claim goes live.

Current posture

No customer logos or testimonials are published on this site until approved assets are recorded through the framework workflow.

Approved proof types

  • Named customer quote only after written customer approval and Legal sign-off
  • Anonymized case study approved by Compliance and Legal
  • Measured pilot summary with documented timeframe and limits
  • Usage-count claim tied to a repeatable analytics source and owner sign-off
  • Benchmark evidence linked to source scope and caveats

Wording guardrails

  • No invented customer logos, testimonials, or usage numbers.
  • No blanket compliance guarantees for customer deployments.
  • No independent-validation language unless a public third-party report exists.

Self-service

Get the security pack

Download the security summary instantly — encryption posture, SOC 2 control mapping, and prefilled questionnaire answers. For detailed artefacts or NDA-scoped review, the security team follows up by email.