Multi-Agent-Systeme ohne Autoritätserweiterung

13 Minuten Lesezeit

Multiagentensysteme verwandeln die Delegation in eine Sicherheitsgrenze. Ein Beschaffungsagent erhält die Befugnis, drei zugelassene Lieferanten zu recherchieren und bis zu 10.000 Euro auszugeben. Es delegiert die Katalogsuche an einen Subagenten und die Verhandlung an einen anderen. Der Verhandlungsagent schafft dann einen Einkäufer. Was kann dieser dritte Agent tun?

Wenn das System antwortet, indem es Rollen kopiert, Bereiche erbt oder ein Modell bittet, die Anweisungen der Eltern zusammenzufassen, wird die Autorität schließlich erweitert. Ein fehlendes Feld wird "unbeschränkt." Ein Budget wird dupliziert anstatt unterteilt. Ein Ablauf wird zurückgesetzt. Ein Kind erhält ein Werkzeug, das seine Eltern nicht verwenden konnten.

Die sichere Delegation benötigt eine Eigenschaft, die getestet werden kann, ohne Prosa zu interpretieren: Jedes Kindermandat muss gleich oder schmaler als sein Elternteil sein.

Modelldelegation in Multiagentensystemen als Einschränkungssatz

Bei einem Mandat handelt es sich um eine kurzlebige Aufzeichnung der übertragenen Befugnisse.

type Mandate = {
  id: string
  subject: string
  parentId?: string
  actions: Set<string>
  resources: Set<string>
  counterparties: Set<string>
  destinations: Set<string>
  purposes: Set<string>
  notBefore: Instant
  expiresAt: Instant
  maxBudget?: Decimal
  maxUses?: number
  maxDelegationDepth: number
  proofKeyId: string
}

Reale Systeme werden mehr Dimensionen haben: Datenklassifizierungen, Regionen, Vertragsreferenzen, Tarifgrenzen, Werkzeugparameter, erforderliche Genehmigungen und kommerzielle Bedingungen. Die Regel bleibt die gleiche. Ein Kind kann Optionen entfernen oder Limits verschärfen. Es kann keine Optionen hinzufügen oder Limits lockern.

Formal für Vorgaben:

child.actions        subset_of parent.actions
child.resources      subset_of parent.resources
child.counterparties subset_of parent.counterparties
child.destinations   subset_of parent.destinations
child.purposes       subset_of parent.purposes

Für bestellte Limits:

child.not_before >= parent.not_before
child.expires_at <= parent.expires_at
child.max_budget <= parent.remaining_budget
child.max_uses <= parent.remaining_uses
child.max_delegation_depth < parent.max_delegation_depth

Der Bewerter sollte für jeden gescheiterten Vergleich einen strukturierten Grund zurückgeben. "Unautorisiert" ist für eine externe Antwort sicher, aber zu vage für einen Operator, der eine Delegationskette debuggt.

Fehlen bedeutet nicht unbegrenzt

Optionale Felder erzeugen die häufigste semantische Falle. destinations: ["supplier_api"] Und das Kind lässt weg destinationsErbt die Unterlassung den Zwang der Eltern, verweigert sie die Delegation oder meint sie ein Ziel?

Es darf niemals ein Ziel bedeuten.

Wählen Sie eine von zwei vertretbaren Semantik und wenden Sie sie konsequent an:

1. Materialisieren Sie vererbte Einschränkungen in das Kind, bevor Sie es unterschreiben.
2. Behandeln Sie das Versäumnis als vererbt während der Berechnung der effektiven Befugnis.

Die erste produziert in sich geschlossene Child-Dokumente und eine einfachere Offline-Verifizierung. Die zweite macht Dokumente kleiner, erfordert aber, dass der Verifizierer die komplette übergeordnete Kette auflöst.

Ein sicherer Bewerter kann zuerst normalisieren:

function effectiveChild(parent: Mandate, draft: Partial<Mandate>): Mandate {
  return {
    ...draft,
    actions: draft.actions ?? parent.actions,
    resources: draft.resources ?? parent.resources,
    counterparties: draft.counterparties ?? parent.counterparties,
    destinations: draft.destinations ?? parent.destinations,
    purposes: draft.purposes ?? parent.purposes,
    notBefore: maxInstant(draft.notBefore ?? parent.notBefore, parent.notBefore),
    expiresAt: minInstant(draft.expiresAt ?? parent.expiresAt, parent.expiresAt),
    maxBudget: minDecimal(draft.maxBudget ?? parent.maxBudget, parent.maxBudget),
    maxUses: minInt(draft.maxUses ?? parent.maxUses, parent.maxUses),
    maxDelegationDepth: parent.maxDelegationDepth - 1
  }
}

