Absicherung der Identität von KI-Agenten mit X.509-PKI auf AWS

Wenn KI-Agenten auf Datenbanken, APIs und sensible Geschäftsvorgänge zugreifen, wird die Etablierung kryptografischer Identität durch eine X.509-Public-Key-Infrastruktur (PKI) zu einer kritischen Anforderung. Die zentrale Herausforderung besteht darin nachzuweisen, welcher Agent eine Anfrage gestellt hat, Fälschungen zwischen Agenten zu verhindern und zu bestätigen, dass jeder Agent nur im Auftrag eines autorisierten Benutzers handelt. Traditionelle Ansätze wie das Teilen von API-Schlüsseln zwischen Komponenten oder das Weiterreichen von OAuth-Tokens durch Agentenketten genügen nicht den Zero-Trust-Anforderungen, die Enterprise-Deployments stellen.

Multi-Agenten-KI-Frameworks verwenden zunehmend das Model Context Protocol (MCP), um Agenten mit externen Tools und Datenquellen zu verbinden. MCP definiert, wie ein von einem Large Language Model (LLM) angetriebener Agent Tools wie Datenbankabfragen oder E-Mail-Vorgänge aufruft. MCP hat jedoch keinen integrierten Authentifizierungsstandard. Es ist designbedingt transportagnostisch. Daraus entsteht eine kritische Lücke: Ohne geeignete Identitätsmechanismen könnte jede Komponente sich als Agent ausgeben, abgefangene Zugangsdaten wiederverwenden oder Tools ohne Autorisierung aufrufen.

In diesem Beitrag zeigen wir Ihnen, wie Sie diese Lücke mit Keyfactor EJBCA in Kombination mit AWS-Services schließen können. EJBCA ist eine PKI-Plattform, die High-Availability-Deployment, REST-API-Automatisierung und Online Certificate Status Protocol (OCSP)-Validierung unterstützt. Die Referenzarchitektur verwendet vier sich ergänzende Sicherheitsmechanismen. Erstens bieten signierte Anfrageumschläge kryptografischen Possession-Nachweis bei jedem Agentenaufruf. Zweitens autorisieren vom Benutzer signierte Delegierungsassertions Agenten, ohne Zugangsdaten weiterzugeben. Drittens begrenzen RFC 8693-Zielgruppenscoped-Tokens den Expositionsbereich einer einzelnen Token-Offenlegung. Viertens propagiert die Echtzeit-OCSP-Revocation-Prüfung Zugangsdatenänderungen sofort an alle Agenten.

Die Lösung verwendet Amazon Bedrock für die LLM-Inferenz über das AWS Strands Agents SDK. Während diese Referenzarchitektur eine Datenbank als geschützte Ressource verwendet, gilt das gleiche Authentifizierungsmuster für jeden MCP-kompatiblen Toolserver. Der vollständige Quellcode für alle Beispiele ist im begleitenden GitHub-Repository verfügbar.

Über Keyfactor EJBCA

Keyfactor bietet eine weit verbreitete Machine-Identity-Management-Plattform, die laut Keyfactor von mehr als 1,500 Enterprise-Kunden weltweit genutzt wird. Diese Organisationen stammen aus den Bereichen Finanzdienstleistungen, Gesundheitswesen, Fertigung und Regierung. Keyfactor hilft Organisationen, kryptografisches Vertrauen durch Zertifikatslebenszyklusmanagement, PKI-Betrieb und Machine-Identity-Governance aufzubauen und aufrechtzuerhalten.

EJBCA Enterprise ist die Certificate-Authority-(CA)- und PKI-Plattform von Keyfactor, die für High-Availability-Deployment und REST-API-Automatisierung konzipiert ist. Als Enterprise-Produkt verfügbar, bietet EJBCA X.509-Zertifikatsausstellung, OCSP-Validierung, Verteilung von Zertifikatssperrlisten (CRL) und vollständiges Zertifikatslebenszyklusmanagement sowohl über eine Webkonsole als auch über eine REST-API. EJBCA unterstützt das Deployment On-Premises, in Containern oder auf Amazon Elastic Compute Cloud (Amazon EC2).

