AI-agents beveiligen met SPIFFE en SPIRE: Workload Identity voor autonome agents

Waarom een opgeslagen secret het verkeerde fundament is voor een agent

Een autonome agent die een statische API-sleutel of OAuth client secret bevat, heeft hetzelfde probleem als elk service account, maar dan erger: de credential overleeft de noodzaak ervan, wordt gekopieerd naar images en configuratiebestanden, en iedereen — of elke via prompt-injection aangeroepen tool call — die het leest, kan de agent imiteren. Hoe meer agents en instanties, hoe meer exemplaren van long-lived secrets u moet bijhouden.

SPIFFE draait het model om. In plaats van een secret te presenteren om identiteit te bewijzen, wordt een workload geattesteerd door zijn omgeving en krijgt deze een verse, kortstondige credential gebonden aan een stabiele identiteit. Er is geen statisch token om te stelen, en elke draaiende instantie krijgt zijn eigen geattesteerde credential. Dit is dezelfde verschuiving van secrets naar identiteit die we beschrijven voor agents in het algemeen in wat AI-agentidentiteit is.

Hoe SPIFFE en SPIRE identiteit uitgeven

SPIRE geeft pas een SVID uit nadat twee attestatiecontroles zijn geslaagd:

• Node-attestatie bewijst welke machine de workload uitvoert — een Kubernetes projected service account token, een AWS instance identity document, of GCP instance metadata.
• Workload-attestatie bewijst welk proces de call maakt — selectors zoals het Kubernetes service account, de namespace, en de container image digest.

Alleen een workload die overeenkomt met een geregistreerde entry op een geattesteerde node ontvangt een SVID. De SVID komt in drie vormen, en de praktische vorm voor gateway-calls vandaag de dag is de JWT-SVID:

Het acme.com-gedeelte van de SPIFFE ID is het trust domain. Op Kubernetes vertrouwt SPIRE projected service account tokens en leest de agent zijn JWT-SVID uit de SPIFFE Workload API tijdens runtime — er wordt dus nooit een secret naar een configuratiebestand geschreven of in een image gebakken.

Hoe de gateway een SVID herleidt

Voor TrueFoundry is een JWT-SVID gewoon een ander identity-provider-token. De agent is geregistreerd als identity-provider-backed — dezelfde registratiestap die elke extern uitgegeven agent-identiteit gebruikt:

Elk verzoek bevat vervolgens twee tokens, precies zoals bij standaard agentidentiteit en delegation namens de gebruiker:

De gateway valideert de SVID tegen de JWKS van SPIRE, herleidt de SPIFFE ID naar de geregistreerde agent, controleert of die agent het doel mag bereiken en mag handelen voor de gebruiker, en stuur de call door met de eigen uitgaande authenticatie van het doel. De identiteit van de gebruiker reist de hele weg mee met die van de agent.

Aansluiten en configureren

Drie stappen verbinden SPIRE met de gateway:

1. Registreer SPIRE als een identity provider. Stel het OIDC-compliant discovery-eindpunt van SPIRE beschikbaar en voeg het toe onder Platform → Identity Providers met de issuer, audiences en JWKS URI.
2. Registreer de agent als identity-provider-backed, waarbij u de SPIFFE ID-claim koppelt aan de agent.
3. Presenteer de JWT-SVID bij elke call aan de gateway, zoals hierboven. De SPIRE-agent roteert deze voor het verstrijken van de geldigheid, zodat de agent nooit halverwege een taak te maken krijgt met verlopen credentials.

Toegang zelf wordt nog steeds beheerd door collaborator-grants — wie de agent mag aanroepen, voor wie deze mag handelen en welke MCP-servers deze mag bereiken — het model dat wordt behandeld in fijnmazige autorisatie en wat MCP-autorisatie is.

Waar teams de fout in gaan

De SVID behandelen als vervanging voor autorisatie. Attestatie bewijst wie de workload is; het bepaalt niet wat deze mag doen. U heeft nog steeds collaborator-grants en beleid nodig bij de gateway — identiteit en autorisatie zijn gescheiden lagen.

Te brede attestatie-selectors. Als workload-attestatie alleen kijkt naar een namespace, kan elke pod in die namespace dezelfde SVID verkrijgen. Koppel selectors vast aan het service account en de image digest, zodat de identiteit voor één specifieke workload staat.

De gebruiker vergeten. Een SVID identificeert de agent, niet de persoon voor wie deze handelt. Het token van de gebruiker moet nog steeds meereizen in Authorization, zodat het stroomafwaartse systeem kan verifiëren wiens gegevens zijn gebruikt.

Aannemen dat mTLS alleen governance is. X.509-SVID's beveiligen het transport, maar een beheerde call heeft nog steeds de gateway nodig om identiteit te herleiden, het paar te autoriseren en het verzoek te auditen.

Wilt u agentidentiteit zonder risico op lekkende secrets?

TrueFoundry Gateway

Een praktisch voorbeeld

Een platformteam draait agents op Kubernetes en weigert nog een long-lived token toe te voegen. Ze zetten SPIRE op, registreren een entry voor research-agent gekoppeld aan het service account en de image digest, en stellen het OIDC-eindpunt van SPIRE beschikbaar. In TrueFoundry voegen ze SPIRE toe als identity provider en registreren ze research-agent als identity-provider-backed, waarbij ze de SPIFFE ID koppelen. Tijdens runtime haalt elke pod een JWT-SVID op uit de Workload API en stuurt deze met het token van de gebruiker naar de gateway. De gateway valideert het token tegen de JWKS van SPIRE, herleidt het naar de geregistreerde agent en autoriseert de call. Wanneer een workload buiten gebruik wordt gesteld, de-registreren ze de entry en stoppen de SVID's simpelweg bij de volgende rotatie — geen secret om in te trekken, geen configuratie om op te schonen.