In dieser Skizze wird die Fehlerbehandlung ausgelassen. Der Produktionscode darf ein Parent ohne verbleibende Tiefe, unbekannte Einschränkungen, fehlerhafte Dezimalstellen oder einen unauflösbaren Vorfahren ablehnen.

Separater Berechtigungsumfang von Verbrauchskapazität

Wenn ein Elternteil mit 10.000 Euro zwei Kinder schafft, die jeweils auf 10.000 Euro begrenzt sind, erfüllen beide Kinder eine individuelle numerische Untergruppenprüfung. Zusammen können sie 20.000 Euro ausgeben.

Budgets, Nutzungszahlen und Quoten sind Verbrauchskapazität, die Delegation muss sie atomar reservieren oder unterteilen.

Das folgende Allokations-Ledger ist ein Laufzeit-Integrationsmuster: Der aktuelle OATI-Evaluator akzeptiert einen bereitgestellten Nutzungs-Snapshot; er betreibt diese Datenbank nicht und koordiniert keine gleichzeitigen Kindzuweisungen.

async function allocateBudget(parentId: string, childId: string, amount: Decimal) {
  return database.transaction(async tx => {
    const parent = await tx.mandates.lockForUpdate(parentId)
    const remaining = parent.maxBudget.minus(parent.committedBudget)
    if (amount.gt(remaining)) throw new Error("budget_allocation_exceeds_remaining")

    await tx.allocations.insert({ parentId, childId, amount })
    await tx.mandates.update(parentId, {
      committedBudget: parent.committedBudget.plus(amount)
    })
  })
}

Entscheiden Sie, was passiert, wenn ein Kind mit ungenutzter Kapazität abläuft. Sie können es an die Eltern weitergeben, es aus Gründen der Einfachheit der Prüfung nicht verfügbar lassen oder ausdrücklichen Widerruf und Freigabe verlangen.

Die gleiche Regel gilt für max_usesEin Elternteil mit zehn verbleibenden Anrufen kann nicht zehn Kinder mit jeweils zehn Anrufen erzeugen. Ein später zusammenlaufender verteilter Zähler ist zu schwach für eine Zahlung oder einen irreversiblen Vorgang.

Bind Delegation zur Child Runtime

Ein Kind Mandat sollte das genaue Kind Subjekt und Beweisschlüssel nennen, andernfalls kann jeder Prozess, der das Dokument erhält, es ausüben.

Das Kind weist beim Einreichen einer Transaktion den Besitz seines Laufzeitschlüssels nach. Bei einem vollständigen Einsatz sollte überprüft werden, ob der Proofschlüssel mit dem Mandat übereinstimmt, jeder Emittent delegieren durfte und die Kette bei einer akzeptierten Organisationsbehörde endet. Der aktuelle Referenzbewerter überprüft eine gelieferte Elternbeziehung. Eine willkürliche Kettenauflösung bleibt eine Laufzeitverantwortung.

Organisation principal
  signs parent mandate for procurement agent
    procurement agent signs child mandate for negotiation agent
      negotiation agent signs child mandate for ordering agent

Jeder Link benötigt seine eigene Gültigkeitsdauer, Unterschrift und Widerrufsstatus. Der Verifizierer darf kein gültiges Blatt akzeptieren, wenn ein Vorfahr abgelaufen ist oder widerrufen wurde.

Ein Beschaffungsbeispiel

Das Root-Beschaffungsmandat ermöglicht:

{
  "actions": ["catalog.search", "offer.request", "order.create"],
  "resources": ["category:industrial-sensors"],
  "counterparties": ["supplier:A", "supplier:B", "supplier:C"],
  "purposes": ["plant-7-maintenance"],
  "constraints": {
    "currency": "EUR",
    "max_budget": "10000.00",
    "max_unit_price": "850.00",
    "destinations": ["plant:7"],
    "max_delegation_depth": 2
  }
}

Das Forschungskind erhält catalog.search, die gleiche Produktkategorie und drei Lieferanten. Es erhält keine Kaufaktion und kein Budget. offer.request für Lieferanten A und B zuzüglich einer Anforderung, die innerhalb des Elternfensters abläuft. order.create für Lieferant B ein ausgewähltes Produkt, 4,200 EUR zugewiesenes Budget, eine Nutzung und Lieferung nur an Anlage 7.

Wenn jeder Ausführungspfad das effektive Mandat und den gemeinsamen Kapazitätsspeicher durchsetzt, kann das bestellende Kind keine andere Kategorie suchen, mit dem Lieferanten C verhandeln, die Lieferung umleiten oder einen zweiten Auftrag erstellen.

