AAIF kündigte am 22. Oktober vier weitere Projekte an: Agent Skills, Open Responses, OpenEnv und OpenSandbox. Die Mitteilung der Linux Foundation bringt mehrere Ebenen der Agenteninfrastruktur unter ein gemeinsames Stiftungsdach. Für Plattformteams stellt sich die operative Frage, wie diese Abhängigkeiten in eine kontrollierte Bereitstellung aufgenommen werden.
Das AAIF-Projektverzeichnis beschreibt Agent Skills als Format für wiederverwendbare Anweisungen, Skripte und Referenzmaterialien. Ein gemeinsames Projektverzeichnis kann Teams helfen, die Projekte zu finden, von denen ihre Systeme abhängen. Ein solches Verzeichnis legt jedoch nicht fest, welchen Artefakten eine Organisation vertrauen sollte, welche Berechtigungen ein Agent erhalten sollte oder ob eine konkrete Bereitstellung sicher ist. Die folgenden Empfehlungen sind Maetras Analyse und keine Behauptung, dass die Zugehörigkeit zu einer Stiftung ein System zertifiziert.
Die Komponenten eines konkreten Agentenablaufs erfassen
Beginnen Sie mit einem Ablauf, der ein Geschäftssystem beeinflussen kann. Identifizieren Sie die Modellanbindung, Anweisungspakete, Werkzeugadapter, Ausführungsumgebung und Evaluierungsumgebung. Erfassen Sie die tatsächlich eingesetzten Versionen und Verantwortlichen, statt nur den bekanntesten Protokoll- oder Framework-Namen aufzuführen.
Ein Agent kann gleichzeitig von mehreren Ebenen abhängen. Eine Änderung am Anweisungspaket kann beeinflussen, wie er ein Werkzeug auswählt. Eine Änderung am Adapter kann die an eine Anwendung gesendete Anfrage verändern. Eine Änderung an der Ausführungsumgebung kann andere Dateien oder Netzwerkziele erreichbar machen. Das Inventar sollte diese Beziehungen so sichtbar machen, dass eine verantwortliche Person ein vorgeschlagenes Update beurteilen kann.
Maetras Leitfaden zur Klassifizierung von Fähigkeiten hilft dabei, den Zweck eines Agenten mit seinem Datenzugriff und seinen folgenreichen Aktionen zu verbinden.
Wiederverwendbare Anweisungspakete als Bereitstellungseingaben prüfen
Ein portables Anweisungsformat kann wiederholte Einrichtungsarbeit reduzieren. Teams sollten dennoch genau das Paket prüfen, das sie verwenden möchten. Erfassen Sie Quelle, Version, Integritätskennung, enthaltene Ressourcen und ausführbare Skripte. Bestimmen Sie, wer das Paket aktualisieren kann und wie Änderungen in die Bereitstellung gelangen.
Trennen Sie das Lesen eines Anweisungspakets von der Befugnis, dessen Vorschläge auszuführen. Ein Paket, das einen Ablauf erklärt, sollte nicht allein dadurch Nachrichten senden, Datensätze verändern oder Software installieren dürfen, dass ein Agent es laden kann. Konfigurieren Sie Ausführungsrechte in dem System, das diese Auswirkungen tatsächlich kontrolliert.
Wählen Sie für eine interne Abnahmeübung ein Paket, das eine harmlose Aktion außerhalb des genehmigten Umfangs verlangt. Prüfen Sie, ob der Ablauf die Anweisung lesen und die nicht autorisierte Auswirkung dennoch verweigern kann. So testen Sie Ihre Bereitstellungsgrenze, ohne dem vorgelagerten Format eine ungeprüfte Sicherheitseigenschaft zuzuschreiben.
Prüfen, ob Schnittstellen die Bedeutung erhalten
Eine gemeinsame Schnittstelle ist nur nützlich, wenn eine Anwendung die für ihre Nutzenden wichtigen Bedeutungen bewahrt. Prüfen Sie beim Wechsel eines Modelladapters oder einer Werkzeugintegration den Umgang mit Fehlern, Abbruch, Wiederholungen, Werkzeugargumenten und unvollständigen Ergebnissen.
Verwenden Sie vor und nach der Änderung dasselbe begrenzte Szenario. Vergleichen Sie die beabsichtigte Aktion mit der tatsächlichen Anfrage und der endgültigen Auswirkung. In einem Zahlungs- oder Nachrichtenablauf darf eine Zeitüberschreitung nicht automatisch die Wiederholung einer Aktion erlauben, deren Annahme unklar ist. Ein Integrationstest sollte diese Unsicherheit für den Aufrufer sichtbar machen.
Das sind Abnahmekriterien für die nutzende Anwendung. Sie sind keine Anschuldigungen, dass eines der neu angekündigten AAIF-Projekte diese Situationen falsch behandelt.
Ausführungsumgebungen ausdrücklich begrenzen
Dokumentieren Sie, welche Ressourcen der Agent aus seiner Ausführungsumgebung erreichen kann. Dazu gehören Dateisystempfade, Netzwerkziele, Zugriff auf Zugangsdaten und Verbindungen zu Kundensystemen. Prüfen Sie die wirksame Konfiguration in der Umgebung, die Sie bereitstellen wollen.
Ein Produktname mit Sandbox-Bezug ist ein Anlass, die Grenze zu untersuchen, aber kein ausreichender Nachweis, dass Ihre konkrete Arbeitslast isoliert ist. Prüfen Sie, wie Administratoren Zugriffe konfigurieren, Ressourcen bereinigt und blockierte Versuche erfasst werden. Halten Sie legitime Arbeit innerhalb einer brauchbaren Grenze, damit das Stoppen einer unzulässigen Aktion nicht jede produktive Aufgabe beenden muss.
Die Sicherheits-Checkliste für produktive Agentensysteme kann diese Bewertung zusammen mit anwendungsspezifischen Anforderungen strukturieren.
Updates prüfbar machen, ohne den Stack einzufrieren
Benennen Sie für jede wichtige Abhängigkeit eine verantwortliche Person und bestimmen Sie, welche Änderungen einen erneuten Abnahmetest erfordern. Eine Dokumentationsänderung, eine neue ausführbare Ressource und erweiterte Netzwerkrechte sollten nicht als dieselbe Art von Update behandelt werden.
Speichern Sie die akzeptierte Konfiguration zusammen mit Testergebnissen und dem operativen Kontakt. Verändert eine neue vorgelagerte Version das Verhalten, sollte die verantwortliche Person betroffene Abläufe identifizieren und einen Einführungs- oder Rücksetzungsweg wählen können. So können Teams gemeinsame Infrastruktur nutzen und zugleich für ihre eigene Bereitstellung verantwortlich bleiben.
AAIFs Erweiterung ist ein guter Anlass für diese Zuordnung. Sie belegt nicht, dass jede Komponente für jede regulierte oder sensible Arbeitslast geeignet ist. Beginnen Sie mit einem folgenreichen Agenten und nutzen Sie die Maetra-Dokumentation, um Inventar, Aktionsrichtlinie und Nachweisanforderungen vor der Aufnahme einer weiteren Abhängigkeit miteinander zu verbinden.