Registrierte Identität
Jeder Agent ist ein Datensatz: stabile agent_id, Rolle, Ed25519-Key-Bindung, Erstellungsdatum. Kein Rätselraten mehr, welcher Prozess was getan hat — die Registry ist die Single Source of Truth, wer existiert.
Bis 2027 sind es Flotten — und eine Flotte anonymer Prozesse ist ein Risiko. LeanCTX macht jeden Agenten zu einer registrierten Identität: eindeutig, von einem Menschen verantwortet, lifecycle-gemanagt, attestiert und widerrufbar — mit jedem Übergang im manipulationssicheren Audit-Trail.
Rollen bleiben wiederverwendbare Berechtigungsprofile. Identität legt Verantwortlichkeit darüber: agent_id, Owner, Status, Key-Bindung, Attestierung, Heartbeat. Vier Eigenschaften machen eine Flotte steuerbar.
Jeder Agent ist ein Datensatz: stabile agent_id, Rolle, Ed25519-Key-Bindung, Erstellungsdatum. Kein Rätselraten mehr, welcher Prozess was getan hat — die Registry ist die Single Source of Truth, wer existiert.
Registrierung ohne menschlichen Owner wird abgelehnt. Verantwortlichkeit ist strukturell: jeder Audit-Eintrag, jedes Lifecycle-Ereignis, jedes Evidence-Bundle führt zu einer Person, die für den Agenten geradesteht.
Einen Agenten suspendieren oder einen Owner offboarden und seine ganze Flotte atomar suspendieren — jede Suspendierung einzeln auditiert. Außerbetriebnahme ist endgültig und schreibt den abschließenden Audit-Eintrag.
Binary- und Rollen-Config-Hashes bei Registrierung und jedem Heartbeat. Drift wird sofort sichtbar (Exit-Code 3) — Upgrade, Config-Änderung oder Manipulation. Wir dokumentieren, wovor das NICHT schützt.
Alles ist CLI-first und Exit-Code-ehrlich, damit deine Pipelines und dein Monitoring darauf reagieren können.
$ lean-ctx agent register --id ci-reviewer-1 --role reviewer --owner alice@org registered: ci-reviewer-1 (role reviewer, owner alice@org) spiffe id: spiffe://org.example/agent/reviewer/ci-reviewer-1 $ lean-ctx agent heartbeat ci-reviewer-1 # liveness + drift; exit 3 on drift $ lean-ctx agent offboard-owner alice@org --reason "left company" suspended 2 agent(s): ci-coder-1, ci-reviewer-1 $ lean-ctx agent check ci-reviewer-1 # enforce-path decision point ci-reviewer-1: DENIED — suspended: left company # exit 1
Jeder Übergang schreibt einen manipulationssicheren Audit-Eintrag — registered, suspended, resumed, decommissioned sind standardisierte Event-Typen (OCP Part 4), sodass die Identitäts-Historie automatisch in deinen Evidence-Bundles landet. Vollständiges Modell und Bedrohungsmodell: Agent-Identity-Docs.
"Was passiert, wenn jemand geht?"
Ihre Agenten stoppen. Mechanisch. Owner-Offboarding suspendiert jeden aktiven Agenten dieses Owners in einer gesperrten Transaktion — verdrahtet mit deinem SCIM-Deprovisioning-Flow oder ausgeführt aus der Leaver-Checkliste. Verwaiste Agenten sind die vergessenen Service-Accounts der Agenten-Ära; LeanCTX macht sie strukturell unmöglich.
Eine Rolle sagt, was ein Prozess darf; eine Identität sagt, wer dafür verantwortlich ist. Bei Flotten sind die entscheidenden Fragen operativ: Wer besitzt diesen Agenten, wann war er zuletzt aktiv, wer hat ihn warum abgeschaltet, was passiert mit seinen Berechtigungen, wenn sein Owner geht? Die Registry beantwortet sie mechanisch — Identität (wer) bleibt getrennt von Rolle (was), damit Rollen wiederverwendbare Profile bleiben.
Ein Agent, dessen menschlicher Owner das Unternehmen verlassen hat, der aber mit seinen Credentials weiterläuft — die Agenten-Ära-Variante des vergessenen Service-Accounts, nur dass er Code liest und Befehle ausführt. LeanCTX schließt es strukturell: Owner sind bei der Registrierung verpflichtend, und ein Befehl (oder dein SCIM-Deprovisioning-Flow) suspendiert die gesamte aktive Flotte eines Owners in einer einzigen gesperrten Transaktion, jede Suspendierung auditiert.
active → suspended ⇄ active → decommissioned. Suspendierung trägt einen Grund und ist reversibel; Außerbetriebnahme ist per Design endgültig — der Datensatz wird nie gelöscht und nie reaktiviert, weil die Identität Teil der Audit-Historie ist. Jeder Übergang schreibt einen manipulationssicheren Audit-Eintrag mit standardisierten Event-Typen (agent_registered, agent_suspended, agent_resumed, agent_decommissioned — OCP Part 4), sodass Identitätsänderungen automatisch in Evidence-Bundles auftauchen.
Registrierung und jeder Heartbeat hashen die laufende Binary und die aktive Rollen-Datei. Ein geänderter Hash bedeutet, dass sich etwas geändert hat — ein Upgrade, eine Config-Änderung oder Manipulation — und zeigt sich als Drift mit einem Exit-Code ungleich null, auf den dein Monitoring alarmieren kann. Es ist Drift-Erkennung, keine Remote-Attestierung: ein Angreifer mit voller Host-Kontrolle kann Hashes fälschen, und unser Bedrohungsmodell sagt das explizit. Es ergänzt Host-Hardening und Code-Signing, ersetzt sie aber nicht.
Drei Hooks. SPIFFE: jeder Datensatz wird auf spiffe://<trust-domain>/agent/<role>/<agent_id> abgebildet, sodass K8s-Workload-Identity (SPIRE) und die LeanCTX-Identität derselbe Name sind. SCIM: verdrahte deinen Deprovisioning-Flow mit dem Owner-Offboarding-Aufruf. Enforce-Modus: die Check-API ist ein einzelner Entscheidungspunkt — nicht registrierte oder suspendierte Agenten werden abgelehnt; starte im Monitor-Modus, wechsle zu Enforce, sobald die Flotte registriert ist.
Registriere deinen ersten Agenten in einer Minute, lokal und kostenlos — oder sprich mit uns über den Flotten-Rollout mit SCIM und SPIFFE in der Schleife.