Ein Agent, der alles installieren, alles aufrufen und überall schreiben kann, ist nur sicher, wenn die Grenzen echt sind. Bei Kortix liegen sie unterhalb des Agenten, in der Plattform, wo ein Prompt sie nicht überreden kann.
Eine Sitzung ist kein Tab in einer gemeinsam genutzten Laufzeitumgebung. Sie ist eine eigene Maschine, und die Datenbank lässt nicht zu, dass zwei Sitzungen dieselbe Maschine haben. Die Trennung zweier eigener Sitzungen funktioniert genauso wie die Trennung zweier verschiedener Kunden.
innerhalb einer Sitzung
gelangt nie hinein
Ein Tool benötigt echte Zugangsdaten, um echte Arbeit zu leisten. Die ehrliche Frage ist daher nicht, ob die Maschine jemals einen Schlüssel enthält, sondern welche Maschine welchen Schlüssel enthält, wer das entschieden hat und was niemals hineingelangt.
01
Mit AES-256-GCM unter einem pro Projekt abgeleiteten Schlüssel verschlüsselt.
02
Sowohl die Rolle der Person als auch die deklarierte Berechtigung des Agenten müssen dies erlauben.
03
Beim Start namentlich in der Sitzung abgelegt, auf tmpfs mit Modus 0600.
04
Das Tool liest es aus der Umgebung. Es wird nicht in den Prompt geschrieben.
05
Die Datei wird beim Herunterfahren sicher gelöscht und die Maschine mitsamt ihr zerstört.
Die meisten KI-Tools geben dem Agenten alles, worauf die Person, die ihn gestartet hat, zugreifen kann. Kortix tut das nicht. Eine Agentenidentität bringt eigene Richtlinien mit, die unabhängig ausgewertet werden, sodass sie sich nicht selbst Zugriff auf etwas verschaffen kann, das du ihr nie gewährt hast.
Prinzipal
Ressourcentyp
Berechtigungen gelten für einen Prinzipal, eine Aktion und einen Ressourcentyp.
Integrierte Rollen – in jedem Tarif
account
project
Enterprise
Available on Enterprise, and on a self-hosted instance with an Enterprise license. The built-in roles above are free on every plan.
Ein Dienstkonto ist eine vollwertige Maschinenidentität des Kontos, kein menschliches Token mit aufgesetztem Hut. Richtlinien gelten direkt für es, und jede Anfrage wird ausschließlich anhand seiner eigenen Richtlinien bewertet – sie übernimmt niemals die Reichweite der Person, die es erstellt hat.
Eine Person oder Gruppe kann innerhalb eines Projekts auf benannte Agenten und Skills begrenzt werden: Das Marketing darf diesen Agenten und jenen Skill verwenden, sonst nichts. Alles, was du nicht begrenzt, bleibt projektweit verfügbar. Einschränkung ist also optional, statt später wieder aufgehoben werden zu müssen.
Genehmigung ist keine Einstellung, die in einem Admin-Panel vergraben ist. Sie ist ein Block in kortix.yaml, gemeinsam mit allem anderen versioniert, der festlegt, welche Tool-Aufrufe ausgeführt werden, bei welchen eine Person entscheidet und welche direkt abgelehnt werden.
# reads run; writes and destructive calls stop for a humanpolicy: default_mode: risk policies: # a name-only rule cannot gate the target — conditions can - match: gmail.send_email action: require_approval conditions: - arg: to match: /@example\.com$/ # anything else through this tool is refused outright - match: gmail.send_email action: block # whole connectors can be gated with one glob - match: stripe.* action: require_approvalDrei Aktionen
always_run, require_approval, block. Eine Regel gleicht einen Glob über vollständig qualifizierte Toolpfade ab, sodass eine Zeile einen einzelnen Aufruf oder einen ganzen Connector abdecken kann.
Das Ziel absichern, nicht nur das Tool
„Darf der Agent E-Mails senden?“ ist keine Sicherheitsvorkehrung. Bedingungen gleichen die Argumente ab, sodass die Regel „nur an diese Adressen“ lauten kann. Ein Argument, das nicht ausgewertet werden kann, wird standardmäßig abgelehnt.
Kein pauschales „immer erlauben“
Jeder geschützte Aufruf wird einzeln mit seinen Argumenten vor dir genehmigt. Es gibt keine sitzungsweite Genehmigung, hinter der sich ein späterer Aufruf mit anderen Argumenten verstecken kann – diese Abkürzung wurde am Durchsetzungspunkt entfernt, nicht nur aus der UI.
Lege den gewünschten Standard fest
default_mode: risk lässt Lesevorgänge zu und leitet Schreib- sowie destruktive Aufrufe an eine Person weiter. Ein Projekt ohne Policy-Block behält den freizügigen Legacy-Standard. Lege dies daher ausdrücklich fest.
Ein Agent kann auf seinem eigenen Branch beliebig viel schreiben. Diese Arbeit auf main zu bringen, ist eine separate Fähigkeit, die er nur erhält, wenn du sie bewusst überträgst – und diese Übertragung selbst muss von jemandem genehmigt werden.
Jede Bearbeitung landet auf dem für diese Sitzung erstellten Branch. Nichts, was der Agent tut, ist für eine andere Sitzung oder für main sichtbar.
Wenn der Agent etwas über die Lebensdauer der Maschine hinaus erhalten möchte, committet er es und öffnet einen auf main gerichteten Change Request. Das ist die einzige Tür.
Ein Change Request ist ein Diff. Einen Agenten zu prüfen, der seinen eigenen Prompt umschreibt, funktioniert genauso wie die Prüfung einer Codeänderung – denn es ist eine. Ein Change Request, dessen Manifest nicht validiert werden kann, kann überhaupt nicht zusammengeführt werden.
Zusammenführen ist eine eigene Fähigkeit und wird jedem Agenten verweigert, sofern ein Admin sie nicht gewährt. Diese Gewährung steht in kortix.yaml – ein Agent kann seine Reichweite also nicht ohne einen von jemand anderem genehmigten Change Request erweitern.
Jede Konto- und jede Agentenaktion wird in jedem Tarif erfasst. Der Tarif entscheidet, wer diesen Datensatz lesen, exportieren oder streamen darf – nicht, ob er existiert.
Dasselbe Produkt gibt es als verwaltete Cloud, als Stack in deinem eigenen Netzwerk und als isolierte Bereitstellung. Es ist Open Source, sodass du dem Code vertraust, den du lesen kannst.
Der verwaltete Dienst. Wir betreiben Control Plane und Compute; du betreibst das Unternehmen.
Ein Docker-Compose-Stack auf deiner Infrastruktur, aus denselben Images wie die verwaltete Cloud. Deine Datenbank und Dateien liegen auf von dir kontrolliertem Speicher.
A single-tenant deployment inside your own network. Isolated topologies are scoped with us rather than self-served.
Wo wir tatsächlich stehen
Wir verfügen nicht über ISO 27001 oder HIPAA und erwecken auch nicht diesen Eindruck. Wenn ein Bericht vorliegt, ändern wir diese Zeile noch am selben Tag – nicht vorher.
Bitte eröffne bei einer Schwachstelle kein öffentliches Issue. Sende dem Sicherheitskontakt die betroffene Version oder den Commit, die Reproduktionsschritte und die Auswirkungen.
Sicherheitskontakt
security@kortix.comWir nennen auf Wunsch die Namen der meldenden Personen, sobald ein Fix veröffentlicht wurde.
Beginne mit einer Aufgabe und wachse von dort aus.