Die Partnerschaft zwischen AWS und Keyfactor vereint AWS verwaltete Services (Amazon Bedrock, AWS Secrets Manager, Amazon Relational Database Service (Amazon RDS)) mit PKI-Infrastruktur, die Zertifikatslebenszyklusmanagement, automatisierte Registrierung und Echtzeit-Revocation unterstützt. Diese Kombination schließt eine Lücke im KI-Agenten-Ökosystem. Während AWS die Compute-, Storage- und KI-Inferenz-Schichten bereitstellt, liefert Keyfactor die kryptografische Identitätsschicht, die Agenten an überprüfbare, sperrbare, kurzlebige Zugangsdaten bindet. Diese gemeinsame Referenzarchitektur, die von den Engineering-Teams von AWS und Keyfactor gemeinsam entwickelt wurde, zeigt, wie diese Technologien integriert werden. Sie können die hier gezeigten Muster an Ihre eigenen Multi-Agenten-Deployments anpassen.

Lösungsübersicht

Die Architektur implementiert drei Authentifizierungsschichten, die jeweils eine andere Vertrauensgrenze in der Agentenkommunikationskette adressieren. Diese drei Schichten nutzen die vier zuvor eingeführten Sicherheitsmechanismen: signierte Umschläge für den Possession-Nachweis, Delegierungsassertions für autorisierung ohne Zugangsdaten, Zielgruppenscoped-Tokens zur Begrenzung der Exposition und OCSP für die Echtzeit-Revocation. Die Mechanismen werden schichtenübergreifend kombiniert, wie in der folgenden Tabelle gezeigt.

Abbildung 1 zeigt die drei Authentifizierungsebenen und wie Anmeldeinformationen zwischen dem Benutzer, den Agents und dem MCP-Toolserver fließen. Das Diagramm veranschaulicht die Trennung zwischen Benutzeranmeldeinformationen (die im Anmeldevorgang verbleiben), Agent-Anmeldeinformationen (pro Agent festgelegt) und der Delegierungskette, die sie verbindet.

Abbildung 1: Drei-Ebenen-PKI-Authentifizierungsarchitektur für KI-Agentensysteme auf AWS

Abbildung 2 veranschaulicht den detaillierten Datenverkehr während einer typischen Benutzersitzung. Er zeigt die Abfolge der Authentifizierungsschritte von der Anmeldung über die Zertifikatausstellung, die Agent-Delegierung und den Tool-Aufruf bis hin zur Sitzungsbereinigung.

Abbildung 2: Authentifizierungs-Traffic-Flow vom Benutzer-Login über Agent-Delegierung, Tool-Aufruf bis hin zur Sitzungsbereinigung

Verwendete AWS-Services

Die folgenden AWS-Services bilden die Grundlage der Referenzarchitektur.

Lösungsdurchlauf

Die folgenden Schritte durchlaufen jede Komponente der Architektur, vom anfänglichen Benutzer-Login bis zur Sitzungsbereinigung. Jeder Schritt baut auf dem vorherigen auf und etabliert eine Vertrauenskette, die den menschlichen Benutzer mit der endgültigen Tool-Ausführung verbindet.

Voraussetzungen

• Ein aktives AWS-Konto mit Zugriff auf Amazon Bedrock, Amazon RDS for MySQL, Amazon SES und AWS Secrets Manager.
• Keycloak 26.2 oder höher (erforderlich für den RFC 8693-Standard-Token-Austausch. Frühere Versionen verwenden einen Legacy-Austausch, der inkompatibel ist).
• Keyfactor EJBCA Enterprise mit REST API V1 und einem konfigurierten OCSP-Responder.
• EJBCA-API-Administratorzertifikat (api-admin.p12) für die REST-API-Authentifizierung.
• Python 3.9+ Entwicklungsumgebung.
• Vertrautheit mit X.509-Zertifikaten, OCSP, OAuth 2.0, RSA digitalen Signaturen und PKCS#12-Schlüsselspeichern.

