Secobo® OS im Detail: wie die Schicht gebaut istSecobo® OS in detail: how the layer is built

Diese Seite ist der technische Teil zur Produktseite. Sie zeigt, wie die gemeinsame Arbeits- und Governance-Schicht gebaut ist: woher das Wissen kommt, wo geprüft wird, was ein Modul bekommt und was bei der Installation passiert.

This page is the technical part that goes with the product page. It shows how the shared layer for work and governance is built: where the knowledge comes from, where the checks happen, what a module receives and what happens at installation.

Die Antwort liegt nicht im KI-Agenten. Er kennt die Regeln nicht, und niemand sollte ihm vertrauen, sie einzuhalten. Die Antwort liegt in zwei Bausteinen: einem Wissensgraphen, der das Wissen des Unternehmens und seine Regeln kennt, und einer Sandbox für KI-Agenten, die sie leicht macht.

The answer does not lie in the agent. It does not know the rules, and nobody should trust it to follow them. The answer lies in two building blocks: a knowledge graph that knows the company’s knowledge and its rules, and a sandbox for AI agents that makes them lightweight.

Der Wissensgraph tut zweierlei. Er ist die Governance-Wahrheit: wer was sehen darf. Und er kennt nicht nur Dokumente, sondern Zusammenhänge: welche Person zu welchem Team gehört, was womit verbunden ist. Ein KI-Agent, der darauf fragt, bekommt Kontext statt Trefferlisten. Für Menschen gilt dasselbe: Sie sehen ihr Unternehmenswissen als Ganzes, nicht als Ordnerbaum.

The knowledge graph does two things. It is the governance truth: who may see what. And it knows not only documents but relationships: which person belongs to which team, what is connected to what. An AI agent that queries it gets context instead of hit lists. The same holds for people: they see their company knowledge as a whole, not as a folder tree.

Nach diesem Agent-in-a-Box-Muster entsteht jeder KI-Agent: unser Assistent Hermes heute, Fach-Agenten für Klassifizierung oder Rezertifizierung morgen. Auch eureIhre Fachabteilungen bauen so eigene Lösungen, risikoarm, weil die Governance nicht bei ihnen liegt, sondern in der Plattform.

Every agent follows this Agent-in-a-Box pattern: our assistant Hermes today, specialist agents for classification or recertification tomorrow. Your own departments build their solutions the same way, with low risk, because governance does not sit with them but in the platform.

So sichern heute fast alle ihre KI-Agenten: Die Schutzregel steht als Text im System-Prompt des Agenten, und alle hoffen, dass das Modell sie befolgt. Solange es funktioniert, merkt niemand, wenn es aufhört. Ein Prompt ist bestenfalls eine eindringliche Bitte, keine Policy.

Einem neuen Kollegen gebt ihr auch keinen Generalschlüssel und die Bitte, nicht überall reinzuschauen. Ihr gebt ihm einen Account mit Rechten.Einem neuen Kollegen geben Sie auch keinen Generalschlüssel und die Bitte, nicht überall reinzuschauen. Sie geben ihm einen Account mit Rechten. Genau das tut Secobo® OS mit KI-Agenten.

This is how almost everyone secures AI agents today: the protection rule sits as text in the agent's system prompt, and everyone hopes the model follows it. As long as it works, nobody notices when it stops working. At best, a prompt is an emphatic request, not a policy.

You would not hand a new colleague a master key and a request not to look into every room. You give them an account with permissions. That is exactly what Secobo® OS does with AI agents.

Secobo® OS führt dafür einen zentralen Werkzeug-Katalog für alle KI-Agenten. Hermes ist darin kein Sonderfall, sondern eine von mehreren Optionen neben Coding-Assistenten oder künftigen Kunden-Agenten. Jeder ruft denselben Katalog auf, und jeder Aufruf passiert dasselbe Gate. Was das Gate prüft, zeigt der nächste Abschnitt.

For this, Secobo® OS keeps a central tool catalogue for all agents. Hermes is no special case in it, but one of several options alongside coding assistants or future customer agents. Every agent calls the same catalogue, and every call passes the same gate. What the gate checks is shown in the next section.

