AI Agent Authorization: Von der Identität zur Request-Bound Authority

Aktualisiert am 27. September 2026: Ausführbare Referenzbeispiele und Kontrollkriterien hinzugefügt. Unabhängige Sicherheitsüberprüfung bleibt vor Veröffentlichung erforderlich.

18 Minuten lesen · Rezensiert 17. August 2026 · Sicherheitsexperte Überprüfung vor Veröffentlichung erforderlich

Die Autorisierung von KI-Agenten ist der Prozess der Entscheidung, ob ein verifizierter Agent eine exakte Aktion für einen rechenschaftspflichtigen Auftraggeber unter den aktuellen Einschränkungen ausführen kann. Ein solides Design bindet die Entscheidung an die Anforderung, die Ressource, den Zweck, das Ziel, das Budget, die Zeit, die Richtlinienversion und die delegierte Autorität. Authentifizierung und breite API-Umfänge sind Eingaben zu dieser Entscheidung. Sie sind nicht die Entscheidung selbst.

Dieser Leitfaden richtet sich an Sicherheitsarchitekten und Plattformingenieure, die Agenten hinter einer gemeinsamen Unternehmenskontrollgrenze platzieren müssen. Am Ende sollten Sie in der Lage sein, den Autorisierungskontext zu definieren, einen deterministischen Entscheidungspunkt zu implementieren, sich sicher aus einem veralteten oder unsicheren Zustand zu erholen und zu testen, dass delegierte Autorität nicht erweitert werden kann.

AI Agent Authority Control Checkliste

Verwenden Sie die folgenden Steuerelemente als Release-Gate für jeden Agenten, der Unternehmensdaten ändern, Geld ausgeben, Informationen freigeben oder einen externen Nebeneffekt auslösen kann. AI Agent Authorization Control Pack v1.0.0 enthält die vollständige 24-Kontroll-Checkliste, 26 kontradiktorische Vorrichtungen und einen Offline-Pack-Integrity-Verifier:

• Laden Sie das komplette Control Pack (ZIP) herunter
• Öffnen Sie die Kontroll-Checkliste (CSV)
• Öffnen Sie die gegnerischen Armaturen (JSON)

Führen Sie die JSON-Gehäuse durch den echten Gateway-Adapter, nicht nur die Policy-Engine isoliert. Für jede Vorrichtung vergleichen Sie die Entscheidung, stabile Grundcodes, Transaktionszustand und Anzahl der geschützten Systemaufrufe. Eine abgelehnte Vorrichtung, die immer noch das geschützte System erreicht, ist eine fehlgeschlagene Steuerung.

Inklusive verify.mjs Sie überprüft, ob die heruntergeladenen Daten vollständig und intern konsistent sind. Sie zertifiziert keine Autorisierungsimplementierung. Ein qualifizierter Prüfer muss weiterhin die Vertrauensanker, die Kryptographie, den Widerruf, die Isolation des Mandanten und das Fehlerverhalten des Einsatzes überprüfen.

Welche Autorisierung von KI-Agenten muss festgelegt werden

Ein Autorisierungsdienst benötigt genügend Beweise, um fünf Fragen für jede geschützte Anfrage zu beantworten:

1. Welcher Agent stellt die Anfrage vor und welche Organisation ist dafür verantwortlich?
2. Welcher Auftraggeber hat diese Aktion delegiert, und ist diese Delegation aktiv und widerruflich?
3. Entspricht die genaue Anfrage der zulässigen Aktion, Ressource, Gegenpartei, Zweck, Ziel und Grenzen?
4. Welche Richtlinie und welcher Genehmigungsstaat gelten zum Zeitpunkt der Entscheidung?
5. Kann ein anderer Prüfer die Entscheidung und das beobachtete Ergebnis später rekonstruieren?

Identität beantwortet nur die erste Frage. Ein gültiges Access-Token kann einen Client identifizieren und Scopes tragen, aber ein Scope wie payments:write Die OAuth 2.0 Security Best Current Practice empfiehlt Publikumseinschränkungen, vom Absender eingeschränkte Token und minimal notwendige Privilegien. Außerdem müssen Ressourcenserver überprüfen, ob ein Token für die angeforderte Aktion und Ressource gilt. RFC 9700 Unternehmensagenten benötigen noch eine transaktionsbewusste Autoritätsschicht über dieser Basislinie.

Definitionen und Grenzen