Schritt 1: Benutzer-Login, Zertifikatsausstellung und Delegierungs Erstellung

Der Login-Flow etabliert die Identität des Benutzers über drei Mechanismen und delegiert dann die Autorität an die KI-Agenten, ohne die Anmeldeinformationen des Benutzers weiterzugeben. Diese Trennung ist entscheidend: Agenten erhalten einen Autorisierungsnachweis, ohne jemals den privaten Schlüssel des Benutzers oder das OAuth-Token der gesamten Sitzung zu besitzen.

Zuerst authentifiziert die Anwendung den Benutzer gegen Keycloak unter Verwendung eines OAuth 2.0 Password Grant und erhält ein Access-Token und ein Refresh-Token für die gesamte Sitzung. Unmittelbar danach führt die Anwendung einen RFC 8693-Token-Austausch durch, um ein Token mit eingeschränktem Geltungsbereich (Downscoped Token) zu erhalten. Die Zielgruppe (Audience) dieses Tokens ist auf den MCP-Server beschränkt. Nur dieses eingeschränkte Token wird an die Agenten übergeben. Falls es versehentlich offengelegt wird, kann es auf keinen anderen Service in der Organisation zugreifen.

Zweitens generiert die Anwendung lokal ein RSA 2048+ Schlüsselpaar und übermittelt eine Certificate Signing Request (CSR) an EJBCA über den pkcs10enroll REST-API-Endpunkt. EJBCA signiert die CSR und gibt das Zertifikat zurück. Die Anwendung bündelt das Zertifikat und den privaten Schlüssel in einem PKCS12-Container und speichert ihn in AWS Secrets Manager. Der private Schlüssel verlässt niemals die Anwendungsgrenze. Er wird nicht an EJBCA gesendet, nicht mit Agenten geteilt und nicht auf dem Dateisystem gespeichert. Drei Agentenzertifikate werden unter Verwendung desselben CSR-basierten Flows ausgestellt, eines pro Agentenrolle.

Drittens signiert der private Schlüssel des Benutzers eine Delegierungsassertion. Dies ist ein JSON-Dokument, das die SHA-256-Fingerabdrücke aller drei Agentenzertifikate sowie den Subjektnamen des Benutzers, die Ausstellungszeit und das Ablaufdatum auflistet. Diese Delegierung beweist, dass der Benutzer diese bestimmten Agenten autorisiert hat, in seinem Namen zu handeln. Agenten tragen diese Delegierung anstelle des Zertifikats des Benutzers.

# RFC 8693 Token Exchange - downscope to MCP audience
downscoped_token = keycloak.token_exchange(
    original_token, audience="mysql-mcp-server", scope="database:write"
)
# Client-side key generation (user key never leaves this flow)
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
csr = build_csr(private_key, f"CN={username},E={username}@org.com")
user_cert = ejbca.pkcs10enroll(csr, ca_name="UserCA")
# User signs delegation over agent cert fingerprints
delegation = mint_delegation(
    username=username,
    user_cert_pem=user_cert,
    user_key_pem=private_key_pem,
    agent_cert_pems=[orch_cert, mysql_cert, email_cert]
)
# Result: {sub, agent_fingerprints[], iat, exp, user_cert_pem, signature_b64}

Schritt 2: Signierte Agent-zu-Agent-Umschläge

Wenn der Orchestrator-Agent eine Anfrage an einen Sub-Agent weiterleitet (z. B. den MySQL-Agent oder den Email-Agent), übergibt er nicht einfach sein Zertifikat zur Identifikation. Stattdessen signiert er die gesamte Anfrage-Payload, einschließlich des Tool-Namens, der Argumente, eines Zeitstempels und einer kryptografisch zufälligen Nonce, mit seinem privaten Schlüssel mittels RSA-PSS-SHA256. Die resultierende signierte Hülle (Signed Envelope) bietet einen Possession-Nachweis (Proof-of-Possession). Der empfangende Agent kann überprüfen, dass der Aufrufer tatsächlich den privaten Schlüssel besitzt, der zum vorgelegten Zertifikat gehört.