Ein Gate braucht ein Kriterium. Es muss wissen, was es gibt, wer es sehen darf und wie vertraulich es ist. Diese Grundlage ist der Wissensgraph von Secobo Governance & Knowledge. Er entsteht aus eurenIhren Quellen: Microsoft 365 mit SharePoint, Teams und OneDrive, dazu Confluence, Notion und die Seiten, die ihrSie in Secobo® OS selbst anlegt. Für den KI-Agenten bleibt es ein Katalog, egal aus welchem System ein Dokument stammt.

Jede Information und jede Verknüpfung trägt zwei Zeitstempel: wann das Ereignis stattfand und wann das System davon erfahren hat. Ändern sich Daten, löscht der Graph den alten Fakt nicht, sondern markiert ihn als ungültig. Damit lässt sich auch im Nachhinein genau abfragen, was an einem bestimmten Tag galt, und das ist der Unterschied zwischen einem Beleg und einer Rekonstruktion.

Der Graph führt dabei Metadaten, nicht die Dateien. Er weiß, dass ein Dokument existiert, wo es liegt, wer darauf Rechte hat und welches Label es tragen sollte. Den Inhalt holt Secobo® OS erst dann aus dem Quellsystem, wenn ein Zugriff alle drei Prüfebenen bestanden hat. Das ist wie in einer Bibliothek: Der Bibliothekar kennt den Katalog, nicht jedes Buch auswendig. Wer etwas braucht, fragt am Tresen. Niemand läuft selbst ins Magazin.

Das hat eine Folge, die wichtiger ist, als sie klingt. Wir kopieren eureIhre Dateien nicht, es entsteht also keine zweite Halde, die ebenfalls abgesichert werden müsste. Das Quellsystem bleibt die Wahrheit.

A gate needs a criterion. It has to know what exists, who may see it and how confidential it is. That foundation is the knowledge graph in Secobo Governance & Knowledge. It is built from your sources: Microsoft 365 with SharePoint, Teams and OneDrive, plus Confluence, Notion and the pages you create in Secobo® OS itself. For the AI agent it stays one catalogue, no matter which system a document comes from.

Every piece of information and every link carries two timestamps: when the event happened and when the system learned about it. When data changes, the graph does not delete the old fact, it marks it invalid. That makes it possible to ask, later and precisely, what was true on a given day, and that is the difference between evidence and a reconstruction.

The graph holds metadata, not the files. It knows that a document exists, where it sits, who has rights on it and which label it should carry. Secobo® OS fetches the content from the source system only after a request has passed all three layers. It works like a library: the librarian knows the catalogue, not every book by heart. Whoever needs something asks at the desk. Nobody walks into the stacks.

That has one consequence that matters more than it sounds. We do not copy your files, so no second pile appears that would have to be secured as well. The source system stays the truth.

Die Daten liegen im Kern von drei ineinander verschachtelten Prüfebenen in Secobo Governance & Knowledge. Ein Aufruf erreicht sie nur, wenn er alle drei durchdringt, und jede innere Ebene prüft unabhängig davon, ob die äußere gehalten hat.

The data sits at the core of three nested clearance layers in Secobo Governance & Knowledge. A call reaches it only if it penetrates all three, and each inner layer checks independently of whether the outer one has held.

Alle drei Ebenen prüft Secobo® OS bei jedem Aufruf auf dem Server, unabhängig davon, welche Tools die Agent-in-a-Box für den KI-Agenten freigegeben hat. Diese Freigabe hält den KI-Agenten fokussiert, verhindert aber nichts.

Secobo® OS checks all three layers on the server at every call, regardless of which tools the Agent-in-a-Box has cleared for the AI agent. That clearance keeps the agent focused but prevents nothing.

Prüfung und Ausführung dürfen dabei nicht zwei Schritte sein. Stellt Secobo® OS nur ein „Ja, das ist erlaubt“ aus und greift der KI-Agent danach selbst zu, bräuchte die Sandbox eigene Zugangsdaten. Und ein Freibrief lässt sich immer auch anders einlösen als vorgesehen.

Check and execution must not be two separate steps. If Secobo® OS only issued a “yes, that is allowed” and the agent then reached for the data itself, the sandbox would need its own credentials. And a blank cheque can always be cashed differently than intended.

