Sicherheit ist ein zentrales Designziel des AGLX-Protokolls. Da Agenten eigenständig handeln, Entscheidungen treffen und miteinander kommunizieren, müssen Authentizität, Integrität und Vertraulichkeit jederzeit gewährleistet sein. AGLX setzt dafür auf eine Kombination aus Verschlüsselung, digitaler Signierung, Vertrauenszonen und kontextabhängiger Zugriffskontrolle.
Sicherheit in AGLX wird nicht zentral verwaltet, sondern dezentral durch Vertrauen und kryptografische Verfahren gewährleistet. Jeder Agent ist selbst verantwortlich für den Schutz seiner Kommunikation und Identität.
| Prinzip | Beschreibung |
|---|---|
| Ende-zu-Ende-Verschlüsselung | Jede TCP-Kommunikation zwischen Agenten kann verschlüsselt werden (TLS oder DTLS). |
| Signierte Nachrichten | Jede Nachricht kann digital signiert werden, um Manipulationen zu verhindern. |
| Vertrauenszonen (Trust Zones) | Agenten in derselben Zone teilen Schlüssel oder Zertifikate. |
| Authentifizierung | Agenten authentifizieren sich gegenseitig über Signaturen, Tokens oder Zertifikate. |
| Minimal Exposure | Agenten veröffentlichen nur die notwendigsten Daten in der Registry. |
Jeder Agent besitzt eine eindeutige digitale Identität, die in einer Agenten-ID und einem Signaturschlüssel besteht. Diese Identität wird beim Start erzeugt und optional durch ein Zertifikat einer Registry bestätigt.
Beispiel: Registrierung mit signierter Identität
AGLX/1.0 TCP FROM: agent://node17.local TO: registry://global.aglx.net TYPE: registry.update CONTENT-TYPE: application/json { "agent_name": "Node17", "agent_type": "worker", "public_key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...", "signature": "hmac-sha256:3f8d1ab2...", "capabilities": ["data.analyze", "task.execute"], "status": "READY" }
Die Registry prüft die Signatur gegen den öffentlichen Schlüssel und gibt eine signierte Bestätigung zurück.
AGLX/1.0 TCP FROM: registry://global.aglx.net TO: agent://node17.local TYPE: registry.ack SIGNATURE: rsa-sha256:72c1b9d0... STATUS: 200 OK
AGLX unterstützt mehrere Transportmodi, die abhängig von Netztyp und Sicherheitsniveau gewählt werden können.
| Modus | Beschreibung | Einsatzgebiet |
|---|---|---|
| TCP (unverschlüsselt) | Nur für geschlossene, interne LANs. Schnell, aber unsicher über WAN. | Testnetze, lokale Simulationen |
| TCP + TLS | Standardmodus für produktive Umgebungen. Schützt Daten gegen Abhören und Manipulation. | Public WAN, Rechenzentren |
| UDP + DTLS | Optional für Broadcasts und Statusmeldungen mit leichter Sicherheitsschicht. | Lokale Discovery |
| Peer Encryption | Ende-zu-Ende-Verschlüsselung auf Anwendungsebene über AGLX-Header-Feld. | Direktkommunikation zwischen Agenten |
Beispiel einer verschlüsselten Direktnachricht:
AGLX/1.0 TCP FROM: agent://alpha.local TO: agent://beta.local TYPE: task.assign ENCRYPTION: aes256-gcm CONTENT-TYPE: application/json { "iv": "8h2G6fzx4VwP+YtN", "payload": "ENCRYPTED:df9d23bb...7f1a" }
Um sicherzustellen, dass Nachrichten unverändert ankommen, wird jede Nachricht mit einer Prüfsumme oder digitalen Signatur versehen.
| Verfahren | Beschreibung |
|---|---|
| HMAC-SHA256 | Schnelles Verfahren für lokale Netze, Schlüsselbasiert |
| RSA-SHA256 | Asymmetrische Signierung, geeignet für übergreifende Netzwerke |
| ECDSA | Kompaktes Signaturverfahren mit geringer Rechenlast |
| Checksum-Header | Fallback für unkritische UDP-Meldungen |
Beispiel mit HMAC-Signatur:
AGLX/1.0 TCP FROM: agent://node51.local TO: agent://node23.local TYPE: task.result HMAC: 3f1ad62f99bcb5e1bcd942ab38e0cf3c1dd06b9e CONTENT-TYPE: application/json { "task_id": "b912-a1d9-7ce3", "result": "OK", "credits_earned": 2 }
Zugriffskontrolle in AGLX erfolgt dynamisch und rollenbasiert. Ein Agent kann definieren, welche Nachrichtentypen oder Aufgaben er akzeptiert.
Beispiel einer Policy-Datei:
{ "accept": ["task.assign", "registry.update"], "deny": ["credit.transfer", "debug.dump"], "trusted_agents": ["agent://mentor01.local", "agent://router.global"], "max_concurrent_tasks": 5 }
| Regeltyp | Beschreibung |
|---|---|
| Accept/Deny-Listen | Filterung erlaubter Nachrichtentypen |
| Trusted Agents | Whitelist bekannter und vertrauenswürdiger Agenten |
| Rate Limiting | Begrenzung eingehender Aufgaben pro Zeitraum |
| Credit Validation | Prüfung, ob Absender über ausreichende Credits verfügt |
Agenten sollten nur die notwendigsten Informationen teilen. Das gilt besonders für Registrierungs- und Monitoringdaten.
| Maßnahme | Beschreibung |
|---|---|
| Anonymisierte Statusmeldungen | Senden nur technischer Daten (z. B. uptime, load, status) |
| Verzicht auf personenbezogene Daten | Keine Userdaten oder Inhalte in Protokollnachrichten |
| Temporäre Einträge | Automatische Löschung in der Registry nach Ablauf der TTL |
| Datenverschlüsselung im Cache | Speicherung sensibler Inhalte nur verschlüsselt |