Security is not a feature we add to our products. It is the condition under which our products are worth using at all. Neuraphic builds systems that hold other people's identity and other people's words. If those systems cannot be trusted, they cannot be deployed. Everything described here follows from that fact.
Some of what follows describes infrastructure and practices that are already in place. Some describes what we are actively building toward. We distinguish between the two throughout, because we believe honesty about where a system stands is more useful than a polished narrative that papers over the gaps.
Infrastructure security
Our infrastructure is built on a zero-trust architecture. No production service exposes a public IP address directly. Every service sits behind secure tunnels, meaning that even if an attacker identifies a service endpoint, there is no direct network path to reach it. Administrative access is mediated through an identity-aware access proxy that verifies both the identity of the person requesting access and the context of the request (device posture, location, time) before granting it.
Each service runs in its own isolated cloud account with independent access policies, independent credentials, and independent network boundaries. There are no shared networks between services. There are no lateral movement paths. Compromising one service does not grant an attacker access to any other service, because the services do not trust each other by default. Trust is explicit, scoped, and auditable.
This architecture is more expensive to build and more complex to operate than the alternatives. We accept that cost because the alternative, a flat network where a single compromised service exposes everything, is not acceptable for the systems we are building.
Data protection
All customer data is encrypted at rest using AES-256 and in transit using TLS 1.3. These are baseline expectations, not differentiators. What matters more is how we handle data segregation and retention.
Each service runs in its own isolated cloud account, with its own credentials and its own network boundary, so compromising one does not reach another. Within a service, records are scoped to the account that owns them and every query carries that scope; we do not claim physical single tenancy, because that is not what the architecture provides and a claim you cannot evidence is worse than the one you can.
Our API data retention policies define clear timelines for how long data is stored and when it is deleted. Customers can review these timelines and, in many cases, configure them. We do not retain data longer than necessary to provide the service, and deletion means deletion, not soft-deletion, not archival, not "we'll get to it."
Customer-managed encryption keys do not exist here, and there is no date for them. When they exist, this page will say so.
Access controls
Internal access to systems and data follows the principle of least privilege. Every person at Neuraphic has the minimum level of access required to do their work, and no more. Roles are defined explicitly, reviewed regularly, and adjusted when responsibilities change.
All administrative access requires multi-factor authentication. There are no exceptions. We do not allow password-only access to any system that touches customer data, production infrastructure, or security-sensitive tooling.
Every action taken on our systems is logged. These audit logs capture who did what, when, and from where. They are immutable, meaning they cannot be modified or deleted by the people whose actions they record. We review these logs regularly, and we use them as the basis for access reviews that verify whether current access levels remain appropriate.
Security operations
We test our own systems adversarially, and we should be precise about what that means: the testing is internal. No external firm has been engaged, and there is no third-party penetration test report. When one exists, this page will say who performed it and when, because that is the only version of the claim worth anything to somebody reading it during a procurement review.
We maintain documented incident response procedures with defined escalation paths. The useful question is not whether a plan exists but whether it has met a real incident. Ours has, and the result was published in full: five days in which every alarm fired correctly and none of them could reach a human. That write-up includes what was still wrong on the day it went out. It is a better answer to this question than any assertion about preparedness.
We operate a responsible disclosure program for external security researchers. If you find a vulnerability in any Neuraphic system, we want to know about it, and we commit to treating researchers who report responsibly with respect and transparency. We will never pursue legal action against researchers acting in good faith.
For vulnerability reports, contact security@neuraphic.com. For concerns about model safety or AI behavior, contact safety@neuraphic.com. We maintain separate channels because the expertise required to evaluate these two categories of reports is different, and we want each report routed to the people best equipped to act on it.
What does not exist
Collected in one place, because a security page that only lists what a company has is the one document nobody can use. If you are filling in a questionnaire, these are the answers that would otherwise take you three emails to get.
No third-party penetration test report. Testing is internal. No external firm has been engaged.
No SOC 2 report and no ISO 27001 certificate. Both are being worked toward and neither is held. We will not claim either until the report is issued.
No customer-managed encryption keys. Storage is encrypted with cloud-managed keys.
No SAML or SCIM integration, and no enterprise directory provisioning.
No service level agreement, because there are no service contracts. See Availability.
No second region. Everything runs in one region in the United States.
No bug bounty payments yet. The disclosure programme is live; the monetary tier is not.
Compliance
We are transparent about where we stand on compliance certifications, because we believe an honest account is more useful than a list of logos.
SOC 2 Type II. We are pursuing SOC 2 Type II certification. This means we have begun the process of documenting our controls, implementing the organizational policies required, and preparing for the audit engagement. We are not yet certified, and we will not claim to be until the audit is complete and the report is issued.
ISO 27001. We are designing our information security management practices for ISO 27001 compliance. Our internal policies, risk assessment processes, and control frameworks are being built with this standard in mind. Formal certification will follow once our practices have matured to the point where certification reflects reality rather than aspiration.
GDPR. We are compliant with the General Data Protection Regulation. Our Privacy Policy describes the data we collect and why. Our Data Processing Agreement is available to all customers. We have appointed an EU representative as required for non-EU companies processing EU personal data. Our legal policies are written in plain language because we believe people should be able to understand the terms they are agreeing to.
CCPA and CPRA. We are compliant with the California Consumer Privacy Act and the California Privacy Rights Act. California residents can exercise their data rights as described in our privacy policy.
HIPAA. We are planning HIPAA readiness for healthcare customers. This is not yet in place, but we recognize that healthcare organizations deploying AI systems will require Business Associate Agreements and the technical safeguards that HIPAA mandates. We are building with those requirements in view.
FedRAMP. We are planning FedRAMP readiness for government customers. Federal agencies face some of the most stringent security requirements of any sector, and we intend to meet those requirements. This is a long-term initiative that we are approaching methodically.
We will update this page as our compliance posture evolves. When we achieve a certification, we will say so clearly. Until then, we will describe what we are working toward and where we are in the process.
Compliance coverage by product
The certifications and frameworks listed above apply uniformly to the platform that runs every Neuraphic product, but customers procuring under specific regimes need to know which product is in scope of which evidence package. The matrix below is the canonical answer; updates to it are versioned and timestamped on the Trust Center.
| Product | Status | SOC 2 Type II | ISO 27001 | GDPR / CCPA | HIPAA (BAA) |
|---|---|---|---|---|---|
| Workers | Generally available | In scope (audit in progress) | In scope (design) | Compliant | Available on enterprise contract |
| the risk engine | Generally available | In scope (audit in progress) | In scope (design) | Compliant | Available on enterprise contract |
| CLI & Console | Generally available | In scope (audit in progress) | In scope (design) | Compliant | Available on enterprise contract |
| the input classifier | Limited access | Out of scope until general availability | Out of scope until general availability | Compliant | Not yet available |
| the code auditor | Limited access | Out of scope until general availability | Out of scope until general availability | Compliant | Not yet available |
Customers under FedRAMP authority should engage with us directly; FedRAMP authorization is a long-term initiative and the appropriate package for the workload depends on its impact level. Reports, bridge letters, and current evidence are made available under NDA from security@neuraphic.com.
Questions
If you have questions about our security practices, need documentation for a vendor assessment, or want to discuss our compliance posture in more detail, contact us. We take these conversations seriously, and we will respond with the same candor reflected in this page.