Durch die Autorisierung wird die Argumentation des Modells nicht deterministisch gemacht. Sie begrenzt, welche vorgeschlagenen Aktionen die Unternehmensgrenze überschreiten können. Das Modell kann ein Ticket interpretieren, Parameter vorbereiten oder eine Ablehnung erklären. Deterministischer Code überprüft Signaturen, bewertet Einschränkungen, Reservennutzung und gibt Ausführungsanmeldeinformationen frei.

Eine Genehmigung sollte einen überprüften Antrag binden. Eine vage Genehmigung wie "Handle this supplier" sollte nicht zu einer wiederverwendbaren Möglichkeit werden, Zahlungsdetails oder -beträge zu ändern.

AI Agent Authorization Architektur

Platzieren Sie den Policy-Eforcement-Punkt zwischen der Agent-Runtime und jedem Folgetool oder jeder API.

agent proposal
  -> gateway normalizes request
  -> identity and issuer verification
  -> mandate and revocation resolution
  -> deterministic policy evaluation
  -> approval check when required
  -> atomic usage reservation
  -> short-lived execution capability
  -> protected system
  -> signed decision and outcome evidence

Der Identitätsresolver überprüft die Emittentenkette, den aktuellen Schlüssel und den Agentenstatus. Der Autoritätsdienst löst ein kurzlebiges Mandat auf und beweist, dass jede Kinddelegation gleich oder schmaler ist als sein Mutterunternehmen. Die Policy-Engine bewertet die normalisierte Anfrage. Ein Anmelder erhält erst nach der Entscheidung eine undurchsichtige, zielgebundene Fähigkeit. Das geschützte System bleibt für das Geschäftsergebnis maßgebend.

Diese Struktur funktioniert mit REST, gRPC, MCP oder einer internen Auftragswarteschlange, da das interne Autorisierungsobjekt protokollneutral ist. Der Adapter übersetzt eine Protokollanforderung in dieses Objekt und übersetzt die strukturierte Entscheidung zurück.

Erstellen eines anforderungsgebundenen Autorisierungskontexts

Bitten Sie die Policy-Engine nicht, Prosa zu interpretieren.Normalisieren Sie die Anforderung in einen versionierten Typ und lehnen Sie unbekannte Felder vor der Auswertung ab.

type AuthorizationContext = {
  version: 1;
  transactionId: string;
  agent: {
    id: string;
    organizationId: string;
    passportDigest: string;
    proofKeyId: string;
  };
  mandate: {
    id: string;
    digest: string;
    parentDigest?: string;
  };
  request: {
    action: string;
    resource: string;
    counterparty?: string;
    purpose: string;
    destination: string;
    amountMinor?: number;
    currency?: string;
    bodyDigest: string;
  };
  control: {
    audience: string;
    policyDigest: string;
    approvalDigest?: string;
    idempotencyKey: string;
    issuedAt: string;
    expiresAt: string;
  };
};

Dies ist illustrative TypeScript, kein OATI-Bibliothekstyp. Verwenden Sie ganzzahlige kleinere Einheiten für monetäre Limits, Version der Normalisierungsregeln und Berechnung bodyDigest Wenn zwei Adapter die gleiche Anforderung unterschiedlich normalisieren können, kann eine Genehmigung, die über einen Adapter erzeugt wird, eine andere Nutzlast genehmigen.

OAuth-Ressourcenindikatoren helfen, ein Token an seinen beabsichtigten Server zu binden. RFC 8707 definiert die resource Parameter, und die MCP-Autorisierungsspezifikation erfordert, dass MCP-Clients ihn senden und MCP-Server bestätigen, dass ein Token für sie ausgegeben wurde. MCP-Autorisierung Damit wird eine wichtige Grenze geschützt: Die Unternehmensentscheidung braucht noch die Tool-Argumente, den Geschäftszweck und delegierte Grenzen.

Express Authority als Daten

Ein Mandat sollte angeben, was der Agent versuchen kann und wann diese Befugnis endet.

{
  "mandate_id": "mandate:finance:ap-442",
  "subject": "agent:finance:ap-worker-3",
  "organization": "org:buyer:eu-1",
  "purpose": "settle-approved-supplier-invoice",
  "actions": ["supplier-payment.create"],
  "resources": ["invoice:INV-8841"],
  "counterparties": ["supplier:northwind"],
  "destinations": ["bank-destination:northwind:primary"],
  "limits": {
    "currency": "EUR",
    "max_amount_minor": 2500000,
    "max_uses": 1
  },
  "delegation": { "allowed": false },
  "expires_at": "2026-08-11T17:00:00Z"
}