Der empfangende Agent führt sechs Validierungsprüfungen an der Hülle durch, bevor er die Anfrage verarbeitet:

1. Signaturverifizierung: Weist nach, dass der Absender den privaten Schlüssel besitzt (proof-of-possession).
2. Zeitstempel-Frische: Der Envelope muss innerhalb von ENVELOPE_MAX_AGE_SECONDS (Standard: 60 Sekunden) zur aktuellen Zeit liegen.
3. Nonce-Eindeutigkeit: Der ReplayCache lehrt jede zuvor gesehene Nonce ab und verhindert so das Wiederholen von Anfragen (Request Replay).
4. CA-Kettenvalidierung: Das Zertifikat des Absenders muss auf die vertrauenswürdige CA zurückführen (UserCA.pem).
5. Rollenautorisierung: Der Rollen-Suffix des Zertifikats-CN muss in ALLOWED_CALLER_ROLES für diesen Agenten enthalten sein.
6. OCSP-Sperrprüfung: Eine Echtzeitprüfung gegen EJBCA bestätigt, dass das Zertifikat nicht widerrufen wurde.

Wenn der Orchestrator denselben Prompt erneut senden muss (zum Beispiel nach einem vorübergehenden Fehler), muss er einen neuen Envelope mit einer frischen Nonce erstellen. Alte Envelopes können nicht wiedergegeben werden, auch nicht vom legitimen Absender.

# Orchestrator signs request to sub-agent
envelope = sign_envelope(
    payload={"tool": "query_database", "args": {"sql": "SELECT ..."}},
    cert_pem=orchestrator_cert_pem,
    private_key_pem=orchestrator_key_pem
)
# envelope: {payload_b64, cert_pem, timestamp, nonce, signature_b64, alg}
# Sub-agent verifies (six checks)
verified_payload = verify_envelope(
    envelope,
    allowed_role="orchestrator-agent",
    ca_cert_pem=ca_pem,
    replay_cache=cache
)

Schritt 3: MCP-Server-Authentifizierung

Der MCP-Server (FastMCP) ist die letzte Vertrauensgrenze, bevor eine Datenbankoperation ausgeführt wird. Er führt bei jedem Tool-Aufruf vier Validierungsprüfungen durch und implementiert damit Defense-in-Depth. Selbst wenn eine Berechtigung einem unbefugten Zugriff unterliegt, verhindern die übrigen Prüfungen unbefugte Operationen.

Die Authentifizierungssequenz:

1. Token-Introspektion: Ein POST an den Keycloak- /token/introspect Endpunkt überprüft, ob das Token aktiv ist und seine Zielgruppe (Audience) „mcp-server“ enthält. Ein Full-Session-Token mit der falschen Zielgruppe wird abgelehnt.
2. Envelope-Verifizierung: Der signierte Envelope des Agenten wird auf Signaturkorrektheit, Zeitstempel-Frische, Nonce-Eindeutigkeit, CA-Kettenvertrauen, Rollenübereinstimmung (mysql-agent) und OCSP-Nichtwiderruf geprüft.
3. Delegierungsverifizierung: Die Delegierungs assertion des Benutzers wird validiert. Die Signatur beweist, dass der Schlüsselinhaber des Benutzers diese Delegierung autorisiert hat, der Zertifikats-Fingerprint des aufrufenden Agenten in der autorisierten Liste erscheint, und das Zertifikat des Benutzers wird über OCSP überprüft.
4. Identitätsabgleich: Der Token-Benutzername, das Delegierungssubjekt und der Zertifikats-CN-Präfix des Agenten müssen alle übereinstimmen. Dies bestätigt eine einzelne konsistente Identitätskette vom Benutzer bis zur Tool-Ausführung.