Ein korrekt erteiltes Mandat kann unbrauchbar werden, nachdem sein Mutterunternehmen widerrufen wurde, sein zugewiesenes Budget verbraucht wurde oder der zugelassene Lieferant das Register verlassen hat.

Delegation ist keine sofortige Vererbung

Frameworks geben oft Anweisungen von einem Manager-Agenten an einen spezialisierten Agenten weiter, das ist eine nützliche Orchestrierung, aber es ist keine Sicherheitsgrenze.

Diese Aufforderung ist keine Autorität:

Buy replacement sensors from approved suppliers.
Do not spend more than EUR 10,000.
Ask before placing an expensive order.

Es lässt grundlegende Begriffe undefiniert. Welches Lieferantenregister? Was zählt als teuer? Beinhaltet das Limit Steuern und Versand? Kann ein Kinderagent die Lieferadresse ändern? Wie viele Bestellungen sind erlaubt? Was passiert nach Ablauf?

Unterzeichnete Mandate und deterministische Richtlinien beschränken, welche Pläne ausgeführt werden können. Behalten Sie beide. Verwechseln Sie nicht einen mit dem anderen.

Ressourcenhierarchien brauchen explizite Containment-Regeln

Einfache String-Gleichstellung ist sicher, aber oft zu restriktiv. cluster:prod-eu/namespace:billing, erstellen Sie dann ein Kind, das auf eine Bereitstellung innerhalb dieses Namensraums beschränkt ist.

Schließen Sie keine Hierarchie aus beliebigen String-Präfixen ab. database:prod darf nicht enthalten database:production-archive Definieren Sie typisierte Ressourcenbeziehungen in einer Registrierung oder verwenden Sie strukturierte Identifikatoren mit einer getesteten Containment-Funktion.

function resourceContained(child: Resource, parent: Resource): boolean {
  if (child.kind !== parent.kind) return false
  if (child.tenant !== parent.tenant) return false
  if (parent.id === child.id) return true
  return resourceGraph.hasAncestor(child.id, parent.id)
}

Wenn ein Administrator eine Ressource zwischen Gruppen verschiebt, während ein Mandat aktiv ist, kann sich der effektive Umfang ändern, ohne das signierte Dokument zu ändern.

Parameterbereiche bedürfen der gleichen Sorgfalt: Ein Kind kann einen zulässigen Portbereich, eine geografische Region oder eine Datenklassifizierung eingrenzen, aber nur, wenn sowohl Emittenten als auch Prüfer eine genaue Teilmengensemantik teilen. Freiformbedingungen wie only safe databases Konvertieren Sie sie in typisierte Attribute oder erfordern Sie ein eigenes Policy-Ergebnis.

Entscheiden Sie, wer ein Root-Mandat prägen darf

Nicht-Amplifikation schützt Nachkommen nur dann, wenn die Wurzel legitim ist. Beschränken Sie die Root-Emission auf verantwortliche Organisationsprinzipien, verwenden Sie geschützte Signaturschlüssel und separate Emission von der Genehmigung für sensible Befugnisse. Ein Runtime-Agent, der ein neues Root-Mandat erstellen kann, kann die gesamte Delegationskette umgehen.

Geben Sie die Sponsor- oder Geschäftsfunktion hinter der Wurzel auf, auch wenn es sich bei dem unmittelbaren Emittenten um einen automatisierten Steuerungsdienst handelt, der Betreibern und Auditoren einen Weg zurück zum menschlichen oder geregelten Prozess gibt, der die Kapazität überhaupt autorisiert hat.

Angriff auf die Kette, nicht nur das Blatt

Delegationstests erfordern kontradiktorische Ketten.

Aktionserweiterung. Geben Sie dem Kind eine Aktion, die vom Elternteil abwesend ist.

Resource Wildcard. Ersetzen einer bestimmten Ressource mit * oder ein breiteres Pfadpräfix, Ressourcenhierarchie-Semantik explizit definieren und Containment beweisen.

Klonen von Haushaltsmitteln. Es dürfen nur Transaktionen mit erfolgreicher Atomreservierung durchgeführt werden, deren kombinierte Zuweisung das verbleibende Budget der Eltern übersteigt.

Expiry Reset. Stellen Sie ein Kind aus, das vor oder nach seinem Elternteil beginnt, lehnen Sie es ab, auch wenn seine eigene Unterschrift und seine Daten gültig sind.

Tiefenwäsche. Die Vertrauenskette muss zeigen, wer an wen delegiert hat, und die Emittentenpolitik muss einschränken, welche Auftraggeber Wurzeln schlagen können.

