perimeter@unternehmen :~$ policy eval --stream

The Perimeter

Betriebssystem für KI-Aktionen im Unternehmen.

Das Modell schlägt vor. The Perimeter entscheidet. Die Entscheidung ist deterministisch.

Kurzfassung

The Perimeter ist eine Kontrollschicht zwischen KI-Agenten und Unternehmenssystemen — SAP, Microsoft 365, SharePoint, Datenbanken, interne APIs. Jeder Tool-Aufruf, den ein Agent vorschlägt, wird deterministisch gegen die Berechtigungen des anfragenden Nutzers autorisiert, bevor er ein führendes System erreicht: erlaubt, abgelehnt oder zur Freigabe angehalten, in unter zwei Millisekunden, und in einem nur anfügenden Protokoll gegen genau eine Identität festgehalten. Das Modell schlägt vor; die Plattform entscheidet. Diese Seite beschreibt das Problem, die Architektur und den Stand der Umsetzung.

Schlagwörter — deterministische Autorisierung · MCP · SAP · Microsoft Graph · Principal-Weitergabe · Protokoll

1Problem

KI-Demos im Unternehmen funktionieren in Woche zwei. Danach stehen sie. Nie, weil das Modell schlecht war.

Sie stehen, weil niemand vier Fragen beantworten kann: Wenn dieser Agent SharePoint liest — respektiert er die Berechtigungen, die der Nutzer bereits hat, oder legt er dem Werkstudenten den Gehaltsordner offen? Welche Tools darf er überhaupt ausführen? Wer trägt die Verantwortung, wenn er in SAP schreibt? Was bekommt die Revision zu sehen?

Das sind keine Modellprobleme. Das sind Berechtigungsprobleme — und zwischen den Systemen sind sie ungelöst.

2Architektur

Eine Kontrollebene im Anfrageweg. Nichts erreicht Unternehmensdaten, ohne sie zu durchlaufen.

  KI-AGENTEN                        UNTERNEHMENSSYSTEME
  Copilot, eigene, MCP              SAP S/4HANA
       │                            Microsoft 365 · SharePoint
       │  Tool-Aufruf               Datenbanken · interne APIs
       ▼                                           ▲
  ┌───────────────────────────────┐                │
  │  THE PERIMETER                │  beschränktes  │
  │                               │  Token         │
  │   Identität  wer fragt        ├────────────────┘
  │   Policy     darf er das      │  führt als der
  │   Freigabe   Mensch gibt frei │  Fachanwender aus,
  │   Filterung  was zurückkommt  │  mit dessen eigenen
  │   Protokoll  was geschah      │  Berechtigungen
  └───────────────────────────────┘
       │
       └──▶ Protokoll: nur anfügen · hash-verkettet
            eine Identität pro Aktion

Abbildung 1 — Anfrageweg. Identität, Policy, Freigabe, Filterung und Protokoll liegen im Gateway; der Agent hält keines davon.

Die KI entscheidet nie, was sie darf. Diese Entscheidung liegt bei uns, sie ist deterministisch, und sie fällt außerhalb des Kontextfensters — dort, wo eine Prompt Injection nicht mit ihr diskutieren kann.

3Entscheidungsverfahren

→ Tool      CreatePurchaseOrder
→ Principal agent:procure-bot/7f1c (SPIFFE)
            im Auftrag von j.weber@acme (Einkauf)
→ Argumente vendor=DE-4471  amount=480.00 EUR

  Rolle im Einkauf ................... true
  Betrag < Schwelle(500) ............. true
  Freigabe der Führungskraft ......... true

ALLOW  1,4ms  führt als j.weber aus, nicht als
              Service-Account

─────────────────────────────────────────────────────────

→ Argumente vendor=DE-4471  amount=12400.00 EUR

  Betrag < Schwelle(500) ............. false

HOLD   1,2ms  Freigabe → m.keller · Eskalation in 72h

─────────────────────────────────────────────────────────

→ Tool      SearchDocuments  q="Vergütung 2026"

  4 Treffer · 3 durch Berechtigungsfilter entfernt

ALLOW  2,0ms  liefert nur, was j.weber ohnehin sehen
              durfte. Der Gehaltsordner war nie in der Menge.

Listing 1 — Drei Aufrufe, ein Nutzer, ein Regelwerk. Urteil und Laufzeit stehen vor der Erklärung, wie im Protokoll.

Gleiche Eingaben, gleiche Antwort, jedes Mal — unabhängig davon, welches Modell auf der anderen Seite hängt und was im Prompt steht.

4Bausteine

