Was die Kanal-Schicht leistet
Wirken leitet Nachrichten von benannten Chat-Oberflächen an einen einzelnen Agenten weiter, den Sie steuern. Jeder Kanal läuft in seinem eigenen Adapter-Prozess mit eigenen Plattform-Zugangsdaten, und die Vermittlung authentifiziert die Kanalidentität bei jedem IPC-Frame. Sie entscheiden, welche Kanäle existieren; die Kanäle entscheiden nie in Ihrem Namen.
Die Adapter
Jeder Adapter ist ein eigenständiges Cargo-Crate, das Plattform-Nachrichten in dasselbe Cap'n Proto-Frame umwandelt, das die Vermittlung erwartet, und umgekehrt. Die Auswahl:
Einen Kanal hinzuzufügen heißt, ein weiteres Crate gegen dieselbe Trait-Menge zu schreiben. Der Vermittlung ist gleichgültig, von welchem Kanal ein Frame kommt, solange es beweisen kann, dass der Frame auf dem Kanal eingetroffen ist, als der sich die Verbindung authentifiziert hat.
Kanalübergreifende Isolierung
Das IPC-Crate benennt die Eigenschaft, die die Kanal-Schicht haben soll, und die Namen sind Typen. AuthenticatedChannel ist der Kanal, zu dem eine Verbindung im Ed25519-Handshake aufgelöst wurde; das Gateway setzt ihn einmal und behandelt ihn für die Lebensdauer der Verbindung als vertrauten Wert. SessionHandle<C: Channel> ist eine Session-Referenz, parametrisiert durch einen versiegelten Kanalmarker. Der Phantom-Typ macht SessionHandle<Telegram> und SessionHandle<Discord> zu unterschiedlichen Rust-Typen; jede Funktion, die einen davon entgegennimmt, weist den anderen zur Kompilierzeit zurück. Einen Kanal zu überschreiten ist keine Prüfung, sondern ein Typfehler.
pub trait Channel: Send + Sync + 'static {
fn id() -> &'static str;
}
pub struct AuthenticatedChannel(String);
pub struct SessionHandle<C: Channel> {
id: SessionId,
_channel: PhantomData<C>,
}Das IPC-Crate erzwingt dies auf der Typebene: Jede Funktion, die ein SessionHandle<Telegram> hält, kann es nicht an etwas weitergeben, das ein SessionHandle<Discord> erwartet. Das Gateway koppelt die Typ-Ebene mit einer Laufzeit-Prüfung AuthenticatedChannel::require_match auf jedem eingehenden Frame, die geschlossen scheitert und beide Seiten einer Abweichung in die Kette schreibt, sodass kanalübergreifende Versuche in der Kette beobachtbar sind. Zugangsdaten, die einem Adapter übergeben wurden, bleiben in diesem Adapter.
Was im Audit-Log landet
Jedes Frame, jede Entscheidung und jeder Aufruf schreibt vor der Ausführung ein typisiertes Event in die Session-Hash-Kette. Ein repräsentativer Ausschnitt aus einer Session, mit gekürzten Hashes:
{
"ts": "2026-05-14T10:23:18Z",
"actor": "adapter",
"action": "inbound.message",
"channel": "telegram",
"session": { "full": "assistant/telegram/12af9c" },
"detail": { "sender_id": "tg:user:74821", "message_hash": "8b1a..." },
"hash": "3f72..."
}
{
"ts": "2026-05-14T10:23:21Z",
"actor": "gateway.permissions",
"action": "permission.decision",
"session": { "full": "assistant/telegram/12af9c" },
"detail": {
"action_variant": "ShellExec",
"tier": "tier2",
"decision": "allow",
"remembered": true
},
"hash": "a04e..."
}
{
"ts": "2026-05-14T10:23:22Z",
"actor": "agent.llm",
"action": "llm.request",
"session": { "full": "assistant/telegram/12af9c" },
"detail": {
"provider": "anthropic",
"model": "claude-sonnet-4-6",
"messages_hash": "c1d2...",
"tools_hash": "5e9f..."
},
"hash": "917b..."
}
{
"ts": "2026-05-14T10:23:24Z",
"actor": "adapter",
"action": "outbound.delivered",
"channel": "telegram",
"session": { "full": "assistant/telegram/12af9c" },
"detail": { "recipient_id": "tg:user:74821", "result_hash": "2c30..." },
"hash": "e6a1..."
}Jedes Event links einer Entscheidung wird durch die Hashes rechts davon festgehalten, sodass die Änderung eines einzelnen Events jeden nachfolgenden Ketten-Hash verändert. Sie können die Reihenfolge beweisen, in der diese Zeilen liefen, und sie können beweisen, dass zwischen ihnen nichts entfernt oder umgeschrieben wurde, ohne Wirken auf das Wort glauben zu müssen.
SIEM-Weiterleitung
Dieselben typisierten Events speisen einen SIEM-Forwarder, sobald einer konfiguriert ist. Datadog, Splunk HEC, Microsoft Sentinel und jeder HTTPS-Webhook sind erstklassige Ziele. Events werden ausgeliefert, nachdem sie in der Kette gelandet sind, sodass der SIEM-Stream und Ihr lokales Audit-Log unabhängige Sichten auf denselben Datensatz sind.
Wenn Sie strukturierte Ingestion möchten, wählen Sie typisierte Events. Wenn Sie bereits einen Normalisierer auf einen generischen Webhook gerichtet haben, behalten Sie ihn bei.
Eine Session offline verifizieren
Die Kette lässt sich auch ohne laufende Vermittlung durch erneutes Abspielen verifizieren. wirken session verify liest die zur Session gehörenden Zeilen, berechnet Nachrichten-Hashes neu, lässt deterministische Werkzeugaufrufe gegen ihre aufgezeichneten Eingaben erneut laufen und meldet jede Abweichung samt Zeile und Grund.
$ wirken session verify assistant/telegram/12af9c
wirken session verify assistant/telegram/12af9c
──────────────────────
agent: assistant
Note: deterministic tools (read_file, list_files) are re-executed against the
CURRENT workspace, not the workspace state at the time of execution.
events_total: 1247
events_verified: 1245
events_unverifiable: 2
events_divergent: 0
chain: OK (1247 rows)Die Ed25519-Signaturen der Kettenköpfe werden im Umfang des gesamten Audits mit wirken audit verify geprüft. Dieser Befehl läuft jede Session-Kette in der Datenbank ab und verifiziert die Signatur jedes Kopfes gegen den veröffentlichten Schlüssel des Agenten. Eine intakte Kette plus ein verifizierter Kopf bedeutet, dass die Session in der aufgezeichneten Reihenfolge lief und dass der Kopf von dem Agenten attestiert wurde, der ihn erzeugt hat.