AI Agent Authentication vs Autorisierung: Referenzarchitektur
Separate AI-Agent-Authentifizierung, Servicezugriff, delegierte Autorität und Vollmacht mit klaren Vertrauensgrenzen und Kontrolleigentum.
Die Authentifizierung von KI-Agenten überprüft eine Identität oder einen Berechtigungsnachweis. Die Autorisierung von KI-Agenten entscheidet darüber, ob diese Identität eine angeforderte Aktion ausführen kann. Unternehmensagenten benötigen zwei weitere Unterscheidungen: Zugang zu einem Dienst und delegierte Geschäftsautorität.
Die AI Agent Authorization Implementation Guide Diese Referenzarchitektur macht die Komponentengrenzen explizit, so dass ein Identitätstoken nicht mit der Genehmigung einer Geschäftsmaßnahme verwechselt wird.
Vier Vertrauensgrenzen ziehen
[Agent runtime]
| signed request and access token
v
[Identity verifier] ---- who presented this credential?
v
[Resource server] ------ may it access this service?
v
[Authority service] ---- was this task delegated, under which limits?
v
[Policy enforcement] --- may this exact request run now?
v
[Domain system] -------- execute idempotently and report outcome
Die Boxen können die Infrastruktur gemeinsam nutzen, aber ihre Entscheidungen sollten sichtbar bleiben. Der Ressourcenserver validiert den Herausgeber, die Signatur, die Zielgruppe, den Ablauf und die Bereiche. Der Autoritätsdienst löst die vertretene Organisation, den Menschen oder den Dienst und seine Gewährung. Policy vergleicht die kanonische Anfrage mit dieser Autorität und dem aktuellen Domain-Status.
Weisen Sie jeder Steuerung einen Job zu
| Kontrollieren | Es kann sich | Sie kann nicht allein |
|---|---|---|
| Arbeitslastkennung | welche Laufzeit einen Schlüssel steuert | Wer einen Kauf genehmigt hat |
| Access-Token | Zugriff auf eine beabsichtigte API und Scopes | genaue Betrags- oder Bestimmungsbehörde |
| Agentenregister | Eigentümer, Version und Lebenszyklusstatus | Erlaubnis für diese Transaktion |
| Delegierte Finanzhilfe | zugewiesene Aktionen und Limits | ob der Live-Business-Staat es ihnen noch erlaubt |
| Grundsatzentscheidung | Genehmigung, Verweigerung oder Genehmigung erforderlich | Ob die Ausführung später erfolgreich war |
| Eingang der Maßnahme | Was ein Unterzeichner aufgezeichnet hat | Jede Quelle ist wahr |
RFC 8707 definiert Ressourcenindikatoren, die verhindern, dass ein für eine Ressource bestimmtes Token für eine andere Ressource verwendet wird. DPoP Sie können die Wiederholung eines gestohlenen Inhaber-Tokens reduzieren.
Verbindliche Identität zum Antrag
Vertrauen Sie nicht auf von Anrufern geschriebene Identitäts-Header. Das Gateway sollte sie entfernen und den verifizierten Kontext nach der Authentifizierung regenerieren.
type VerifiedExecutionContext = {
tenantId: string;
principalId: string;
agentId: string;
credentialThumbprint?: string;
tokenAudience: string;
authorityDigest: string;
requestDigest: string;
};
Die requestDigest Das Autorisierungsergebnis muss diesen Digest zurückgeben. Der Ausführungsadapter vergleicht ihn unmittelbar vor dem Versand.
Für die interaktive Autorisierung sollten die Identitäten von Mensch und Agent unterschiedlich sein. Aufzeichnen, welche Person die Autorität delegiert hat, welcher Agent gehandelt hat und welche Organisation rechenschaftspflichtig ist.
Testgrenzenverwirrung
Eine nützliche Architekturüberprüfung enthält negative Pfade:
- ein gültiges Token dem falschen Publikum präsentieren;
- Injizieren
x-tenant-idund bestätigen, dass das Gateway es ersetzt; - einen Agenten im Register zu deaktivieren, während sein Token gültig bleibt;
- Genehmigung eines Antrags und Übermittlung eines geänderten Bestimmungsorts;
- Rufen Sie den Domaindienst über eine direkte interne Adresse an;
- Drehen Sie den Workload-Schlüssel und testen Sie die Old-Key-Richtlinie zum Ereigniszeitpunkt.
Die OAuth Umfang und Business Authority Vergleich geht tiefer auf Access Tokens. Laufzeitberechtigung stellt den Vollstreckungsvertrag zur Verfügung. Digitale Identität Leitlinien sind nützlich für die Identitätssicherung, während die AI Risk Management Framework umfasst eine breitere KI-Governance und Risikobehandlung.
Intelliger beschreibt seine aktuellen öffentlichen Produktschichten bei Agent TrustOATI ist eine Entwicklervorschau, daher muss die Bereitstellungssicherheit in der Kundenumgebung bewertet und vor der Verwendung in der Produktion unabhängig überprüft werden.
Fragen zur Architekturprüfung
Ist ein Agent ein Benutzer, eine Anwendung oder ein Workload?
Es kann an allen drei Beziehungen teilnehmen, aber eine Kennung sollte sie nicht verwischen. Die Organisation oder der Mensch ist rechenschaftspflichtig, der logische Agent hat einen Eigentümer und einen Lebenszyklus, und jede laufende Instanz verwendet einen Workload-Anmelder. Zeichnen Sie den dargestellten Auftraggeber und den handelnden Agenten separat auf. Dies ermöglicht es einem nachgeschalteten Dienst, "das Finanzteam durch AP Agent" von einer menschlichen interaktiven Sitzung zu unterscheiden und ermöglicht es Betreibern, einen Laufzeitschlüssel zu drehen, ohne die Geschäftsidentität zu ändern.
Wo sollte Token Exchange stattfinden?
Platzieren Sie den Austausch in einem vertrauenswürdigen Gateway oder Credential-Broker, der die beabsichtigte Upstream-Ressource kennt. Er sollte den eingehenden Kontext validieren, einen engen Upstream-Token erhalten und verhindern, dass der ursprüngliche Credential zu einem anderen Server übertragen wird. Downstream-Dienste validieren weiterhin den Emittenten und die Zielgruppe. Zeichnen Sie die Akteur-, Subjekt-, Quell- und Zielressourcen auf, damit ein Ermittler die verwendete Identitätsbeziehung rekonstruieren kann, ohne die Tokenwerte zu protokollieren.
Löst gegenseitiges TLS die Agentenautorisierung?
Mutual TLS kann Workloads authentifizieren und eine Verbindung schützen. Es drückt nicht die Geschäftsaufgabe, den Betrag, das Ziel oder die genehmigende Person aus. Verwenden Sie es, um den Pfad zwischen Gateway und geschütztem Dienst zu sichern, dann den verifizierten, integritätsgeschützten Autorisierungskontext zu bestehen oder den Dienst zur Lösung der Entscheidung zu verpflichten. Akzeptieren Sie keine von Anrufern erstellten Autorisierungs-Header, nur weil die Verbindung von einem internen Netzwerk kam.
Wie kreuzt der Widerruf die Schichten?
Das Deaktivieren eines Workload-Schlüssels, eines Agenteneintrags, eines delegierten Grants oder eines Benutzerkontos entspricht unterschiedlichen Incident-Anforderungen. Definieren Sie, welches Ereignis welche Requests stoppen soll und wie schnell jeder Durchsetzungspunkt es lernt. Eine kompromittierte Laufzeit kann einen Schlüssel- und Grant-Widerruf erfordern. Ein Besitzer-Abgang kann den Agenten bis zur Neuzuweisung aussetzen. Testen Sie aktive Sitzungen und in die Warteschlange gestellte Arbeit, da ein Widerruf, der nur neu ausgegebene Token betrifft, eine Lücke lässt.
Welche Beweise sollte jede Schicht aussenden?
Der Identitätsverifikator zeichnet das Anmeldeergebnis und verifizierte Identifikatoren auf. Der Ressourcenserver zeichnet die Zielgruppen- und Umfangsdurchsetzung auf. Der Autoritätsdienst zeichnet den Status und die Einschränkungen der Gewährung auf. Die Richtlinie zeichnet den genauen Anforderungsverdau und die Gründe auf. Der Domänenadapter zeichnet den Versand und das beobachtete Ergebnis auf. Korreliert diese Datensätze, aber hält ihre Ansprüche getrennt. Ein Gateway-Erfolgsereignis sollte nicht als Anbieterabwicklung oder abgeschlossene Geschäftsarbeit dargestellt werden.
Während der Architekturüberprüfung ziehen Sie eine Bypass-Linie um jedes Feld. Fragen Sie, was passiert, wenn ein Anrufer den Ressourcenserver ohne das Gateway erreicht, wenn ein Workload-Token die Agent-Suspension überlebt oder wenn ein interner Dienst Identitäts-Headern von einem Netzwerk-Peer vertraut. Die Antworten sollten eine erzwungene Dienstidentität, Netzwerkbeschränkung oder lokale Entscheidungsprüfung nennen. "All normal traffic uses the gateway" ist eine Betriebsannahme, keine Kontrolle.