# MCP Server - Four validation checks
# 1. Token: must be active with correct audience
info = introspect(token)
assert info["active"] and "mcp-server" in info["aud"]
# 2. Envelope: proof-of-possession + freshness + replay + CA + role + OCSP
payload = verify_envelope(envelope, "mysql-agent", ca_pem, replay_cache)
# 3. Delegation: user authorized this agent + user cert not revoked
claims = verify_delegation(delegation, agent_cert_pem, ca_pem)
# 4. Cross-check: consistent identity chain
assert token_username == claims["sub"] == agent_cn.rsplit("_", 1)[0]
# All checks passed - execute tool
result = execute_sql(payload["args"]["sql"])

Schritt 4: Replay-Prävention

Jeder signierte Envelope trägt eine eindeutige Nonce, eine 128-bit-kryptografisch zufällige Hexadezimalzeichenkette, die mit Pythons secrets-Modul erzeugt wird. Der ReplayCache ist ein thread-sicherer In-Memory-Speicher, der sich jede Nonce merkt, bis ihr Frische-Fenster abläuft (2x ENVELOPE_MAX_AGE_SECONDS). Wenn dieselbe Nonce in einer zweiten Anfrage auftaucht, wird der Umschlag sofort abgelehnt, selbst wenn seine Signatur gültig und der Zeitstempel aktuell ist.

Die Zeitstempel-Validierung ergänzt die Nonce-Prüfung. Der Zeitstempel eines Umschlags muss innerhalb von ENVELOPE_MAX_AGE_SECONDS (Standard 60 Sekunden) der aktuellen Serverzeit liegen. Zusammen adressieren diese Mechanismen vier Szenarien unbefugten Zugriffs:

• Aufgezeichnetes Replay: Ein unbefugter Nutzer erfasst einen gültigen Umschlag und sendet ihn später erneut. Die Nonce wurde bereits gesehen.
• Verzögerte Zustellung: Ein während der Übertragung abgefangener Umschlag kommt nach dem Frischefenster an. Die Zeitstempel-Prüfung schlägt fehl.
• Wiederverwendung alter Anfragen: Ein alter, von einem Proxy zwischengespeicherter Umschlag wird erneut übermittelt. Sowohl die Nonce- als auch die Zeitstempel-Prüfung schlagen fehl.
• Vorberechnete Fälschung: Ein unbefugter Nutzer kann zukünftige Noncen nicht vorhersagen, um Umschläge vorab zu signieren.

Schritt 5: Clientseitige Schlüsselerzeugung

Eine kritische Sicherheitseigenschaft dieser Architektur ist, dass private Schlüssel lokal erzeugt und niemals an ein externes System übertragen werden. Die Anwendung erzeugt RSA 2048+ Schlüsselpaare unter Verwendung der Python-Bibliothek cryptography. Sie erstellt eine CSR, die nur den öffentlichen Schlüssel und Subject-Informationen enthält, und sendet nur die CSR über den pkcs10enroll Endpunkt an EJBCA.

EJBCA validiert die CSR, wendet das Zertifikatsprofil an (7 Tage Gültigkeit, Key-Usage-Einschränkungen), signiert sie mit dem CA-Schlüssel und gibt das ausgestellte Zertifikat zurück. Die Anwendung verpackt dann den lokal gehaltenen privaten Schlüssel zusammen mit dem zurückgegebenen Zertifikat in einen PKCS12-Container und speichert ihn in AWS Secrets Manager.

Dieses Design bietet mehrere Sicherheitseigenschaften:

• Der private Schlüssel des Nutzers wird nur beim Login verwendet, um die Delegierungs-Assertion zu signieren. Er wird niemals mit Agents geteilt.
• Der private Schlüssel jedes Agents wird nur von diesem Agent verwendet, um Umschläge zu signieren. Er wird niemals zwischen Agents geteilt.
• EJBCA sieht oder speichert niemals private Schlüssel. Es fungiert rein als Zertifizierungsstelle.
• Falls Secrets Manager einem unbefugten Zugriff ausgesetzt ist, fügt das PKCS12-Passwort (separat gespeichert) eine zusätzliche Schutzebene hinzu.
• Schlüsselmaterial kann unabhängig rotiert werden, indem man sich beim nächsten Login mit einer neuen CSR neu registriert.