Dieses Beispiel ist eher konzeptionell als ein wörtliches OATI-Schema-Objekt. Jede Einschränkung muss eine definierte Vergleichsregel haben. Fehlende Child-Beschränkungen können keine unbegrenzte Autorität bedeuten. Für ein Eltern- und Kind-Mandat müssen Sie die festgelegte Aufnahme für Aktionen, Ressourcen, Gegenparteien und Ziele nachweisen und dann nachweisen, dass numerische Obergrenzen, Ablauf und Delegationstiefe nicht breiter sind.

Bewerten in einer festen Reihenfolge

Der Bewertungsauftrag betrifft sowohl die Sicherheits- als auch die Störfalldiagnose.

1. Validierung von Objektschemata und unterstützten Versionen.
2. Lösen Sie die Emittentenkette zu einem akzeptierten Vertrauensanker.
3. Überprüfen Sie den Signaturschlüssel, das Gültigkeitsintervall und den aktuellen Status.
4. Überprüfen Sie Pass und Mandat Widerruf.
5. Stellen Sie die kanonische Signatur-Nutzlast wieder her und überprüfen Sie den Besitznachweis.
6. Überprüfen Sie Aktivierung, Ablauf, Clock Skew und erwartete Zielgruppe.
7. Fordern Sie die Transaktionskennung in einem Replay Store an.
8. Prove Child Authority ist eine Untergruppe der Elternautorität.
9. Bewerten Sie Aktion, Ressource, Gegenpartei, Zweck, Ziel und Grenzen.
10. Reservieren Sie einmalige Nutzung oder Budget atomar.
11. Überprüfen Sie einen genauen Genehmigungsverdau, wenn die Richtlinie eine Genehmigung erfordert.
12. Geben Sie eine zielgebundene Ausführungsfähigkeit aus.

Die Replay-Behauptung und die Nutzungsreservierung erfordern eine dauerhafte atomare Semantik. Zwei gleichzeitige Anfragen dürfen nicht beide ein One-Use-Mandat erfordern. Wenn der Police-Service nach der Reservierung, aber vor dem Versand abstürzt, sollte die Wiederherstellung den Transaktionszustand überprüfen und nicht die Freigabebehörde sofort freigeben.

Cache-Design erfordert die gleiche Sorgfalt. Ein Gateway kann Emittentendatensätze, Schlüssel, Mandate und Richtlinienpakete zwischenspeichern, um die lokale Durchsetzung verfügbar zu halten, aber jedes zwischengespeicherte Objekt benötigt eine Versions-, Ablauf- und Ungültigkeitsregel. Der Widerruf sollte den betreffenden Eintrag ungültig machen oder das Gateway in einen begrenzten, durch Richtlinien definierten, veralteten Zustand verschieben. Materialschreiben sollten nicht geschlossen werden, wenn das Gateway keinen aktuellen Vertrauens- oder Wiedergabezustand herstellen kann. Ein risikoarmes Lesen kann eine explizite Fail-Open-Regel verwenden, vorausgesetzt, die Regel benennt die Ressource, die maximale Veralterung und die emittierten Beweise. Ein undokumentierter Rückgriff von der aktuellen Autorisierung auf den zwischengespeicherten breiten Zugriff ist ein Richtlinien-Bypass.

type Decision =
  | { result: 'allow'; reservationId: string; contextDigest: string }
  | { result: 'approval_required'; reason: string; contextDigest: string }
  | { result: 'deny'; reason: string; contextDigest: string };

function decide(ctx: AuthorizationContext, state: VerifiedState): Decision {
  denyUnless(state.agentActive, 'AGENT_INACTIVE');
  denyUnless(state.mandateActive, 'MANDATE_INACTIVE');
  denyUnless(state.audience === ctx.control.audience, 'AUDIENCE_MISMATCH');
  denyUnless(state.allowedActions.has(ctx.request.action), 'ACTION_DENIED');
  denyUnless(
    state.allowedResources.has(ctx.request.resource),
    'RESOURCE_DENIED',
  );
  denyUnless(
    state.allowedDestinations.has(ctx.request.destination),
    'DESTINATION_DENIED',
  );

  if (state.requiresApproval && !state.approvalMatches(ctx)) {
    return {
      result: 'approval_required',
      reason: 'EXACT_APPROVAL_REQUIRED',
      contextDigest: state.contextDigest,
    };
  }

  return state.reserveUsageAtomically(ctx.transactionId);
}