IDENTITÄT: OIDC-Föderation zum IdP des Kunden — wir werden nie selbst einer. Eine kryptografische Identität pro Agenten-Instanz, damit zwanzig parallele Agenten zwanzig unterscheidbare Principals im Protokoll sind.
AUTORISIERUNG: Deterministische Policy bei jedem Aufruf, in-process ausgewertet, unter 2 ms p99. Kein Klassifikator. Ein zu 98 % genaues Guardrail vor einem ERP-Schreibvorgang ist eine 2-%-Chance auf eine falsche Bestellung.
WEITERGABE: Token Exchange auf ein beschränktes Downstream-Credential, das beide Principals trägt. SAP führt als der Fachanwender aus; Graph wendet sein eigenes Trimming an. Kein fetter Service-Account, aus dem heraus impersoniert wird.
FREIGABE: Mensch in der Schleife als dauerhafter Workflow, nicht als Request. Eine Freigabe wartet drei Tage, eskaliert und übersteht ein Deployment.
PROTOKOLL: Nur anfügen, hash-verkettet, signiert, mit Zeitstempel. Zugeschnitten auf Artikel 12 der EU-KI-Verordnung. Live-Observability und kalte Compliance-Nachweise aus einem Emissionspfad.

5Implementierung

Datenebene      Go · spec-konformer MCP-Server · OAuth 2.1
                Resource Server (PKCE/S256, DCR, RFC 8707)
Policy          Cedar — formal verifizierter Kern, statisch
                analysierbar. Rust validiert und signiert das
                Bundle; cedar-go wertet es in-process aus.
                Offizielle Conformance-Suite läuft in der CI.
Identität       SPIFFE/SPIRE JWT-SVID · RFC 8693 Exchange ·
                SAML-Bearer zu SAP · On-Behalf-Of zu Graph
Beziehungen     SpiceDB (ZedToken-Konsistenz)
Freigaben       Temporal, dauerhafte Workflows
Zustand/Audit   Postgres · hash-verkettet · KMS-signiert ·
                RFC-3161-Zeitstempel
Transport       NATS JetStream — Kunden betreiben kein Kafka
Telemetrie      OpenTelemetry, ein Emissionspfad
Deployment      Helm auf Kubernetes · Single-Tenant · Air-Gap
Modelle         modellagnostisch by design; wir konkurrieren
                über Vertrauen, nicht über Modellqualität.
                Die Modellwahl ist selbst eine Policy-
                Entscheidung — eine Datenklasse lässt sich an
                Modell und Region binden.

Tabelle 1 — Stack. Die tragende Entscheidung ist die Trennung von Cedar-Validierung und -Auswertung: Rust validiert und signiert das Bundle zur Compile-Zeit, cedar-go wertet es zur Anfragezeit aus.

6Abgrenzung

Identity-Anbieter geben einem Agenten eine Identität. Sie sitzen nicht im Anfrageweg mit der Semantik einer Bestellung und können deshalb nicht beantworten: „Darf dieser Agent jetzt CreatePurchaseOrder über 480 € im Auftrag dieses Nutzers aufrufen?“
KI-Gateways regeln den Aufruf zum Modell — Kosten, Rate Limits, PII im Prompt. Wir regeln den Aufruf zu SAP. Die andere Seite des Agenten.
Guardrails sind probabilistische Klassifikatoren auf Prompts und Ausgaben. Erkennung, nicht Autorisierung.
Herstellereigene Governance: Microsoft steuert Microsoft, SAP steuert SAP. Unsere Kunden betreiben beides plus zwanzig interne Systeme — und die Lücke liegt genau dazwischen.

Der schwere Teil war nie die Policy Engine — das ist ein gelöstes Primitiv, wir nutzen eines. Der schwere Teil ist die Übersetzung der Berechtigungsmodelle: SAP-Berechtigungsobjekte und abgeleitete Rollen, SharePoint-ACLs, Vertraulichkeitsbezeichnungen und Graph-Scopes in ein Entscheidungsmodell, pro Nutzer. Mühsame, unglamouröse Konnektorarbeit, die nur aus echten Tenants kommt.

7Stand

BUILD: Prototyp. Erste nutzbare Version innerhalb eines Monats.
HINTERGRUND: Zwei Jahre Vollzeit in SAP- und Microsoft-365-Tenants von Unternehmen — 20+ zahlende Kunden, 200+ Unternehmen befragt in DE / CH / AT / HU / ES. Wir haben diese Schicht mehr als einmal von Hand gebaut. Wenn man dasselbe zum n-ten Mal baut, ist es ein Produkt.
MARKT: DACH-Industrie zuerst — weil es der schwerste Markt ist, nicht der leichteste. Datenresidenz, Betriebsräte, On-Prem, die dichteste SAP-Installationsbasis der Welt. Ein Produkt, das einen deutschen Betriebsrat und einen ISO-Auditor zufriedenstellt, ist überall sonst überqualifiziert.
KUNDE NULL: Jeder Coding-Agent, der unsere eigenen Staging-Systeme berührt, läuft durch The Perimeter — mit eigener Identität, eigener Policy und einem Eintrag in demselben Audit-Log, das wir verkaufen.

8Kontakt

Design-Partner: eine Abteilung, ein Konnektor, ein Agenten-Anwendungsfall. Das Onboarding übernehmen wir persönlich.

simon.bunyatov@aiphase.de