Schritt 6: Vollständiger Logout und Credential-Revocation

Der Logout löst eine Revocation-Kaskade aus, die sofort alle ausstehenden Credentials ungültig macht. Die Sequenz führt dazu, dass nach Abschluss keine gültigen Credentials mehr verbleiben:

1. Benutzerzertifikat in EJBCA widerrufen: Dies macht sofort alle ausstehenden Delegierungen ungültig, da die Delegierungsprüfung das Benutzerzertifikat in Echtzeit über OCSP überprüft.
2. Alle drei Agentenzertifikate widerrufen: Dies macht alle ausstehenden signierten Envelopes ungültig, da die Envelope-Verifizierung OCSP umfasst.
3. Alle Secrets aus dem AWS Secrets Manager löschen: Verwendung von ForceDeleteWithoutRecovery für sofortige Entfernung ohne Wiederherstellungsfenster.
4. Keycloak-Sitzung beenden: Macht das Downscoped-Token über den Sitzungsbeendigungs-Endpunkt ungültig.

Die Widerrufskaskade ist die zentrale Sicherheitseigenschaft. Das Widerrufen eines einzelnen Benutzerzertifikats auf der PKI-Ebene hebt umgehend alle nachgelagerten Agentenbefugnisse auf, ohne dass Tokens einzeln widerrufen, Sitzungen gelöscht oder jeder Agent kontaktiert werden muss. OCSP bietet den Verbreitungsmechanismus, und da jede Anfrage OCSP prüft, ist die Wirkung sofort.

Sicherheitsüberlegungen

Die Designentscheidungen in dieser Architektur adressieren mehrere Sicherheitseigenschaften, die für Produktions-Multi-Agenten-Deployments wichtig sind.

Isolierung privater Schlüssel. Der private Schlüssel des Benutzers existiert nur während des Login-Flows und wird ausschließlich zum Signieren der Delegierung verwendet. Agentenschlüssel sind pro Agent abgegrenzt und werden niemals geteilt. Kein Schlüsselmaterial überschreitet Vertrauensgrenzen.

Delegierung im Vergleich zur Weitergabe von Anmeldeinformationen. Agenten weisen ihre Befugnis durch eine kryptografische Kette nach (Delegierung zu Agenten-Fingerprint zu Envelope-Signatur), ohne jemals Benutzeranmeldeinformationen zu besitzen. Wird ein Agentenschlüssel offengelegt, wird nur der Schlüssel dieses Agentens enthüllt, nicht der des Benutzers.

Audience-abgegrenzte Tokens. Der RFC 8693 Token-Austausch erzeugt ein Token, das nur vom MCP-Server akzeptiert wird. Ein versehentlich offengelegtes Downscoped-Token kann sich weder gegen Keycloak-Admin-APIs noch gegen andere Dienste oder gar eine andere MCP-Server-Instanz authentifizieren.

Schutz vor Replay-Angriffen. Die Kombination aus Nonces pro Anfrage und einem 60-sekündigen Frischefenster bestätigt, dass jede Anfrage nur einmalig und zeitlich begrenzt ist. Der ReplayCache ist threadsicher und selbstreinigend.

Fail-closed-Design. Jeder Validierungsfehler führt zu sofortiger Ablehnung. OCSP nicht erreichbar: ablehnen. Ungültige Signatur: ablehnen. Abgelaufener Zeitstempel: ablehnen. Wiederholte Nonce: ablehnen. Falsche Audience: ablehnen. Es gibt keine sanfte Verschlechterung bei Sicherheitsprüfungen.

Widerrufskaskade. Das Widerrufen eines Benutzerzertifikats macht umgehend alle Delegierungen, alle Agentenbefugnisse und alle ausstehenden Envelopes ungültig. Dies wird durch Echtzeit-OCSP verbreitet, ohne dass eine individuelle Bereinigung von Anmeldeinformationen erforderlich ist.