Dieser Pseudocode lässt kryptographische Verifizierungs- und Speichertransaktionen aus. Seine nützliche Eigenschaft ist der geschlossene Entscheidungstyp. Eine Ausnahme oder ein Timeout wird nicht zu einem Erlauben.

Anmeldeinformationen aus dem Modellkontext heraushalten

Der Agent sollte ein Tool-Ergebnis, ein undurchsichtiges Handle oder eine eng begrenzte Fähigkeit erhalten. Er sollte keinen wiederverwendbaren API-Schlüssel erhalten, den er in einer Eingabeaufforderung zitieren, in den Speicher schreiben oder an ein anderes Tool senden kann.

Mechanismen zum Nachweis des Besitzes reduzieren den Wert gestohlener Zugriffstoken. RFC 9449 Definiert DPoP für die Bindung von OAuth-Tokens an einen Client-Schlüssel. DPoP drückt keine Rechnungslimits oder Delegationen aus, kann aber die vom Gateway verwendeten Transportdaten schützen.

Ausfall- und Wiederherstellungsfälle

Eine unsichere Ausführung muss besonders behandelt werden. Das externe System hat die Aktion möglicherweise akzeptiert, selbst wenn das Gateway die Antwort verloren hat. Die Autorität und das Budget bleiben vorbehalten, das maßgebliche System mit dem gleichen Idempotenzschlüssel abfragen und das abgeglichene Ergebnis anhängen. Der Versuch mit einer neuen Transaktions-ID kann die Aktion duplizieren.

Überprüfen Sie das Design mit kontradiktorischen Armaturen

Beginnen Sie mit dem Herunterladbares Adversariary Fixture Pack, den illustrativen Kontext Ihrer Implementierung abbilden und die gleichen Fälle durch jede Sprache und jeden Adapter ausführen.

• genaue Grenzwerte für Mengen, Zeit und Verwendung;
• abgelaufene, noch nicht aktive und widerrufene Objekte;
• falsches Publikum, falsches Ziel und falsche Gegenpartei;
• Eltern-Kind-Delegation mit jeweils einer erweiterten Einschränkung;
• Unicode- und Zahlen-Kanonisierungsunterschiede;
• Transaktionswiedergabe vor und nach Ablauf des Cache;
• zwei gleichzeitige Versuche gegen One-Use-Befugnis;
• Antragsstelle, Genehmigung und Ersatzpolitik;
• Crasheinspritzung vor der Reservierung, vor dem Versand und nach dem Versand;
• Offline-Empfangsüberprüfung mit einem gedrehten Schlüssel.

Erwartete Grundcodes aufzeichnen, nicht nur zulassen oder ablehnen, ein Feld pro Single-Request-Fall mutieren und den gemeinsamen Zustand für Wiederholungs-, Parallelitäts- und Unausführbarkeitssequenzen verwenden, wodurch das Autorisierungsmodell in einen ausführbaren Vertrag umgewandelt wird und Adapter freigelegt werden, die den Kontext stillschweigend löschen.

Canonical JSON ist relevant, wenn Signaturen oder Verdauungen Sprachgrenzen überschreiten. RFC 8785 JCS definiert, so dass Implementierungen vor dem Hashen oder Signieren eine wiederholbare Darstellung ableiten können.Veröffentlichen Sie das genaue Profil und die Testvektoren, die Sie verwenden, anstatt anzunehmen, dass sich jeder JSON-Serializer gleich verhält.

Durchführung von Request-Binding- und Missbrauchstests

Das vorhandene Kontrollpaket überprüft die Integrität der Vorrichtung. Agent Control Lab 1.0.0 Sie führt eine kleine Referenzrichtlinie aus und überprüft ihr Versandverhalten. Sie implementiert keinen Produktionsautorisierungsdienst. node --test lab.test.mjs mit Node.js 20 oder neuer; es sind keine Pakete, Anmeldeinformationen oder Netzwerkaufrufe erforderlich.

Die Anforderung bindet Mieter, Agenten, Werkzeug, Ziel, Körper und Idempotenzschlüssel. Der Simulator akzeptiert nur einen genehmigten Entwurfs-Schreibvorgang. Seine Genehmigung enthält den Auszug dieser genauen Felder, einen unabhängigen Genehmiger und einen Ablauf. Identitäts- und Genehmigungsprüfung sind vertrauenswürdige Testräume, die von der Vorrichtung geliefert werden. Die Produktion muss sie aus authentifiziertem Kontext und vertrauenswürdigem Speicher ableiten.

