Tenant-Isolation wird als Architekturgrenze gedacht
Workspaces, Policies, Secrets, Connector-Freigaben und Storage-Kontexte werden tenant-aware modelliert, statt nur in UI-Ebenen getrennt zu werden.
Security
Trust durch klare Grenzen statt ueberspannter Versprechen
Das Sicherheitsmodell wird hier als Architektur- und Betriebslogik formuliert: Tenant-Isolation, Provider-Key-Vault, Data Boundaries, Logging und Action Permissions fuer Dokumente, Arena-Sessions und Hintergrundjobs mit nachvollziehbarem Geltungsbereich.
Trust Layer
Sicherheitslogik wird klar, aber nicht ueberzogen formuliert
Die Plattformseite will Vertrauen aufbauen, ohne Dinge zu behaupten, die spaeter deployment-spezifisch fuer Dokumente, Provider oder Hintergrundjobs entschieden werden muessen.
Secrets gehoeren in kontrollierte Inject-Pfade
Provider-API-Keys, Connector-Zugaenge und sensible Schluessel sollen nicht in Skill Packs oder Oberflaechen verstreut sein, sondern ueber die Plattform kontrolliert bereitgestellt werden.
Logs unterscheiden Betrieb von Inhalt
Operational Telemetrie, Audit-Signale und kundennahe Historie haben unterschiedliche Sichtbarkeits- und Aufbewahrungslogiken.
Action Permissions werden explizit
Agenten handeln nicht pauschal. Connectoren, Tools, Broker-nahe Aktionen, Dokumentenoperationen und kritische Hintergrundjobs muessen an Tenant, Plan, Skill Pack und Rolle gekoppelt werden koennen.
Keine ueberzogenen Compliance-Versprechen
Die Plattformseite beschreibt ein sauberes Zielbild und klare Grenzen. Deployment-spezifische Garantien haengen spaeter vom gewaehlten Runtime- und Betriebsmodell ab.
Kontrollmodell vor Blackbox
Kunden, Partner und Operatoren sollen nachvollziehen koennen, welche Ebene sichtbar ist, welche Grenzen gelten und wer welche Hebel bedienen darf.
Data Boundaries
Sensible Daten, Logs und Action Permissions bleiben getrennte Themen
Gerade bei agentischen Systemen ist die Trennung zwischen Customer Content, Dokumenten-Vault, Provider-Keys, Betriebsdaten und aktiven Tools entscheidend fuer ein glaubwuerdiges Sicherheitsmodell.
Boundary
Tenant-Isolation wird als technische und operative Grenze beschrieben.
Boundary
Secrets und Connector-Freigaben bleiben in kontrollierten Pfaden.
Boundary
Logs, customer-facing history und Audit-Signale werden unterschiedlich behandelt.
Kontrollmodell
Nicht jeder Nutzer sieht oder darf dasselbe
Die Plattform ist spaeter auf Rollen, Support-Sichten, Operator-Controls und Self-Service ausgelegt. Genau das braucht ein tenant-aware Agent-System mit Dokumenten- und Job-Kontext.
Customer controls
Kundenseitige Views fuer Status, Usage, Connector-Freigaben und sichtbare Workspaces.
Operator controls
Plattformseitige Eingriffe fuer Provisioning, Governance, Rollouts und Eskalationen.
Support and audit
Saubere Grenzen zwischen Betriebsnotwendigkeit, Auditfaehigkeit und kundennaher Transparenz.
Trust
Sicherheitslogik wird stark, wenn sie zur Betriebslogik passt
Genau deshalb ist die Security-Seite nicht von Architektur, Runtime und Deployment getrennt, sondern Teil derselben Plattformgeschichte.