Der KI-Agent schickt aus der Sandbox die vollständige Anfrage an den Katalog, Aktion samt Parametern. Secobo® OS prüft die drei Ebenen und führt bei Erlaubnis die Aktion selbst aus: liest das Dokument, schreibt den Eintrag, versendet die Nachricht. Zurück kommt nur das fertige Ergebnis oder eine Ablehnung. Das Gate verhält sich damit wie eine Firewall, mit einem Unterschied: Eine Firewall entscheidet nach Adresse und Port, dieses Gate nach der Identität des Nutzers und der Vertraulichkeit des Zielobjekts.

The agent sends the complete request from the sandbox to the catalogue, action and parameters included. Secobo® OS checks the three layers and, if permitted, performs the action itself: it reads the document, writes the entry, sends the message. Only the finished result or a rejection comes back. The gate therefore behaves like a firewall, with one difference: a firewall decides by address and port, this gate by the identity of the user and the confidentiality of the target object.

Erweiterbarkeit ist Teil des Entwurfs. Ein Modul oder ein KI-Agent bekommt einen Satz Konnektoren gereicht, also genau die Anschlüsse, die er braucht: für den Wissensgraphen, für Dateien, für Ereignisse, für die Oberfläche, für ein Sprachmodell. Dieser Satz ist zugleich seine Berechtigung. Was nicht im Satz steht, existiert für ihn nicht. Anderswo bekommt ein Modul einen Zugang und benutzt ihn danach frei. Hier nicht.

In den meisten Plugin-Systemen erbt eine Erweiterung die Rechte des Programms, das sie lädt. Modular ja, aber ohne Berechtigung. Bei uns ist es wie bei einer App auf dem Smartphone. Das Modul nennt, was es braucht, und bekommt genau das.

Jeder Konnektor hat drei Eigenschaften von Anfang an. Er ist widerrufbar ohne Neustart, er ist nicht weitergebbar an einen anderen Agenten, und er ist kurzlebig. Ein entzogenes Recht wirkt beim nächsten Aufruf, nicht beim nächsten Wartungsfenster. So kann ein neues Modul jederzeit dazukommen, ohne dass sich an den Rechten der anderen etwas ändert.

Extensibility is part of the design. A module or an AI agent is handed a set of connectors, exactly the sockets it needs: for the knowledge graph, for files, for events, for the interface, for a language model. That set is at the same time its permission. Whatever is not in the set does not exist for it. Elsewhere a module receives an access token and then uses it freely. Not here.

In most plugin systems an extension inherits the rights of the program that loads it. Modular, yes, but without a permission step. Ours works like an app on a smartphone. The module names what it needs, and it gets exactly that.

Every connector has three properties from the start. It is revocable without a restart, it cannot be passed on to another agent, and it is short-lived. A withdrawn right takes effect on the next call, not in the next maintenance window. A settings page that only works after a restart is decoration. That way a new module can be added at any time without changing the rights of the others.

Ein Modul bringt ein Manifest mit: welche Fähigkeiten es anbietet, welche Konnektoren es braucht, welche Typen es im Graphen anlegen will. Bei der Installation steht das in Klartext vor euchIhnen, und ihr lehntSie lehnen jeden Punkt einzeln ab. Genau wie beim Berechtigungsdialog einer App.

Beim Start meldet das Modul, was es kann. Secobo® OS gleicht diese Meldung gegen das ab, was wirklich erteilt wurde. Alles darüber weist es ab, statt es stillschweigend zu kürzen. Und der Weg dahin ist abgesichert: kein Image aus einer beliebigen Registry, sondern Signaturprüfung und eine Freigabeliste. Der Bereich, in dem das Modul läuft, hat eine Ressourcen-Obergrenze und eine Liste der Ziele, die es nach draußen erreichen darf. Für einen KI-Agenten ist diese Liste kurz: Secobo® OS und das Sprachmodell, das Secobo® OS für Pi.dev festlegt. Beendet ein Nutzer die Sitzung, entzieht Secobo® OS zuerst die Vollmacht. Danach verschwindet die Sandbox ohne Rückstände auf dem Server. Das Protokoll bleibt.

A module brings a manifest: which capabilities it offers, which connectors it needs, which types it wants to create in the graph. At installation this is shown to you in plain words, and you refuse each item one by one. Exactly like the permission dialogue of an app.

