OAuth Scopes vs Business Authority für AI Agents
Erfahren Sie, wo OAuth-Umfänge aufhören und anforderungsgebundene Geschäftsautorität für KI-Agenten beginnt, die Datensätze kaufen, erstatten, ändern oder Produktionstools betreiben.
OAuth-Bereiche kontrollieren den Zugriff auf geschützte Ressourcen. Geschäftsbehörde kontrolliert die Maßnahmen, die ein KI-Agent innerhalb dieses Zugriffs ergreifen kann. Ein Agent kann orders:write und es fehlt immer noch die Befugnis, die erfüllte Bestellung dieses Kunden zu stornieren, den Bestimmungsort dieses Lieferanten zu ändern oder diese Rückerstattung ohne Genehmigung auszustellen.
OAuth bleibt Teil der Architektur. Der Fehler besteht darin, einen Scope-String zu bitten, Identität, Delegation, Transaktionspolitik und den aktuellen Geschäftszustand zu tragen. AI Agent Authorization Guide.
Halten Sie die Grenze explizit
| Fragestellung | OAuth/Ressource Server | Geschäftsgenehmigung |
|---|---|---|
| Wurde das Token von einem vertrauenswürdigen Emittenten ausgegeben? | Ja | verbraucht verifiziertes Ergebnis |
| Ist diese API das beabsichtigte Publikum? | Ja | verbraucht verifiziertes Ergebnis |
| Tragt das Token einen erforderlichen Umfang? | Ja | Ein politischer Input |
| Ist dieser Lieferant zugelassen? | Nein | Ja |
| Liegt der Auftrag des Agenten bei 8.000 EUR? | Nein | Ja |
| Hat eine autorisierte Person dieses genaue Ziel genehmigt? | Nein | Ja |
| Ist die One-Use-Befugnis bereits verbraucht? | Nein | Ja |
RFC 8707 ermöglicht es Kunden, die geschützte Ressource zu identifizieren, für die sie ein Token anfordern. RFC 9700 empfiehlt, wenn möglich, auf die Zielgruppe beschränkte und absenderbeschränkte Tokens.
Übersetzen eines Scope in einen Policy Input
function authorizeRefund(ctx: RefundContext): Decision {
denyUnless(ctx.token.audience === 'https://refunds.example', 'BAD_AUDIENCE');
denyUnless(ctx.token.scopes.has('refunds:write'), 'SCOPE_MISSING');
denyUnless(ctx.agent.status === 'active', 'AGENT_INACTIVE');
denyUnless(ctx.grant.actions.has('refund.create'), 'ACTION_DENIED');
denyUnless(ctx.grant.merchants.has(ctx.order.merchantId), 'MERCHANT_DENIED');
denyUnless(ctx.refund.amountMinor <= ctx.grant.maxAmountMinor, 'AMOUNT_DENIED');
denyUnless(ctx.order.refundableMinor >= ctx.refund.amountMinor, 'ORDER_STATE_DENIED');
return ctx.approval.matches(ctx.refundDigest)
? { effect: 'allow' }
: { effect: 'approval_required' };
}
Ein Token mit Hunderten von Werten wird schwer zu überprüfen und langsam zu widerrufen. Halten Sie den Servicezugriff im Token stabil und lösen Sie schnell wechselnde Grants, Richtlinien und Geschäftszustände an der erzwungenen Grenze.
Umgang mit Token-Austausch sorgfältig
Gateways tauschen oft ein externes Token gegen ein Upstream-Token aus. leiten Sie das Original-Token niemals an einen unbeabsichtigten Server weiter. Behalten Sie den dargestellten Haupt- und Akteur als unterschiedliche Ansprüche, beschränken Sie die Zielgruppe und den Umfang und legen Sie einen kurzen Ablauf fest. Ein Downstream-Dienst muss seine eigene Zielgruppe validieren, anstatt darauf zu vertrauen, dass das Gateway dies bereits getan hat.
Für Umgebungen mit höherem Risiko, DPoP Es reduziert den Nutzen eines gestohlenen Tokens durch die Bindung an einen Schlüssel. Es hindert einen kompromittierten autorisierten Agenten nicht daran, eine schädliche Transaktion in einem breiten Rahmen zu verlangen.
Testen Sie beide Schichten getrennt
Erstellen Sie eine Access-Test-Suite und eine Action-Authority-Suite. Ein falscher Emittent, abgelaufener Token oder eine falsche Zielgruppe sollte vor der Geschäftsrichtlinie ausfallen. Ein gültiger Token mit einer nicht zugelassenen Gegenpartei sollte die Richtlinie erreichen und eine stabile Domain-Denial erhalten. Fügen Sie einen Direct-Route-Test hinzu, um zu bestätigen, dass der geschützte Dienst nicht um den Durchsetzungspunkt herum erreicht werden kann.
Die Authentifizierung versus Autorisierungsarchitektur Karten der Kontrollbesitzer. So autorisieren Sie einen MCP Tool Call gilt die gleiche Unterscheidung für MCP. Übersicht über die Plattform ist das Intelliger-Produktziel für die Bewertung von Durchsetzungsmustern.
OATI steht als Entwicklervorschau mit öffentlichen Schemata und Verifizierungsbeispielen zur Verfügung. Behandeln Sie Produktionsidentitätsintegration, Tokenaustausch und geschäftspolitische Durchsetzung als systemspezifische Arbeit, die einer unabhängigen Überprüfung bedarf.
OAuth und Authority Design Fragen
Sollte jedes MCP-Tool seinen eigenen Umfang erhalten?
Nicht unbedingt. Scopes sollten verständliche Zugangszuschüsse sein, nicht ein Spiegel jedes dynamischen Werkzeugs und jeder Aufzeichnung. Ein sensibles Werkzeug kann einen bestimmten Umfang verdienen, während Transaktionsdetails immer noch in die externe Richtlinie gehören. Übermäßige Umfangsgranularität schafft Zustimmungs- und Lebenszyklusprobleme; Umfange, die zu breit sind, zeigen mehr Serviceoberfläche. Testen Sie den gewählten Umfang mit realen Rollen und verwenden Sie Step-up nur für Zugriffe, die ein Benutzer sinnvoll verstehen kann.
Können Token-Forderungen geschäftliche Grenzen haben?
Sie können stabile, kurzlebige Attribute tragen, aber schnell wechselnde Budgets, Lieferantenstatus und Einwegzähler sind in einem in sich geschlossenen Token nur schwer auf dem neuesten Stand zu halten. Wenn ein Anspruch verwendet wird, definieren Sie den Emittenten, die Frische, Einheiten und das Konfliktverhalten. Ein Policy-Service sollte Meinungsverschiedenheiten ablehnen, anstatt die permissivere Quelle auszuwählen.
Was fügt Absender Constraint hinzu?
Ein vom Absender eingeschränktes Token macht Diebstahl weniger nützlich, indem es einen Beweis von einem gebundenen Schlüssel verlangt. Es schützt nicht davor, dass der legitime Agentenprozess manipuliert oder kompromittiert wird. Der Prozess kann immer noch einen gültigen Beweis für eine schädliche Anfrage vorlegen.
Wie sollte ein Multi-Tenant-Publikum funktionieren?
Audience identifiziert die geschützte Ressource, während der Mandantenkontext die Organisation identifiziert, deren Datensätze und Richtlinien gelten. Binden Sie sowohl den Status als auch den Partitionsautorisierungsstatus. Ein gültiges Ressourcentoken für Mandanten A darf nicht gegen Mandanten B verwendet werden können, weil ein Aufrufer einen Pfad oder Header geändert hat. Mandanten in Routing-, Cache-, Replay- und Idempotenzschlüsseln einschließen und identische Domänenkennungen für Mandanten testen.
Wann ist Token-Introspektion angemessen?
Introspektion kann den aktuellen Token-Status und die zentrale Widerrufung auf Kosten der Latenz- und Verfügbarkeitsabhängigkeit bereitstellen. Lokal validierte Token verringern diese Abhängigkeit, beruhen jedoch auf Ablauf- und verteilten Widerrufsrichtlinien. Wählen Sie nach Risiko- und Betriebsmodell. Keine der beiden Optionen macht es erforderlich, den aktuellen Agentenstatus, die delegierte Befugnis und den Geschäftszustand nach der Token-Validierung zu überprüfen.
Überprüfen Sie die Bereiche mit den Teams, die die geschützten Operationen besitzen, nicht nur die Identitätsplattform. payments:write kann für einen IAM-Administrator angemessen eng aussehen, während er mehrere Käufereinheiten, Schienen und Zieländerungen abdeckt. Dokumentieren Sie, welche Serviceoberfläche der Umfang öffnet, und listen Sie dann die Transaktionsfakten auf, die außerhalb des Umfangs bleiben.
Die Erweiterung eines bestehenden Endpunkts unter einem alten Scope kann Autorität schaffen, die keine Zustimmung, Erteilung oder Richtlinienüberprüfung in Betracht zieht.
Ein gültiges Legacy-Token sollte die neue Geschäftsmaßnahme nicht erben, nur weil das Routing noch seinen Anwendungsbereich akzeptiert.