Security & data commitments
Neumannic ships with privacy, security, and provider-neutrality as first-class product commitments. This page describes how your data is handled: the zero-data-retention contracts that govern every model provider in our routing chain, the layered defense that protects long-running memory context, the edge filtering that sits between the public internet and our application, the human-gate controls on destructive administrative operations, and the operational substrate that makes those guarantees auditable. Last updated June 21, 2026 · v2.0.
Overview
Neumannic is provider-neutral by design. Every request runs through an abstraction layer that routes to one of nine model providers (selected per integration point and per workspace tier), with zero-data-retention contracts in place at every provider in the routing chain. The platform ships with three layers of defense against memory-poisoning attacks on long-running context, edge filtering in front of our application origin, and human-gate controls on the destructive administrative operations that cannot run unattended. These are commitments we ship at launch, not aspirations — every claim on this page traces to a control that exists in our infrastructure today.
Zero-data-retention posture
Every model provider in our routing chain is configured to drop your prompts and outputs immediately after serving the request. This commitment binds every workspace tier, every integration point, and every provider — there is no faster-cache opt-in path that would forfeit it. The 24-hour cache option some providers offer is structurally forbidden in our codebase rather than merely discouraged, and the prohibition is enforced at three layers: a continuous-integration check that fails any pull request reaching for the forbidden option, an administrator interface that does not surface the option as a selectable value, and a runtime resolver that returns the nearest shorter cache window the provider supports.
When a workspace tier requests a cache window a provider cannot honor (for example, the routing chain has shifted to a provider with shorter retention than the tier configuration requested), the request still succeeds — the resolver records the requested-vs-effective cache window and surfaces the gap to operators rather than failing the customer-visible call. This fail-safe path is intentional: zero-data-retention is the non-negotiable invariant; cache-window degradation is the tunable.
The verbatim contractual wording is in our Privacy Policy.
Multi-provider neutrality
Neumannic is not locked to any one model vendor. Our routing chain includes Anthropic, OpenAI, Qwen (Alibaba Cloud), DeepSeek, Together AI, Fireworks AI, Google Gemini, fal, and Replicate. Each provider handles a distinct integration point — chat, embeddings, vision, image generation — and the per-tier mapping of which provider serves which integration point is configurable by an administrator rather than hardcoded in our source. Image generation specifically defaults to a dedicated diffusion-and-token-priced-image provider, not to any general-purpose chat vendor, because image workloads do not share the same cache and retention shape as text workloads.
The provider-neutrality posture is enforced mechanically. A continuous-integration check scans every pull request for accidental vendor lock-in — direct vendor library imports outside the per-vendor wrapper module, vendor-specific response-shape assumptions in generic application code, or hardcoded vendor names as default selections in shared utilities. The check fails the build on any new violation. The result is that a future migration away from any single vendor is a configuration change rather than an application rewrite.
For the per-tier × per-integration-point routing matrix that governs your specific workspace, see your workspace administration panel or contact us through your account channel.
Memory poisoning defense
Cross-session memory — the long-running workspace and per-user context that lets agents pick up where they left off — is one of the highest-impact attack surfaces in production agentic systems. An attacker who can inject content into a memory store can change agent behavior days or weeks later, long after the original injection vector is forgotten. The industry's coordinated response named this class of attack memory poisoning, and we ship three independent layers of defense against it from day one.
The first layer screens inputs at the point of write — content is run through automated moderation before it is committed to the workspace or user memory store, and high-risk content is held for review rather than auto-saved. The second layer protects stored memory itself: every memory row carries an integrity signature so silent tampering at the storage layer is detectable on read. The third layer screens retrievals — when memory content is pulled into a model request, the retrieval path validates the integrity signature and routes high-trust-decay items through a reviewer queue before they reach the prompt.
The customer-facing summary of how your memory store works — what triggers a review, how recency decay is applied, how to inspect and edit your own memory — is on our memory help page.
Perimeter defense
Public traffic to our application origin passes through a content-delivery network with an integrated web application firewall in front. The firewall runs five managed rule profiles in parallel — a baseline managed ruleset, the OWASP core ruleset, our content-delivery provider's curated rule pack, a free managed ruleset for high-confidence signatures, and a bot-traffic mitigation mode that filters automated probes before they reach our origin. Edge filtering catches the broad signatures — SQL-injection probes, cross-site scripting payloads, server-side-request-forgery probes against cloud metadata endpoints, and similar — before they consume application capacity.
Webhook receive paths for our authentication, billing, email, notification, and durable-execution sub-processors are exempted from edge filtering on a per-route basis so signed provider deliveries are not mistakenly blocked. After they arrive at our application, those webhook routes are re-checked at the application layer through signature verification rather than relying solely on the edge. Static assets ride the content-delivery network's cache for low-latency delivery. The free tier of this perimeter substrate is sufficient for Phase 1 traffic — the posture is intentional, not a constraint we plan to migrate away from at launch.
When edge filtering drops bot traffic, the events surface in our internal audit trail so we have a continuous record of perimeter activity without coupling to any single provider's proprietary log surface.
Wire-up integrity, human gates, and contact
Every backend route declared in our platform specification is classified in a single registry with one of four explicit states — wired to a real handler, partially wired, intentionally stubbed for a planned surface, or not yet implemented. Continuous-integration lint enforces that the registry stays in sync with the route definitions; the platform does not ship orphan endpoints or interface surfaces with no backing implementation. The result is that what a customer sees in the product reflects what is actually wired, not a stub.
Administrative operations with high blast radius — workspace deletion, billing changes, marketing-campaign deployment, subscription tier downgrades, and similar — require an explicit human approval step before they execute. The approval is recorded with a per-event audit row that names the approving administrator, the target of the operation, and the time-bounded approval window. An automated process cannot escalate itself into one of these destructive operations without surfacing the approval request to a human first.
If you have found something that looks like a security issue, please report it to security at neumannic dot com. We acknowledge every report within one business day, follow up with a disposition within seven business days, and operate on a coordinated-disclosure window of ninety days from confirmed report. We do not pursue legal action against good-faith researchers operating under coordinated disclosure.
Authentication
Account access is protected by our authentication provider with passkey-default sign-in, time-based one-time password backup, and recovery codes for account recovery. Multi-factor authentication is enforced for administrative surfaces and is available to all users from account settings. Sign-in attempts are rate-limited at both the edge and the application layer; suspicious patterns trigger automated lockouts with self-service recovery.
Data encryption
All traffic between your browser and our services runs over the latest version of transport-layer security. Data at rest is encrypted at the storage layer using envelope encryption with key rotation. Collaborative document state — the live editing surface for shared documents — is additionally encrypted at rest with a separate key, so operators of our collaboration infrastructure cannot read your document content.
Audit logging
Every administrative action, every workspace permission change, and every data-handling operation runs through an audit log with full payload retained for ninety days and skeleton-row retention thereafter for compliance traceability. The audit log is append-only; entries cannot be edited or deleted by application code. Audit events that match defined high-severity patterns are surfaced through our paging system in real time.
Infrastructure
Our services run on a single managed-cloud provider behind a content-delivery network and web application firewall. The perimeter defense includes managed-rule profiles for the OWASP core rule set, our provider's curated rule pack, and bot-traffic mitigation. Webhook receive paths are exempted from rate-limiting at the perimeter to preserve provider notifications, then re-rate-limited at the application layer with signature verification. Observability — metrics, logs, and traces — runs on self-hosted open-source tooling rather than third-party software-as-a-service, to preserve data-residency control.
Multi-provider model posture
Neumannic routes requests through multiple model providers — never locked to any single vendor. Every provider in our routing chain is configured to drop your prompts and outputs immediately after serving the request. There is no faster-cache opt-in path that would forfeit this commitment.
The integrity-check framework that protects long-running memory context against tampering — input moderation, storage integrity signatures, and retrieval-time review queues — is summarized in plain language above and detailed in our memory help page linked from the memory poisoning defense section.
Vulnerability disclosure
If you have found something that looks like a security issue, please report it to security at neumannic dot com. We acknowledge every report within one business day, follow up with a disposition within seven business days, and operate on a coordinated-disclosure window of ninety days from confirmed report. We do not pursue legal action against good-faith researchers operating under coordinated disclosure.
Incident response
Our paging substrate runs on a self-hosted notification service rather than a software-as-a-service pager, so an outage of a third-party pager cannot prevent our team from responding to an incident. Customer-impacting incidents are communicated through our status page and, for affected workspaces, by email to the workspace owner. Post-incident reviews are conducted within ten business days of resolution and material findings are surfaced in our changelog.
Compliance and certifications
Our SOC 2 Type II audit is in progress; the Type I report is targeted for the third quarter of 2026. We maintain GDPR-aligned and CCPA-aligned data-handling practices. Where a specific certification is required for your enterprise procurement process, please reach out — we can share the relevant compliance documentation under non-disclosure agreement, and our roadmap for additional certifications is shaped by enterprise customer demand.
Effective date and version
This Security page is version v2.0, last updated June 21, 2026. Specific technical details, the current sub-processor list, and the up-to-date compliance posture are maintained internally; security-review questions can be directed to security at neumannic dot com.