On start-up the module reports what it can do. Secobo® OS checks that report against what was actually granted. It rejects anything beyond that, instead of silently trimming it. And the supply path is secured: no image from an arbitrary registry, but signature checks and an allow list. The area the module runs in has a resource limit and a list of destinations it may reach. For an agent that list is short: Secobo® OS and the language model that Secobo® OS sets for Pi.dev. When a user ends the session, Secobo® OS first revokes the authority. Then the sandbox disappears without leaving anything behind on the server. The log remains.

Die Daten liegen verschlüsselt. Als Schlüsseltresor nutzt Secobo® OS Infisical, und der Master-Schlüssel liegt bei euchIhnen. Ihr verwaltetSie verwalten alle Schlüssel selbst, statt sie dem Hersteller zu überlassen. Das ist der Unterschied zwischen einem Versprechen und einer Architektur: Wer den Schlüssel nicht hat, kann auch nicht mitlesen. Zum Start betreibt Secobo den Schlüsseltresor noch selbst. Der Umzug des Master-Schlüssels zu euchIhnen ist als nächste Ausbaustufe vorgesehen.

Suchen bleibt trotzdem möglich, über einen Blindindex. Er speichert statt des Klartexts einen verschlüsselten Fingerabdruck, den man vergleichen, aber nicht zurückrechnen kann. Eine Suche findet damit das richtige Dokument, ohne dass der Server den Inhalt sieht.

Ein Team kann noch weiter gehen. Für einen Bereich, bis hinunter zu einzelnen Dateien, legt es einen eigenen Schlüssel an, den auch die eigene Administration nicht hat. Dort liest dann niemand mit, ihr nichtSie nicht und wir erst recht nicht. Ein KI-Agent kommt nur hinein, wenn ein Mitglied des Teams ihn startet, denn er arbeitet in dessen Sitzung und mit dessen Schlüssel. Was ein Team so schützt, wird dafür nicht vorab durchsucht und nicht im Hintergrund klassifiziert. Diesen Tausch entscheidet das Team, nicht wir. Den Wiederherstellungsschlüssel hält das Team selbst. Geht er verloren, kommt auch Secobo nicht mehr an die Daten.

The data is encrypted. Secobo® OS uses Infisical as its key vault, and the master key stays with you. You manage every key yourself instead of leaving it to the vendor. That is the difference between a promise and an architecture: whoever does not hold the key cannot read along. At launch, Secobo still operates the key vault itself. Moving the master key to you is planned as the next stage.

Search still works, through a blind index and through pseudonyms. A blind index stores an encrypted fingerprint instead of the plain text. It can be compared, but not reversed. A search finds the right document without the server having to see the content.

A team can go one step further. For one area, down to single files, it creates a key of its own, one that not even your own administration holds. Nobody reads along there, not you and certainly not us. An AI agent gets in only when a member of that team starts it, because it works in that member's session and with that member's key. What a team protects this way is not indexed in advance and not classified in the background. The team decides that trade, not us. The team holds the recovery key itself. If it is lost, not even Secobo can get to the data.

Die meisten Werkzeuge für KI-Governance setzen einen Cloud-Dienst voraus. Für den Geheimschutz und für getrennte Netze ist das ein Ausschlusskriterium, und das Gespräch endet, bevor es beginnt. Secobo® OS ist ohne Internet lauffähig. Den Lizenzschlüssel prüfen wir ohne Online-Aktivierung, wir liefern als geschlossenes Paket, und im Normalbetrieb geht kein Aufruf nach draußen.

Das ist kein Sonderfall, den wir später nachrüsten. Es entscheidet mit, was überhaupt eingebaut werden darf. Und es hat eine Folge, die ihrSie kennen solltetsollten: In einer abgeschotteten Umgebung kann das Sprachmodell nicht extern liegen. Es läuft dann im eigenen Netz.

Das ist kein Detail. Marktbegleiter wie SAP® Joule binden ihre KI-Assistenten an eine SAP-Cloud-Instanz; eine klassische lokale Installation ist dort ausgeschlossen (SAP-Hinweis 3632703). Für einen Kunden mit getrenntem Netz ist das kein Konfigurationsschritt, sondern eine geschlossene Tür. Secobo® OS ist von Anfang an für genau diesen Fall gebaut.