Unbekannte Einschränkungsbeseitigung. Senden Sie ein Kind-Dokument durch einen älteren Bewerter, der ein neues Sicherheitsfeld nicht versteht.

Ahnenentzug. Spätere Blatttransaktionen müssen gemäß der Richtlinie über die Frische des Widerrufs fehlschlagen.

Wiederverwendung durch das Publikum. Wiedergabe eines Kindermandats bei einem Dienst, der kein erlaubtes Ziel war.

Teilausführung. Ein Anbieter nimmt eine Bestellung an, aber der lokale Nutzungs-Commit schlägt fehl. Verwenden Sie Idempotenzschlüssel, eine dauerhafte Transaktionszustandsmaschine und einen Abgleich. Durch das blinde Wiederholen kann die Geschäftsaktion dupliziert werden.

Return Erklärbare Fehler

Ein Bewerter sollte maschinenlesbare Pfade und stabile Grundcodes erzeugen:

{
  "decision": "deny",
  "reason": "authority_amplification",
  "issues": [
    {
      "path": "constraints.destinations",
      "code": "child_not_subset",
      "parent": ["plant:7"],
      "child": ["plant:9"]
    }
  ],
  "evaluated_chain": [
    "mandate:procurement:root-18",
    "mandate:negotiation:44",
    "mandate:order:91"
  ]
}

Führen Sie eine detaillierte Betreiberaufzeichnung und geben Sie bei Bedarf einen reduzierten externen Fehler zurück. Beide sollten die gleiche Entscheidungs-ID haben, damit die Support-Teams das Ereignis verfolgen können.

Eine Implementierungs-Checkliste

• Definieren Sie jede Autoritätsdimension als typisierte Daten.
• Veröffentlichen Sie genaue Semantik für ausgelassene und unbekannte Einschränkungen.
• Normalisieren Sie geerbte Werte vor der Teilmengenauswertung.
• Vergleichen Sie Mengen, Intervalle, numerische Grenzen und Ressourcenhierarchien deterministisch.
• Behandeln Sie Budgets, Quoten und Nutzung als Verbrauchskapazität.
• Reservieren Sie delegierte Kapazität atomar über gleichzeitige Kinder.
• Binden Sie jedes Mandat an ein Thema, einen Beweisschlüssel, einen Emittenten, ein Publikum und ein Gültigkeitsfenster.
• Begrenzen Sie die Delegationstiefe und überprüfen Sie die vollständige Vorfahrenkette.
• Überprüfen Sie den Widerruf und Status zum Zeitpunkt der Transaktion erneut.
• Lehnen Sie Kinder ab, die Einschränkungen enthalten, die der Bewerter nicht sicher interpretieren kann.
• Binden Sie Genehmigungen an das genaue Kind Mandat verdauen.
• Verwenden Sie Provider-Idempotenz und abgleichen Sie die teilweise Ausführung.
• Fügen Sie negative Konformitätsvektoren für jeden Verstärkungspfad hinzu.

Verwandte technische Anleitungen

• Sehen Sie, wie MCP-Autorisierung trennt den Werkzeugzugriff von der delegierten Befugnis.
• Für die schrittweise Annahme beginnen mit Ein-Unternehmen Transaktionssicherheit für Enterprise AI Agenten.

Aktuelle Grenze von OATI

OATI-Mandate und der deterministische Bewerter umfassen Aktion, Ressource, Gegenpartei, Ziel, Zweck, einen gelieferten Eltern- und Kind-Subset-Nachweis, Budgets, Nutzung und einmalige Einschränkungen. Die öffentliche Entwickler-Vorschau-Konformitätssuite umfasst Nicht-Amplifikationsfälle und führt die gleichen sprachneutralen Vektoren in TypeScript, Python und Go aus. Atomic Allokation über mehrere Kinder, dauerhafte Nutzungskoordination und willkürliche Tiefe Kettenauflösung gehören zur integrierenden Laufzeit.

Die breitere Intelliger-Produktkarte fügt verwaltete Vorlagen, Genehmigungen, einen Autoritätsgraphen und Lifecycle-Operationen hinzu. Das sind Zielproduktgrenzen, keine Behauptung, dass jeder Dienst vollständig ist. Der aktuelle Richtlinien-Compiler ist immer noch ein Gerüst, die Durchsetzung von Kunden-Gateways ist ein Referenzpfad, und eine unabhängige Protokollüberprüfung ist nach wie vor hervorragend.

Multiagentensysteme müssen delegiert werden, weil ein allmächtiger Agent schwer zu bedienen und schwerer zu vertrauen ist.