Architektur

Palveron arbeitet in zwei Modi, die unabhängig oder zusammen genutzt werden können — Enforcement Gateway für Traffic, den Sie routen können, Governance Control Plane für Traffic, den Sie nicht routen können.

Enforcement Gateway

Für KI-Systeme, die Traffic über eine API routen, agiert Palveron als transparenter Proxy:

Ihre App → Palveron Gateway → LLM-Provider
                ↓
         Policy Engine (Rust, μs Latenz)
                ↓
         Multi-Modal-Analyse (Text / Bild / Audio / Code)
                ↓
         Trace + Audit-Log → Flare Blockchain

Governance Control Plane

Für KI-Systeme, die nicht proxied werden können — native Plattform-Agenten, SaaS-Tools, browserbasierte KI — bietet Palveron Dokumentation, Compliance-Tracking und Event-Ingestion via Extension API und MCP-Gateway.

Komponenten

Komponente	Technologie	Zweck
Gateway	Rust / Axum	Policy-Enforcement in Quasi-Echtzeit, Trace-Logging, Multi-Modal-Analyse
Dashboard	Next.js 16 / React 19	Admin-UI, Command Center, Agent Registry, Playground
PostgreSQL	Supabase / Self-hosted	Persistente Speicherung, Multi-Tenancy
Redis	Optional	Caching, Blocklisten, Rate Limiting
NGE	ONNX Runtime + 5 Modelle	Lokale Neural-Inferenz — Sub-50-ms-PII, Injection, NLI-Scoring
Flare Relayer	Rust	Merkle-Tree-Berechnung, Blockchain-Verankerung
SDKs	TypeScript, Python, Go, Java	Kunden-Bibliotheken mit Retry, Circuit Breaker, Multi-Modal

Content-Ingestion-Pfade

Palveron unterstützt mehrere gleichwertige Ingestion-Pfade. Jeder Pfad normalisiert auf dasselbe VerifyRequest-Format:

Pfad	Anwendungsfall
SDK / Verify API	Direkte API-Aufrufe aus Ihrem Anwendungscode
Gateway-Proxy	Drop-in-Ersatz für LLM-Base-URLs
MCP-Gateway	Coding-Agents (Cursor, Windsurf, Claude Code)
Extension API	SaaS-Connectors, Webhooks, externe Systeme

Das Gateway unterstützt Text, Bilder, Audio, Dokumente und Code in einer einzigen Anfrage:

VerifyRequest
├── prompt: String
├── attachments: [{ contentType: "image/png", data: Base64, ... }]
└── context: { mcpServer, toolName, chainDepth, sourceSystem }
         ↓
    Content-Type-Erkennung (auto: OpenAI / Anthropic / Palveron-Format)
         ↓
    Provider-Routing: Text → NGE local → optional LLM-Assist
                      Bild → Llama Guard Vision
                      Audio → Whisper → Text-Pipeline
                      Code → Secret Scanner + NGE
         ↓
    Findings zusammenführen → Policies anwenden → Entscheidung

Attachment-Typen verwenden MIME-Strings (keine Enums) — erweiterbar ohne Code-Änderungen. Heute: image/png. Morgen: application/x-lidar-pointcloud.

Neural Governance Engine (NGE)

NGE ist Palverons lokale Inferenzschicht — fünf ONNX-Modelle, die im Gateway laufen und die meisten LLM-Assist-Aufrufe in lokale Calls unter 50 ms verwandeln.

Input → NGE-Pipeline (5 Stufen)
   1. Regex          schnell, deterministisch (Kreditkarten, SSNs, E-Mails)
   2. Aho-Corasick   Multi-Pattern-Keyword-Matching (Denylists, Markenbegriffe)
   3. ONNX NER       Entity-Extraktion (PII NER × 2 + Injection-Detektor)
   4. Contextual     NLI-Semantik-Scoring (Toxicity, Off-Topic, Policy-Intent)
   5. LLM-Assist     Grenzfälle in die Cloud eskalieren (umschaltbar)

Engine-Modi:

Modus	Latenz	Wann einsetzen
`disabled`	n/a — nur Regex + LLM-Assist	Pre-Sprint-54-Verhalten, keine NGE-Inferenz
`nge_local`	~30-50 ms	Nur lokale Modelle — null LLM-Kosten, null externe Calls
`nge_fallback` (Standard)	~30-50 ms + gelegentlich LLM	Local-first; Grenzfälle eskalieren zum LLM-Assist
`llm_only`	~300-800 ms	Lokale Inferenz überspringen, immer Cloud-LLM

Die meisten Kunden fahren nge_fallback — Palverons Daten zeigen, dass dieser Modus 85-95 % der LLM-Assist-Calls eliminiert, bei einem Genauigkeitsverlust von unter einem Prozentpunkt gegenüber llm_only.

Die NGE-Outputs sind Assistance-Signale — sie informieren Policy-Entscheidungen, aber die Policy Engine besitzt weiterhin die finale Entscheidung. Siehe den Neural-Governance-Engine-Leitfaden für die vollständige Pipeline.

Purpose-Bound Entity Governance (PBEG)

Klassische Zugriffskontrolle steuert Entities nach Typ („Agents", „User", „Dokumente"). PBEG steuert Entities nach Purpose — dem deklarierten Zweck der Entity.

Agent: „support-bot-v2"
   ↓
Deklarierter Purpose: „Tier-1-Kunden-E-Mails beantworten. CRM-Tickets lesen. Templated Replies senden. Niemals Rechnungen ausstellen."
   ↓
Aus Purpose abgeleitetes Capability-Modell
   ├── ALLOW    crm.read_ticket
   ├── ALLOW    email.send_templated
   ├── DENY     billing.create_invoice
   └── REQUIRE  approval für crm.bulk_export

Wenn ein Agent eine Aktion außerhalb seines deklarierten Purpose versucht, blockiert Palveron (oder queued für Freigabe) — selbst wenn die Aktion die Content-Checks des Gateways bestehen würde.

PBEG läuft neben, nicht statt der bestehenden EntityGate. PBEG ist die primäre Enforcement-Schicht; EntityGate läuft im Observe-Only-Modus weiter, zur Rückwärtskompatibilität. Der Purpose wird bei der Agent-Registrierung gesetzt und ist eines der ersten Felder, die Auditoren in Annex-IV-Berichten prüfen.

Sicherheitsmodell

Dual-Authentifizierung: API-Key + optional JWT
Multi-Tenancy: Organisation → Projekt-Isolation, erzwungen in der Middleware
RBAC: 5 Stufen — platform_admin, owner, admin, editor, viewer (siehe Rollen & Berechtigungen)
Verschlüsselung: AES-256-GCM at rest, TLS 1.3 in transit
Tamper-Evidence im Audit: Append-only-Traces, Blockchain-verankerte Nachweise
Fehlermodi: Konfigurierbares Fail-Open oder Fail-Closed
Circuit Breaker: Alle SDKs enthalten clientseitigen Circuit Breaker (5 Fehler → offen → 30 s Cooldown)

On this page