Most tools for AI governance require a cloud service. For classified environments and separated networks that rules them out before the conversation starts. Secobo® OS runs without an internet connection. We check the licence key without online activation, we deliver as a closed package, and in normal operation no call leaves the network.

This is not a special case we add later. It shapes what may be built into the product at all. And it has one consequence worth knowing: in a separated environment the language model cannot sit outside. It then runs inside your own network.

This is not a detail. Market players such as SAP® Joule bind their AI assistants to an SAP cloud instance; a classic local installation is ruled out there (SAP Note 3632703). For a customer with a separated network that is not a configuration step, it is a closed door. Secobo® OS is built for exactly this case from the start.

Ihr müsstSie müssen keine Software bauen, um anzufangen. Es gibt drei Stufen, und die meisten Aufgaben enden auf der ersten oder zweiten.

Erstens ein Rezept. Eine feste Kette von Schritten, ohne Schleife, vom Fachbereich zusammengestellt. Keine eigene Laufzeit, kein Entwickler. Zweitens ein konfigurierter Agent. Eine Anweisung, eine Liste erlaubter Werkzeuge und ein Auslöser. Er läuft als Instanz eines vorhandenen Host-Moduls und seine Rechte sind immer eine Teilmenge von dessen Rechten. Drittens ein eigenes Modul mit eigener Schleife, für Entwickler, mit dem vollen Vertrag aus Manifest, Handshake und Konnektoren.

Die mittlere Stufe ist der Normalfall, und sie trägt vier Auflagen. Ein Trockenlauf ist Pflicht, bevor der Agent zum ersten Mal wirklich handelt. Vor jeder schreibenden Aktion fragt er nach. Jeder Agent hat einen benannten Besitzer und ein Ablaufdatum. Und alle laufenden Agenten stehen an einer Stelle, sichtbar für die, die sie verantworten.

You do not have to build software to get started. There are three levels, and most tasks end at the first or second one.

First, a recipe. A fixed chain of steps without a loop, assembled by the department. No runtime of its own, no developer. Second, a configured agent. An instruction, a list of allowed tools and a trigger. It runs as an instance of an existing host module, and its rights are always a subset of that module's rights. Third, a module of your own with its own loop, for developers, under the full contract of manifest, handshake and connectors.

The middle level is the normal case, and it carries four obligations. A dry run is mandatory before the agent acts for real. It asks before every writing action. Every agent has a named owner and an expiry date. And all running agents are listed in one place, visible to those accountable for them.

Ein Custom Agent bringt Fähigkeiten mit. Er kann auch eine eigene Ansicht mitbringen, mit eigenem Eintrag in der Hauptnavigation von Secobo® OS. Ein Rezertifizierungs-Agent zeigt dann seine offenen Prüfungen, ein Klassifizierungs-Agent seine Vorschläge, jeweils an dem Ort, an dem ihr ohnehin arbeitetSie ohnehin arbeiten.

A custom agent brings capabilities. It can also bring its own view, with its own entry in the main navigation of Secobo® OS. A recertification agent then shows its open reviews, a classification agent its proposals, each in the place where you work anyway.

Die Ansicht ist ein Plugin: Sie rendert in die Anker, die Secobo® OS vorgibt, und bekommt keinen eigenen Platz daneben. Rahmen, Navigation, Design und Sprache kommen von Secobo® OS. Der Navigationseintrag hängt am Nutzungsrecht. Wer den KI-Agenten nicht nutzen darf, sieht ihn auch nicht. Und die Ansicht erreicht Daten nur so, wie der KI-Agent sie erreicht: durch das Gate und im Rahmen der Rechte des Nutzers, der sie öffnet. Es gibt keine globalen Agenten-Rechte, die ihr außerhalb mühsam pflegen müsstetSie außerhalb mühsam pflegen müssten.

The view is a plugin: it renders into the anchors that Secobo® OS defines and gets no space of its own beside them. Frame, navigation, design and language come from Secobo® OS. The navigation entry hangs on the usage right. Whoever may not use the agent does not see it either. And the view reaches data only the way the agent reaches it: through the gate and within the rights of the user who opens it. There are no global agent rights that you would have to maintain laboriously elsewhere.

Governance, Wissensgraph und Oberfläche bleiben damit aus einer Hand, während die KI-Agenten selbst von euchIhnen, von uns oder von Partnern kommen können.

