Standardmasige Enterprise-Hygiene, sorgfaltig umgesetzt.

Der grosste Teil der Sicherheitsarbeit auf einer Plattform dieser Art ist Standard. Verschlusselung im Ruhezustand. Verschlusselung beim Transport. Secrets, die auf einzelne Workers begrenzt sind. Schlussel, je Umgebung isoliert. Eine dokumentierte Incident-Response-Prozedur. Ein Responsible-Disclosure-Programm. Nichts davon ist neu. Die Arbeit besteht darin, jeden Teil sorgfaltig, mit Fail-Closed-Standards und ohne Entwicklungsumgehungen umzusetzen.

Diese Seite beschreibt, wie jeder Teil implementiert ist. Die vollstandige Durchsetzungsmatrix befindet sich im Engineering-Sicherheitsdokument; diese Version ist das, was Sie lesen mussen, um ein Sicherheitsteam zu briefen.

Aller Objektspeicher (Cloudflare R2, AWS S3, On-Premise MinIO sowie Azure uber einen S3-kompatiblen Endpunkt) wird im Ruhezustand mit dem Standard-AES-256 des Plattformanbieters verschlusselt. Alle Durable-Object- und Datenbankspeicherung erbt denselben Standard. Aller Worker-zu-Worker- und Worker-zu-Speicher-Traffic lauft uber TLS 1.2 oder hoher, und ausgehende Aufrufe zu Anthropic und ElevenLabs handeln TLS 1.3 aus.

Schlussel sind je Umgebung und je Worker begrenzt. Die Entwicklungsumgebung teilt nie einen Schlussel mit der Produktion, und die Datenebenen-Workers teilen nie Schlussel mit den Betreiberebenen-Workers. Der Anmeldedaten-Tresor jedes Workspace ist unter einem Schlussel versiegelt, der allein fur diesen Workspace abgeleitet wird. Fur Deployments, die kundenverwaltete Schlussel erfordern, wird wahrend des Engagements eine KMS-Integration auf der gewahlten Cloud verdrahtet (AWS KMS, Azure Key Vault oder das Cloudflare-Aquivalent).

Jedes Secret lebt in genau einem Worker. Es gibt keine gemeinsamen HMAC-Schlussel, keine kopierten Bearer-Tokens, keine umgebungssubergreifende Wiederverwendung. Der Ingestion-Worker halt das Webhook-Signing-Secret. Der Operations-Worker halt das Admin-Bearer-Secret. Der Engine-Worker halt den LLM-API-Key. Der Query-Worker halt das Read-Side-Bearer-Secret. Der Canvas-Worker halt das Matrix-Mutation-Secret.

Workers, die miteinander kommunizieren mussen, verwenden Cloudflare-Service-Bindings (oder das Aquivalent auf AWS, Azure, On-Premise). Service-Bindings tragen die Identitat des Aufrufers nativ. Es gibt keinen gemeinsamen Signing-Key, der zwischen Workers kopiert wird. Die Kompromittierung des Secrets eines Workers kaskadiert nicht in den Blast-Radius eines anderen Workers.

Workers schlagen fail-closed, wenn beim Start ein erforderliches Secret fehlt. Der Worker startet, verweigert den Dienst und protokolliert den fehlenden Secret-Namen. Es gibt keinen Fallback-Pfad, der still mit einer Standard-Berechtigung bedient.

Die Plattform sperrt, bevor sie leckt. Die Fail-Closed-Checkliste wird auf jedem Worker ohne Ausnahme in Entwicklung oder Staging erzwungen:

• Webhook-HMAC-Signatur auf jedem eingehenden Webhook. Fehlende oder falsche Signatur gibt 401 zuruck ohne Body-Lesen und ohne Speicherschreiben.
• Bearer-Token bei jedem Betreiber-API-Aufruf. Fehlender, fehlgeformter oder widerrufener Token gibt 401 zuruck ohne ausgehenden Downstream-Aufruf.
• Rollen-Gate auf jeder authentifizierten Route. Gultige Token plus falsche Rolle gibt 403 zuruck.
• Matrix-Eigentumerschafts-Prufung bei jeder Canvas-Mutation. Der Aufrufer muss der Matrix-Eigentumer sein; sonst 403. Dieselbe Fail-Closed-Postur deckt die Canvas-Oberflache in ihrem ausgelieferten Zustand ab.
• Token-Budget-Prufung vor jedem LLM-Aufruf. Budgetuberziehung gibt eine Budget-Exceeded-Lineage-Zeile zuruck und keinen Aufruf.
• Prompt-Hash-Prufung vor jedem Anreicherungsaufruf. Eine Prompt-Template-Abweichung schlagt fail-closed mit einer prompt_drift-Lineage-Zeile. Keine stillen Bearbeitungen bereitgestellter Prompts.
• Ausgabe-Schema-Validierung bei jeder LLM-Antwort. Nicht-validierende Ausgabe schlagt fail-closed; die Roh-Antwort wird im Ergebnis-Blob fur die Forensik aufbewahrt.

Wenn ein Entwickler jemals ein "Auth fur lokale Tests uberspringen"-Flag mochte, ist das der Moment, in dem wir eine Schwachstelle liefern. Die Entwicklungsumgebung verwendet ein separates Secret mit derselben Durchsetzung.

