Core Engine

KI, die Ihre
Grenzen respektiert.

Vier Ebenen von Guardrails mit gesperrten Regeln und Ausnahmen. Globale Sicherheitsrichtlinien, die nicht überschrieben werden können. Gruppen-Vererbung für Teams. Projektspezifische Anpassungen. Feinjustierung pro Job.

Zugang anfragen

Vier Sicherheitsebenen

ALLE SCOPES

naming/branch: ai/*

Branch-Namen müssen mit ai/ beginnen

GESPERRT

max_file_changes: 10

Überschreibbar in niedrigeren Scopes

content-pattern: no-console

console.log in allen Repos blockieren

GESPERRT

TEAM GRUPPE

max_file_changes: 15

← überschreibt Global (10)

no-public-rds: critical

Neue Regel im Gruppen-Scope hinzugefügt

naming/branch

✕ kann nicht überschrieben werden — GESPERRT

PROJEKT SCOPE

max_file_changes: 20

← überschreibt Gruppe (15)

testing/min-coverage: 80%

Spezifisch für dieses Projekt

Effektive Regeln dieses Projekts

max_files:20 · no-console · ai/* branch

① Globale Regeln definiert — gesperrte Regeln (Branch-Benennung, no-console) können nirgendwo überschrieben werden

② Gruppen-Overrides erlaubt — überschreibbare Regeln (max. Dateiänderungen) können pro Team gelockert werden

③ Projekt löst effektive Menge auf — spezifischster Scope gewinnt; gesperrte Regeln gelten immer

Was Guardrails durchsetzen

Dateilimits

Maximale Dateien festlegen, die ein Experten-Agent pro Job ändern darf. Unkontrollierte Änderungen verhindern.

Zeilenlimits

Anzahl geänderter Zeilen begrenzen. Änderungen fokussiert und überprüfbar halten.

Verzeichnisbeschränkungen

Experten-Agenten von bestimmten Verzeichnissen komplett aussperren. Infrastruktur, Config und sensible Pfade schützen.

Erlaubte Verzeichnisse

Experten-Agenten auf bestimmte Verzeichnisse beschränken. Sicherstellen, dass Änderungen im Scope bleiben.

Pattern-Checks

Verbotene Code-Patterns per Regex erkennen und ablehnen. Security-Antipatterns automatisch abfangen.

Namenskonventionen

Branch-, Commit- und Merge-Request-Standards erzwingen. Konsistenz ohne manuelles Review.

Gesperrte Regeln

Kritische globale Regeln als gesperrt markieren. Keine Gruppe und kein Projekt kann sie aufheben. Sicherheitsrichtlinien, die nicht überschrieben werden können.

Explizite Ausnahmen

Gruppen und Projekte können nicht gesperrte Elternregeln aufheben. Vollständiger Audit-Trail darüber, was aufgehoben wurde und warum.

Wie eine Regel feuert

  Agent möchte `src/infra/terraform.tf` bearbeiten
                     │
                     ▼
             ┌────────────────┐
             │ Globale Regeln │  gesperrt: „keine hartkodierten Secrets"
             └───────┬────────┘
                     ▼
             ┌────────────────┐
             │ Gruppen-Regeln │  „Infra-Änderungen erfordern Freigabe"
             └───────┬────────┘
                     ▼
             ┌────────────────┐
             │ Projekt-Regeln │  „/infra/ in Feature-Jobs blockieren"
             └───────┬────────┘
                     ▼
               ◆ DENY → Autor benachrichtigen + Dashboard-Banner

01

Regeln aus vier Ebenen stapeln

Global, Gruppe, Projekt und pro Job. Auf globaler Ebene gesperrte Regeln können nicht aufgehoben werden — eine Compliance-Policy überlebt jede nachgelagerte Anpassung.
02

Vor dem Schreibzugriff auswerten

Jeder Tool-Call, der Zustand ändern würde, durchläuft zuerst die Engine. Pattern-Prüfungen, Pfadbeschränkungen, Datei-/Zeilenlimits und Namensregeln feuern synchron — nichts wird ausgeführt, wenn eine gesperrte Regel verweigert.
03

Ablehnung sichtbar machen, nicht crashen

Ablehnungen werden zu Dashboard-Benachrichtigungen mit Regel, Scope und optionalem Ausnahme-Link, falls die Regel nicht gesperrt ist. Das Audit-Log hält fest, wer was warum ausgenommen hat.

Guardrails vor dem Deploy testen

Die Play Workbench lässt Sie Guardrail-Regeln gegen echte Änderungen validieren — bevor sie live gehen.

Frühzugang anfragen

KI, die IhreGrenzen respektiert.