Nur vorwärtsgerichtete Vertrauenskette. Die ALLOWED_CALLER_ROLES -Map erzwingt, dass nur orchestrator-agent aufrufen darf mysql-agent und email-agent. Sub-Agenten können einander nicht aufrufen, können nicht nach oben zum Orchestrator aufrufen und können sich nicht als Benutzer ausgeben.

KI-Governance-Überlegungen

Die PKI-Architektur bietet eingebaute Verhaltensgrenzen für die KI-Agenten in diesem System. Produktions-Deployments sollten Amazon Bedrock Guardrails verwenden, um Inhaltsfilterung, Themenvermeidung und Grounding-Prüfungen für Agentenantworten durchzusetzen, neben den in diesem Beitrag beschriebenen PKI-basierten Zugriffskontrollen.

• Tool-Grenzen: Der KI-Agent arbeitet unter strengen Tool-Einschränkungen. Er kann nur vordefinierte MCP-Tools aufrufen (execute_sql, describe_table, list_tables). Der Agent kann keinen beliebigen Code ausführen oder auf Ressourcen außerhalb seines Zertifikatsumfangs zugreifen.
• Menschliche Aufsicht: Alle Agentenaktionen werden protokolliert und sind auditierbar. AWS CloudTrail erfasst AWS-API-Aufrufe, und der MCP-Server protokolliert jede validierte Tool-Aufruf mit der vollständigen Identitätskette (Benutzer, Agent, Zeitstempel und Operation).
• Datenverarbeitung: Benutzerabfragen und Ergebnisse bleiben innerhalb der Grenze der authentifizierten Sitzung. Das zielgruppenspezifische Token beschränkt den Datenzugriff auf die jeweilige MCP-Server-Instanz.
• Zertifikatsbasierte Verhaltensgrenzen: Agents können nur Tools aufrufen, für die sie gültige Zertifikate besitzen. Ein Agent ohne mysql-agent Zertifikat kann nicht auf die Datenbank zugreifen, unabhängig davon, welche Anweisungen das LLM generieren mag.

Erweiterung der Architektur

Sie können diese Architektur erweitern, um zusätzliche Agent-Typen, horizontale Skalierung und Multi-Tenant-Isolation zu unterstützen. Die folgenden Absätze beschreiben die gängigsten Erweiterungspunkte.

• Um neue Agent-Typen hinzuzufügen, müssen Sie nur einen Eintrag in ALLOWED_CALLER_ROLEShinzufügen. Zertifikate werden bei der Anmeldung automatisch ausgestellt, und die Delegierungsassertion enthält dynamisch den Fingerabdruck des neuen Agents. Es sind keine Infrastrukturänderungen erforderlich.
• Für die horizontale Skalierung können Sie den OCSP-Responder von EJBCA im Hochverfügbarkeitsmodus hinter einem Load Balancer betreiben. AWS Secrets Manager unterstützt hohe Anforderungsraten, die für diese Workload geeignet sind. Die ReplayCache kann für verteilte Bereitstellungen durch Amazon ElastiCache-backed gespeichert werden.
• Um die Architektur für die Produktion abzusichern, können Sie hardwarebasierte EJBCA-Signaturschlüssel mit Hardware-Sicherheitsmodul (HSM) über AWS CloudHSM oder ein lokales HSM verwenden. OCSP Response Stapling reduziert die Validierungslatenz, und Certificate-Transparency-Logs bieten eine vollständige Prüfhistorie der ausgestellten Zertifikate.
• Für Multi-Tenant-Bereitstellungen können Sie mandantenspezifische Certificate Authorities oder mandantenspezifische Delegation Authorities erstellen, um eine kryptografische Tenant-Isolation zu erreichen. In Kombination mit mandantenspezifischen AWS-Konten ermöglicht dies eine starke Isolation zwischen den Tenants.
• Sie können die PKI-basierte Agent-Identität auch durch AWS Identity and Access Management (IAM)-Rollen ergänzen. Verwenden Sie PKI für die Agent-zu-Agent-Authentifizierung und IAM für die AWS-Serviceautorisierung. Die beiden Systeme funktionieren unabhängig voneinander und bieten so eine Verteidigung in der Tiefe.