Governance, knowledge graph and interface stay from a single source, while the agents themselves can come from you, from us or from partners.

Auf einem Smartphone gibt es keinen Schalter, der eine App halb einschaltet. Sie ist installiert oder sie ist es nicht. Secobo® OS ist genauso gebaut, und das hat vier Folgen, die ihrSie direkt merkt.

Ihr fangt klein an. Ein Modul reicht für den Anfang, weitere kommen dazu, wenn ihr sie brauchtSie sie brauchen. Kein Umbau, keine zweite Anmeldung, keine zweite Rechteverwaltung. Der Wissensgraph darunter bleibt derselbe.

Was nicht installiert ist, kann nichts anrichten. Ein abgeschaltetes Feature liegt trotzdem als Code im System und bleibt Angriffsfläche. Ein nicht installiertes Modul ist schlicht nicht da.

Der Nachweis ist eindeutig. Welche Module am Stichtag liefen, steht im Produktschlüssel. Ihr müsstSie müssen nicht rekonstruieren, wie eine Einstellung an jenem Tag stand und wer sie wann geändert hat.

Und ein Modul muss nicht von uns kommen. Ein Partner oder euerIhr eigenes Team kann eines bauen, unter demselben Vertrag und denselben Prüfebenen wie jedes andere. Vier Dinge bleiben dabei immer fest verbaut: das Tor, die Prüfung eines Modulpakets, die eine Stelle, die in den Wissensgraphen schreibt, und das Rechtesystem. Wäre eines davon austauschbar, könnte irgendwann jemand die Prüfung austauschen.

On a smartphone there is no switch that turns an app half on. It is installed or it is not. Secobo® OS is built the same way, and that has four consequences you notice directly.

You start small. One module is enough to begin with, more follow when you need them. No rebuild, no second login, no second permission system. The knowledge graph underneath stays the same.

What is not installed cannot do harm. A disabled feature still sits in the system as code and remains attack surface. A module that is not installed is simply not there.

The evidence is unambiguous. Which modules ran on a given day is recorded in the product key. You do not have to reconstruct how a setting stood that day and who changed it when.

And a module does not have to come from us. A partner or your own team can build one, under the same contract and the same layers of checks as any other. Four things always stay built in: the gate, the check of a module package, the single place that writes to the knowledge graph, and the permission system. If one of them were replaceable, somebody could eventually replace the check.

Ein KI-Agent, den nicht wir gebaut haben, läuft in Secobo® OS wie eine App auf dem Smartphone: in einer eigenen Box, mit einem Manifest, das in Klartext sagt, was er braucht, und mit einer Zustimmung, bevor er zum ersten Mal handelt. Das Betriebssystem läuft nicht in der App mit. Es kontrolliert an der Grenze, über die Schnittstelle, die es der App gibt. Genau so hält es Secobo® OS mit Agenten, die von einem Partner oder aus euremIhrem eigenen Haus kommen.

Zwei Bauformen, beide sind Apps. Eine Definitions-App bringt Anweisung, Konfiguration und Werkzeugauswahl mit und läuft in unserer Harness. Dort sitzt unsere Werkzeugfreigabe im selben Prozess und kann jeden Aufruf anhalten, weil kein fremder Code neben ihr läuft. Eine Code-App bringt eigenen Code mit. Sie bekommt eine eigene Box mit einer eigenen Harness-Instanz. Eine Freigabe im Prozess wäre dort wertlos, fremder Code könnte sie abschalten. Deshalb wandert die Kontrolle an die Grenze der Box: Secobo® OS entscheidet an jedem Aufruf noch einmal selbst.

Die Harness ist das SDK. Pi.dev in der Box gibt der App ihre Werkzeuge, Sitzungen und Rückfragen, so wie das Smartphone der App Kamera und Kontakte gibt. Jedes Werkzeug ist ein dünner Client der Schnittstelle von Secobo® OS, mit dem Token der App: keine eigene Logik, kein Geheimnis, kein Weg am Tor vorbei zum Wissensgraphen oder zu Microsoft 365. Was die Harness der App verspricht, muss Secobo® OS halten. Rückfrage, Drossel und Freigabe sind deshalb Funktionen des Kerns, die Harness spiegelt sie nur nach innen.