Jede Abfragemethode auf der Lese-API erfordert ihren Scope-Key (Matrix-Identifier, Organisations-Identifier) als typisiertes Positionsargument. Ihn wegzulassen ist ein TypeScript-Kompilierungsfehler. Er wird zur Build-Zeit gepruft, bevor die Laufzeit-Autorisierung eine Chance hat.

Jede HTTP-Route enthalt den Scope-Key im Pfad, nicht in einem Abfrageparameter. Die Handler-Signatur erfordert ihn. Es gibt keine "Alles-auflisten"-Route, bei der ein Tenant-Filter still weggelassen werden konnte. Wenn die Plattform einen zweiten Organisations-Scope hinzufugt (aktuelle Deployments sind single-organisation), erkennt der Kompilierungsfehler jeden Ort, der aktualisiert werden muss.

Jede zustandsandernde Operation schreibt bereits in einen Append-Only-Speicher. Webhook-Ingest schreibt in den Data-Lake-Index. Canvas-Bearbeitungen schreiben einen neuen Plan-Version-Blob mit beibehaltener Vorversion. Engine-Envelopes schreiben eine Lineage-Zeile fur jeden LLM-Aufruf: Modell-Identifier, Token-Zahlen, Dauer, Status und ein Zeiger auf den Ergebnis-Blob. Budget-Ausgaben erhohen eine Zahler-Zeile.

Es gibt keine separate "Audit-Log"-Funktion, da das gesamte System das Audit-Log ist. Ein Betreiber, der einen Vorfall untersucht, fragt die vorhandenen Tabellen ab. Die Antworten sind bereits dort. Es gibt keinen Zeilen-Loschpfad in der Plattform. Der Einwilligungswiderruf wird durch einen Tombstone gehandhabt, der den Zugriff auf ein Gesprach blockiert, anstatt die Geschichte zu loschen, sodass die Aufzeichnung dessen, was geschehen ist, intakt und manipulationssicher bleibt.

Vorfalle werden an einen namentlich genannten Bereitschaftsdienst weitergeleitet. Die Prozedur hat funf Schritte: den Vorfall bestatigen, betroffene Anmeldedaten einfrieren, den betroffenen Zustand aus den Append-Only-Speichern aufzeichnen, den Blast-Radius aus den Lineage-Zeilen identifizieren und die Behebung durchfuhren. Das Runbook wird mit dem Engagement veroffentlicht.

Die Kundenbenachrichtigung ist vertraglich gebunden. Bei einem bestatigten Datenvorfall, der Befragten-Daten betrifft, benachrichtigen wir den Kunden innerhalb von 24 Stunden nach der Bestatigung. Die Benachrichtigung enthalt die Kompromittierungs-Zeitstempel, den Blast-Radius, die durchgefuhrte Behebung und den Audit-Pfad, den wir zur Feststellung dieser Fakten verwendet haben.

Ein Post-Incident-Review wird schriftlich innerhalb von zehn Geschaftstagen geteilt. Das Review benennt die Ursache, die architektonische Anderung, die eine Wiederholung verhindert, und die Verifizierung, die wir durchgefuhrt haben, um zu bestatigen, dass die Anderung greift.

Sicherheitsforscher, die eine Schwachstelle finden, konnen sie an security@nexaintel.ai melden. Wir bestatigen den Eingang innerhalb von zwei Geschaftstagen. Wir verpflichten uns zu einer Behebung oder einem dokumentierten Minderungszeitplan innerhalb von funfzehn Geschaftstagen bei hochgradigen Problemen, dreissig Geschaftstagen bei mittelschweren. Wir nennen den Forscher in der Empfehlung, es sei denn, er zieht Anonymitat vor.

Wir leiten keine rechtlichen Schritte gegen gutglaubige Forschung ein, die den Offenlegungszeitplan einhalt. Wir behalten uns das Recht vor, die offentliche Offenlegung zu verzogern, bis die betroffenen Deployments gepatcht sind.

Die Plattform ist nach den Kontrollanforderungen aufgebaut, die HIPAA, SOC 2 Typ II, Loi 25 Quebec und DSGVO prufen. Die Architektur liefert das Substrat fur diese Kontrollen: In-Tenant-Deployment, No-Training- und No-Retention-Vereinbarungen mit den LLM- und Sprachpartnern, der Append-Only-Audit-Pfad, der Tombstone-Mechanismus fur den Einwilligungswiderruf und die je Deployment festgelegte Regionsplatzierung.

Bei einem In-Tenant-Deployment gehoren die massgeblichen Zertifizierungen zu Ihrer Infrastruktur. Die Plattform lauft innerhalb des Cloud-Kontos, das Sie bereits auditieren liessen, sodass Ihre SOC-2-, HIPAA- oder regionale Bescheinigung sie genauso abdeckt wie alles andere, was Sie betreiben. Fur Kaufer, die Unterstutzung wunschen, ist ein verwaltetes Deployment verfugbar, bei dem Nexa unter Vertrag einen grosseren Teil des Stacks betreibt.

Die Unterauftragsverarbeiter-Bescheinigungen (Cloudflare, Anthropic, ElevenLabs), unser DPA, die Unterauftragsverarbeiterliste und ein aktueller Sicherheitsfragebogen sind unter NDA verfugbar uber Kontakt. Bei einem In-Tenant-Deployment bewertet Ihr Team die Plattform gegen Ihr eigenes Rahmenwerk.