AWS beschrijft X.509-identiteit voor AI-agenten

AWS beschrijft een referentiearchitectuur die AI-agenten met X.509-certificaten een eigen cryptografische identiteit geeft. Het voorbeeld combineert ondertekende verzoeken, door gebruikers ondertekende delegatie, tokens met een beperkte doelgroep en certificaatcontroles via OCSP. MCP heeft daarnaast optionele OAuth-autorisatie voor HTTP-transporten. Die regelt toegang op transportniveau; X.509 identificeert de agent en helpt diens verzoeken te controleren.

Wat X.509 toevoegt aan agentidentiteit

Een X.509-certificaat koppelt een publieke sleutel aan een identiteit. In het voorbeeld van AWS en Keyfactor krijgt elke agent een eigen sleutelpaar en certificaat. Zo kan een ontvangende agent of server controleren welke sleutel een verzoek heeft ondertekend en of het certificaat wordt vertrouwd.

AWS ordent het ontwerp rond drie vertrouwensgrenzen: gebruiker naar systeem, agent naar agent en agent naar MCP-server. De bijbehorende controles zijn onder meer tokens met een beperkte doelgroep, door de gebruiker ondertekende delegatie, ondertekende verzoeken en controle op ingetrokken certificaten. Een certificaat bewijst de technische identiteit van de agent; de delegatie legt vast welke agentcertificaten de gebruiker autoriseert.

MCP-autorisatie en agentidentiteit zijn verschillende lagen

De MCP-specificatie voor autorisatie beschrijft optionele OAuth-autorisatie voor HTTP-transporten. Voor STDIO-implementaties raadt de specificatie aan om in plaats daarvan inloggegevens uit de omgeving te gebruiken.

OAuth voor MCP en certificaatidentiteit vullen verschillende controles in. Een token met een beperkte doelgroep is bedoeld voor een aangewezen dienst. De handtekening op een verzoek koppelt de aanvraag aan de sleutel van de agent. In het AWS-voorbeeld vormen die controles onderdelen van één autorisatieketen.

Van gebruikerslogin tot controle door de MCP-server

De gebruiker meldt zich in het voorbeeld aan via Keycloak. Daarna wisselt het systeem het sessietoken via RFC 8693 in voor een token met de MCP-server als doelgroep. De volledige sessie wordt niet aan de agent doorgegeven.

De applicatie maakt lokaal een RSA-sleutelpaar aan en stuurt een certificaataanvraag naar EJBCA Enterprise. De privésleutel gaat niet naar EJBCA. AWS beschrijft dat het certificaat en de privésleutel als PKCS#12-bundel in AWS Secrets Manager worden opgeslagen en dat agents geen privésleutels met elkaar delen.

Vervolgens ondertekent de gebruiker een delegatieverklaring met onder meer de vingerafdrukken van de agentcertificaten, de gebruikersidentiteit en uitgifte- en vervaltijd. Wanneer een agent een tool aanroept, ondertekent die het verzoek, de toolnaam, de argumenten, het tijdstip en een nonce. De MCP-server controleert het token, de handtekening, de delegatie en de samenhang tussen gebruikersnaam, delegatie en agentcertificaat voordat de aanvraag verdergaat.

AWS beschrijft drie vertrouwensgrenzen in deze keten: van gebruiker naar systeem, tussen agents en van agent naar MCP-server.

Herhaling tegengaan en certificaten intrekken

Een nonce is een eenmalige, willekeurige waarde die hergebruik van een eerder verzoek helpt voorkomen. In het voorbeeld bevat elke ondertekende aanvraag een nonce van 128 bits en een tijdstempel. De standaard maximale leeftijd van een aanvraag is 60 seconden; de replay-cache bewaart de nonce tweemaal die ingestelde periode. Bij een nieuwe poging moet de agent een nieuwe aanvraag met een verse nonce ondertekenen.

Het voorbeeldprofiel geeft certificaten een geldigheid van zeven dagen. AWS beschrijft OCSP-controles bij verzoeken en stelt dat de controle mislukt wanneer de OCSP-responder niet bereikbaar is. Het bedrijf presenteert certificaatintrekking als een snelle intrekkingsketen; de beschreven architectuur geeft daarbij geen gemeten intrekkingslatentie.

AWS noemt een gedistribueerde replay-cache, een hoogbeschikbare OCSP-responder, HSM-beveiligde ondertekeningssleutels, OCSP stapling en aparte certificaatautoriteiten per tenant als mogelijke uitbreidingen. Voor toegang tot AWS-diensten onderscheidt het bedrijf PKI voor agentidentiteit van IAM-rollen voor dienstautorisatie.

Vereisten en het doel van de voorbeeldcode

Het voorbeeld vraagt onder meer om Keycloak 26.2 of hoger, Python 3.9 of hoger en EJBCA Enterprise met REST API V1 en een OCSP-responder. Verder zijn AWS-toegang tot Amazon Bedrock, Amazon RDS for MySQL, Amazon SES en AWS Secrets Manager nodig. De RSA-sleutels in het voorbeeld zijn minstens 2048 bits groot.

De AWS Samples-repository omschrijft het project als demonstratie voor leren en ontwikkelen. De README vraagt om aanvullende beveiligingsmaatregelen en een beoordeling voordat het voor productie wordt gebruikt. De beschreven installatieroute start Keycloak en EJBCA lokaal met Docker en maakt AWS-resources aan.