Zwei Wände, immer. Jede Box ist ein gehärteter Container: keine Rechte auf dem Host, nur lesbar, Netz ausschließlich zu Secobo® OS und zu den freigegebenen Sprachmodellen. Um jede Box liegt zusätzlich ein eigener Anwendungskern (gVisor), der die Systemaufrufe der Box abfängt, bevor sie den Server erreichen. Für unbekannte Anbieter und für Hochsicherheitsbereiche kann an seine Stelle eine kleine virtuelle Maschine je Box treten (Kata Containers). Die App merkt davon nichts. Für Bereiche, in denen Zero Trust bis auf die Team- und Dateiebene reicht, ist das die passende Stufe.

Was ihrSie damit in der Hand habthaben, und was nicht. In der Hand: welche Daten der Agent sieht, entschieden am einzelnen Objekt und nie über die Sicht des Nutzers hinaus; welche Werkzeuge es gibt; jeder Schreibvorgang durch Tor und Audit-Kette; das Netz; die Geheimnisse, denn die Box hält nur ein knappes Token, das sich je Anfrage widerrufen lässt; Rechenzeit und Laufzeit; und die Deinstallation, die Box und Token entfernt. Nicht in der Hand: was der Agent mit Daten tut, die er rechtmäßig sieht, seine Anfälligkeit für eingeschleuste Anweisungen und die Qualität seiner Antworten. Der Aufruf des Sprachmodells ist der eine Kanal, der sich nicht schließen lässt. Er ist nur über die Liste der erlaubten Modelle begrenzt.

Tippen zum VergrößernTap to enlarge

An AI agent we did not build runs in Secobo® OS like an app on a phone: in a box of its own, with a manifest that says in plain words what it needs, and with consent before it acts for the first time. The operating system does not run inside the app. It controls at the boundary, through the interface it hands the app. Secobo® OS treats agents from a partner or from your own team exactly that way.

Two shapes, both are apps. A definition app brings an instruction, a configuration and a tool selection and runs in our harness. There, our tool clearance sits in the same process and can stop any call, because no foreign code runs beside it. A code app brings code of its own. It gets its own box with its own harness instance. A clearance inside that process would be worthless there, foreign code could switch it off. So control moves to the box's boundary: Secobo® OS decides on every call itself.

The harness is the SDK. Pi.dev inside the box hands the app its tools, sessions and confirmation prompts, the way a phone hands an app the camera and the contacts. Every tool is a thin client of the Secobo® OS interface, carrying the app's token: no logic of its own, no secret, no way past the gate to the knowledge graph or to Microsoft 365. Whatever the harness promises the app, Secobo® OS has to keep. Confirmation, throttling and clearance are therefore functions of the core; the harness only mirrors them inward.

Two walls, always. Every box is a hardened container: no rights on the host, read-only, network only to Secobo® OS and to the approved language models. Around every box sits an application kernel of its own (gVisor) that intercepts the box's system calls before they reach the server. For unknown providers and for high-security areas a small virtual machine per box (Kata Containers) can take its place. The app does not notice. For areas where zero trust reaches down to team and file level, that is the matching tier.

What you hold in your hand, and what you do not. In your hand: which data the agent sees, decided at the single object and never beyond the user's own view; which tools exist; every write through the gate and the audit chain; the network; the secrets, because the box holds only one narrow token that can be revoked per request; compute and run time; and uninstallation, which removes box and token. Not in your hand: what the agent does with data it sees legitimately, its susceptibility to injected instructions, and the quality of its answers. The call to the language model is the one channel that cannot be closed. It is bounded only by the list of approved models.

Tippen zum VergrößernTap to enlarge

Die Anfrage läuft von oben nach unten: vom Nutzer zur Control Plane, von dort in die Sandbox, in der Pi.dev den KI-Agenten ausführt, und erst ganz unten liegt der Server. Jede Ebene hat genau eine Aufgabe.

Das Gehirn. In der Control Plane von Secobo® OS wird entschieden: wer anfragt, was er darf, und ob ein Agent startet, weiterläuft oder gestoppt wird. Hier liegen die Regeln. Läuft ein Agent aus dem Ruder, kommt der Befehl zum Stoppen von hier.