Aandachtspunten die het weten waard zijn

• JWT-SVID's zijn vandaag de dag de praktische keuze; WIT-SVID's voegen proof-of-possession toe, maar vereisen wijzigingen aan de client. Begin met JWT-SVID voor gateway-calls.
• Eerste-klas SPIFFE-binding op de agent-spec staat vermeld als binnenkort beschikbaar in de documentatie — vandaag de dag koppelt u via de identity-provider-mapping. Controleer de huidige documentatie voor een brede uitrol.
• Per-hop token exchange wordt momenteel uitgerold; controleer bij multi-agent ketens hoe delegatie is ingericht in uw versie.
• Het trust domain is een beveiligingsgrens. Houd één trust domain per omgeving aan en deel SPIRE-ondertekeningsmateriaal niet tussen omgevingen.
• Node-attestatie hangt af van het platform. Op managed Kubernetes zijn projected service account tokens het gebruikelijke bewijs; controleer of uw cluster deze beschikbaar stelt.

SPIFFE vergeleken met alternatieven

Om te zien waarom geattesteerde identiteit belangrijk is, vergelijkt u het met de twee opties waar teams het eerst naar grijpen. Het verschil is niet cosmetisch — het veranderd wie de agent kan imiteren en hoe snel u een gecompromitteerde agent kunt uitschakelen.

De statische sleutel en het gedeelde account delen hetzelfde probleem: de credential is een bearer-secret, dus bezit is identiteit. SPIFFE doorbreekt die vergelijking — het bezit van een SVID is waardeloos zonder de attestatie te doorstaan op een geattesteerde node, en de SVID verloopt uit zichzelf binnen enkele minuten. Er is geen duurzaam materiaal om te stelen.

De sandwich van overdraagbaar vertrouwen

De documentatie beschrijft het end-to-end model als een stack van vier lagen, die elk één probleem oplossen. Dit is waardevol om expliciet te maken, omdat het laat zien waar SPIFFE stopt en de gateway begint:

1. Workload identity (de SVID) uit runtime-attestatie — SPIRE bewijst de node en het proces, en geeft vervolgens een kortstondige credential uit die gebonden is aan een stabiele SPIFFE ID.
2. Herleiding naar de geregistreerde agent — de gateway valideert de SVID tegen de JWKS van SPIRE en koppelt de SPIFFE ID aan de agent in het register.
3. Delegatie per hop via token exchange — de gebruiker reist mee als sub, de handelende agent als act, en de scope wordt verkleind voor de volgende aangeroepene.
4. Een doel-eigen credential waar nodig — een token namens de gebruiker, of een door de gateway beheerde OAuth-credential, zodat de stroomafwaartse tool een indeling ontvangt die het al vertrouwt.

Het wordt overdraagbaar genoemd omdat de stabiele agentidentiteit wordt afgeleid van attestatie, niet van een cloudspecifiek secret — dus dezelfde identiteit blijft behouden, ongeacht of de workload vandaag op de ene cluster draait en morgen op een andere. Laag één is zuiver SPIFFE/SPIRE; laag twee tot en met vier is waar de TrueFoundry Gateway zijn werk doet.

Concreet op Kubernetes

Kubernetes is het meest voorkomende scenario, en dit is waar de claim "geen secret op schijf" werkelijkheid wordt. SPIRE vertrouwt de projected service account tokens van het cluster als bewijs voor node en workload, en de agent leest zijn JWT-SVID tijdens runtime uit de SPIFFE Workload API — een lokale socket. Er wordt niets naar een bestand geschreven, in een image gebakken of als omgevingsvariabele doorgegeven. Er is dus geen artifact dat bij een gelekt image of via een prompt-injected instructie zichtbaar kan worden gemaakt. Wanneer de SVID bijna verloopt, haalt de SPIRE-agent transparant een nieuwe op, zodat een langdurig draaiende agent nooit vastloopt op een verlopen credential. Koppel workload-attestatie-selectors vast aan het service account en de container image digest, niet alleen aan de namespace, zodat één SVID exact voor één workload staat in plaats van voor elke pod in de namespace.

Gerelateerde artikelen

• Wat is AI-agentidentiteit? — het concept dat SPIFFE concreet maakt
• Agentidentiteit en delegatie namens gebruikers — het twee-header model waar de SVID op aansluit
• AI Agent Governance — waar identiteit zich bevindt in de stack
• Wat is een MCP Gateway? — het beheren van de tool calls zelf
• Agent Gateway vs LLM Gateway — waarom het pad met meerdere hops een eigen controlepunt nodig heeft

Conclusie

Een opgeslagen secret is een risico dat groeit met elke agent en elke instantie. SPIFFE en SPIRE vervangen dit door een identiteit die voortkomt uit attestatie — kortstondig, automatisch geroteerd en onmogelijk te kopiëren uit een configuratiebestand. De TrueFoundry Gateway neemt de SVID die de agent tijdens runtime verkrijgt, herleidt deze naar een beheerde identiteit en autoriseert de call voor de gebruiker namens wie deze handelt.

Het resultaat is precies wat beveiligingsteams willen van autonome agents: een identiteit die u kunt attesteren, autoriseren, auditen en intrekken — zonder dat er één long-lived credential aan te pas komt.

Geef elke agent een geattesteerde identiteit en een heldere audit trail.

Boek een demo