Dieses Experiment macht die Überprüfung beobachtbar: jede verweigerte Vorrichtung behauptet, dass die simulierte Upstream-Versandzahl Null ist. Der Test für einen akzeptierten Wiederholungsversuch behauptet, dass es insgesamt genau einen Versand gibt. Das Beispiel speichert den Zustand in einem einzigen synchronen Prozess, so dass es keine Persistenz, Cross-Replica-Atomität oder Wiederherstellung nach einem Crash feststellt. Diese Eigenschaften benötigen Integrationstests mit Ihrem tatsächlichen Operationsspeicher und Upstream-Anbieter.

Für die umliegenden Grenzen, lesen Sie AI Agent Sicherheit und MCP-SicherheitDen Simulator nicht als Service aussetzen oder seine Injektion behandeln verified Flag als vom Kunden kontrollierter Produktionsnachweis.

Aktueller Intelliger und OATI Grenze

Intelliger baut KI-Systeme, die konsequente Unternehmensarbeit sicher ausführen können. Agent Trust ist die Kontrollschicht, das Enterprise Agent Gateway ist die gemeinsame Durchsetzungsgrenze und OATI ist der offene Standard für Identität, delegierte Autorität, politische Entscheidungen und Handlungsnachweise.

Die OATI-Entwicklervorschau umfasst derzeit versionierte Schemata, kanonische JSON-, Ed25519- und ES256-Profile, die Verifizierung von Emittenten und Schlüsseln, den Widerruf, einen deterministischen Mandatsbewerter, Lookup und Discovery, Referenz-Middleware-, Commerce- und RWA-Profile sowie eine gemeinsame 73-Fall-Konformitätssuite für TypeScript, Python und Go. Ein öffentlicher Lookup-Service und ein privater Trust und eine vertikale Ausgabe werden bereitgestellt.

Dies stellt keine Produktionsbereitschaft dar. Unabhängige kryptographische und Protokollprüfung bleibt offen. Der vollständige Richtlinien-Compiler, dauerhafte Evidenz- und Streit-Workflows, vollständige Hub-Lebenszyklus-Erfahrung, betriebene Kunden-Gateway-Flotte und Zwei-Unternehmen-Produktionsabnahme sind unvollständig. Die Architektur in diesem Leitfaden beschreibt die Kontrollmuster, die Teams erstellen und testen sollten; es wird nicht behauptet, dass jede kommerzielle Agent Trust-Komponente eingesetzt wird.

Sicherheitsüberprüfungshinweis: Ein qualifizierter Gutachter sollte das kryptographische Profil, die Vertrauensankerrichtlinie, das Widerrufsverhalten, die Mandantenisolierung, den Fehlermodus und den Wiederherstellungsplan für den tatsächlichen Einsatz überprüfen. Diese Seite wurde am 17. August 2026 technisch mit dem dokumentierten OATI-Entwicklervorschaustatus verglichen, ist jedoch keine Sicherheitszertifizierung.

Weiter mit Details zur Implementierung

Verwenden Sie dieses Autorisierungscluster, um vom Kategoriemodell zu einer Produktionsüberprüfung zu wechseln:

• KI-Agentenberechtigungen: von Umfang bis Transaktionsbeschränkungen
• Laufzeitgenehmigungsentscheidungsvertrag und Tests
• AI Agent Authentifizierung versus Autorisierungsarchitektur
• Wie man menschliche Zustimmung an eine KI-Agent-Aktion bindet
• OAuth Scopes versus Business Authority für KI-Agenten
• AI Agent Access Control Checkliste für die Produktion

Die Agent Trust Übersicht erklärt die Produktkontrollgrenze. Enterprise AI Agent Authorization Platform ShortlistDownload der Berechtigungssteuerpaket, dann verwenden MCP-Autorisierung für Folgewerkzeugaufrufe und die Identität versus Autorität Sicherheitsanalyse für Protokoll- und Bedrohungsmodelldetails. OATI Mandat Dokumentation beschreibt das portable authority-Objekt und öffentliches OATI-Repository enthält Schemata, SDKs und Übereinstimmungsvorrichtungen.

Für eine Überprüfung eines Gateway-Designs um einen Folgeworkflow herum, Kontaktieren Sie Intelliger mit der Aktion, dem aktuellen Anmeldepfad und dem Fehlerzustand, den Sie kontrollieren müssen.