Die Festung. Jeder Agent läuft in Pi.dev, in einer eigenen Kapsel. Die Wand der Kapsel ist gVisor: ein eigener Anwendungskern, der nur geprüfte Systemaufrufe durchlässt. Zwischen den Kapseln gibt es keine Verbindung. Nach oben geht nur ein Service-Aufruf an den Tresen, und jeder wird dort geprüft. Zur Seite geht nur der Durchgang zum Sprachmodell.

Das Fundament. Der Kernel des Servers trägt alles, aber kein Agent berührt ihn direkt. gVisor liegt dazwischen.

The request runs from top to bottom: from the user to the control plane, from there into the sandbox where Pi.dev runs the agent, and only at the very bottom lies the server. Each layer has exactly one job.

The brain. The control plane of Secobo® OS decides who is asking, what they may do, and whether an agent starts, keeps running or is stopped. The rules live here. If an agent runs wild, the stop command comes from here.

The fortress. Every agent runs in Pi.dev, in a capsule of its own. The capsule's wall is gVisor: an application kernel of its own that lets only checked system calls through. There is no connection between the capsules. Upwards only a service call goes to the counter, and every one is checked there. Sideways only the passage to the language model.

The foundation. The server's kernel carries everything, but no agent touches it directly. gVisor sits in between.

Tippen zum VergrößernTap to enlarge

Tippen zum VergrößernTap to enlarge

Der neue Kollege. „Einem neuen Kollegen gebt ihr keinen Generalschlüssel und die Bitte, nicht überall reinzuschauen. Ihr gebt ihm einen Account mit Rechten. Genau das tut Secobo® OS mit KI-Agenten.“„Einem neuen Kollegen geben Sie keinen Generalschlüssel und die Bitte, nicht überall reinzuschauen. Sie geben ihm einen Account mit Rechten. Genau das tut Secobo® OS mit KI-Agenten.“

Der Unterschied. „Andere bitten ihre KI-Agenten per Prompt, sich an die Regeln zu halten. Secobo® OS setzt die Regeln durch, bevor der Agent die Daten überhaupt sieht.“

Ausweis und Herkunft. „Secobo® OS verarbeitet keine Prompts, nur Service-Aufrufe. An der Übergabe prüft es jeden Aufruf: ob er berechtigt ist und woher seine Daten stammen. Und selbst wenn eine untergeschobene Anweisung den Agenten täuscht, endet der Schaden an seinen Rechten.“

The new colleague. “You would not hand a new colleague a master key and a request not to look into every room. You give them an account with permissions. That is exactly what Secobo® OS does with AI agents.”

The difference. “Others ask their AI agents by prompt to follow the rules. Secobo® OS enforces the rules before the agent even sees the data.”

ID and origin. “Secobo® OS processes no prompts, only service calls. At the handover it checks every call: whether it is authorised and where its data comes from. And even if a smuggled-in instruction fools the agent, the damage ends at its permissions.”

Unsere vier Kernleistungen:

• Informationssicherheits-Managementsysteme. Aufbau und Betrieb eines ISMS bis zur Zertifizierungsreife. ISO 27001 · ISO 27701 · BSI IT-Grundschutz · DSGVO
• Secure Software Development Lifecycle. Sicherheit von der Anforderung bis zum Release, eingebaut in den Entwicklungsprozess. OWASP · ISO/IEC 27034 · Cyber Resilience Act (CRA)
• Cloud Security Governance & Compliance. Regeln, Kontrollen und Nachweise für sichere und regelkonforme Cloud-Umgebungen. BSI C5 · SOC 2 · NIS2
• AI Security & Security Automation. Absicherung von KI-Systemen und Automatisierung von Sicherheits- und Compliance-Aufgaben mit KI. ISO 42001 · EU AI Act

Our four core services:

• Information security management systems. Building and operating an ISMS up to certification readiness. ISO 27001 · ISO 27701 · BSI IT-Grundschutz · GDPR
• Secure Software Development Lifecycle. Security from requirement to release, built into the development process. OWASP · ISO/IEC 27034 · Cyber Resilience Act (CRA)
• Cloud Security Governance & Compliance. Rules, controls and evidence for secure and compliant cloud environments. BSI C5 · SOC 2 · NIS2
• AI Security & Security Automation. Securing AI systems and automating security and compliance tasks with AI. ISO 42001 · EU AI Act

Mehr unter More at www.secobo.de