Aufräumen

Um laufende Kosten zu vermeiden, entfernen Sie die im Zuge dieser Anleitung erstellten Ressourcen:

• Löschen Sie die Amazon RDS for MySQL-Instance (oder den AWS CloudFormation-Stack, falls Sie das skriptbasierte Setup verwendet haben).
• Löschen Sie alle Secrets aus AWS Secrets Manager, einschließlich der Benutzer- und Agent-Zertifikate unter dem mcp/ Präfix.
• Entfernen Sie die verifizierte Absender-E-Mail-Adresse aus Amazon SES.
• Beenden Sie die Amazon-EC2-Instances, auf denen Keycloak und EJBCA ausgeführt werden (sofern für diese Demonstration bereitgestellt).
• Widerrufen und löschen Sie alle Testzertifikate in EJBCA über die EJBCA-Admin-Konsole oder die REST-API.
• Entfernen Sie den Keycloak-Realm (mcp-realm) und die zugehörigen Clients.
• Wenn Sie das skriptbasierte Setup verwendet haben, führen Sie ./scripts/cleanup.sh (Linux) oder ./scripts/cleanup.bat (Windows) aus, um diese Schritte zu automatisieren.

Fazit

In diesem Beitrag haben wir eine Referenzarchitektur für die Sicherung von Kommunikation zwischen KI-Agenten mit X.509-PKI unter Verwendung von Keyfactor EJBCA und AWS-Services vorgestellt. Die Architektur behebt die grundlegende Identitätslücke in Multi-Agent-KI-Systemen durch vier komplementäre Mechanismen:

• Signierte Anfrageumschläge (Signed Request Envelopes) bieten bei jedem Aufruf zwischen Agenten einen kryptografischen Besitznachweis (Proof-of-Possession), wodurch es für unbefugte Parteien deutlich schwieriger wird, die Identität eines Agenten zu fälschen oder seine Anfragen zu wiederholen.
• Vom Benutzer signierte Delegierungsassertionen entkoppeln die Autorisierung von der Weitergabe von Anmeldeinformationen. Agenten weisen nach, dass sie befugt sind, im Namen des Benutzers zu handeln, ohne dessen privaten Schlüssel oder ein vollständiges Sitzungstoken zu besitzen.
• RFC 8693-Zielgruppentokens (Audience-Scoped Tokens) begrenzen den Umfang der Offenlegung bei jeder Token-Offenlegung auf eine einzige Servicegrenze.
• Die Echtzeit-OCSP-Sperrprüfung bestätigt, dass der Widerruf von Anmeldeinformationen im gesamten System sofort wirksam wird. Der Widerruf eines Benutzerzertifikats beendet umgehend alle nachgelagerten Agentenbefugnisse.

Diese Architektur ist framework-agnostisch. Obwohl wir sie mit dem AWS Strands Agents SDK und FastMCP demonstriert haben, gelten dieselben PKI-Muster auch für LangChain, CrewAI, AutoGen oder jedes andere Multi-Agent-Framework, das Tool-Protokolle verwendet. Während sich KI-Agenten verbreiten und Zugang zu zunehmend sensiblen Operationen erhalten, wird die Identitätsinfrastruktur für Agenten von optional zu unverzichtbar.

Um mit dieser Referenzarchitektur zu beginnen, sehen Sie sich das begleitende GitHub-Repositoryan. Weitere Informationen zu den verwendeten Services finden Sie in den folgenden Ressourcen:

• Amazon Bedrock
• Amazon Bedrock User Guide
• Keyfactor EJBCA Enterprise
• MCP Specification
• AWS Strands Agents SDK
• Introducing Strands Agents, an Open Source AI Agents SDK (AWS Open Source Blog-Beitrag)

Über die Autoren