<\/p>\n\n\n\n
In Part 1<\/a> of this series, we explored why Agentic AI breaks the identity model we spent the last decade building: agents have no native identity, delegation chains collapse, and static credentials don’t fit dynamic behaviour. The promise was that in Part 2 we will stop talking and start building.<\/p>\n\n\n\n So this is the practical half. We took the theory from Part 1, RFC 8693 token exchange, a Security Token Service, Workload Identity Federation, SPIFFE and turned it into a working demo. Then I built it twice<\/em>, on purpose, because the question I kept coming back to wasn’t “can we make it work?” It was “how few secrets can we get away with storing?”<\/p>\n\n\n\n Let’s start and explain what I mean, and then walk through the two versions.<\/p>\n\n\n\n I kept the same story from Part 1. A citizen, let’s call him Adam, submits a housing benefit claim through a government portal. Three AI agents process it end to end, and no human caseworker reviews the decision<\/strong>:<\/p>\n\n\n\n When no human sits in the loop, identity and accountability can’t be a comment in a log file. They have to be cryptographic and complete at every hop. The demo tries to prove two things at once, and it’s worth separating them clearly, because they’re easy to mush together:<\/p>\n\n\n\n Layer 1 – Workload Identity.<\/strong> “Is this workload even allowed to talk to the model provider?” This is the workload authenticating itself to Anthropic, and it’s where the two versions differ<\/span><\/strong>.<\/p>\n\n\n\n Layer 2 – Delegation Identity.<\/strong> “Which agent delegated to which, and on whose behalf?” This is the RFC 8693 That split is worth holding on to. It’s the reason I built two versions: Layer 2 never changes, and Layer 1 is where the question lives.<\/p>\n\n\n\n In Part 1 we stated that “long-lived, broad credentials are a security disaster waiting to happen” and that workload identity (SPIFFE\/SPIRE) is “the cryptographic root everything else is built on.” That’s easy to write in a blog post. It’s harder to feel until you watch a credential actually disappear.<\/p>\n\n\n\n So I built a deliberate progression (with the help of claude code). Think of it as peeling away secrets one layer at a time:<\/p>\n\n\n\n The point I’d ask you to keep in mind: the Anthropic-side token exchange and the agent-to-agent delegation are the same<\/strong> in both versions. The only thing that changes is the source of the workload’s very first identity.<\/p>\n\n\n\n Both versions lean on a capability that made this demo possible in the first place: Workload Identity Federation (WIF)<\/strong> on the Anthropic platform.<\/p>\n\n\n\n The fragile way we’d normally authenticate to a model API: generate a long-lived API key ( The mechanism on the wire is RFC 7523<\/strong>, the JWT-bearer grant: This is the hinge of the whole demo. Once you have a way to exchange any trusted JWT for an Anthropic token, the only question left is: where does that first JWT come from, and how much of a secret do you have to keep to get it?<\/strong> v1 and v2 are two answers to exactly that question.<\/p>\n\n\n\n In v1 the trusted JWT comes from Idira<\/strong>, an Idira tenant acting as the Oauth provider. The workload runs an OAuth client credentials<\/strong> grant: a machine-to-machine flow. It sends its The passport analogy holds up well here. Idira<\/strong> is the passport office. The JWT is a passport with an expiry date, issued to the workload only after it proves itself with credentials. The workload then presents that passport to Anthropic (RFC 7523), and Anthropic issues the short-lived token everything else runs on.<\/p>\n\n\n\n The full chain looks like this:<\/p>\n\n\n\n The heart of v1 is one small module that does two steps. Step one runs the client credentials grant against Idira and gets back the JWT ( What v1 wins:<\/strong> there is no static What v1 still carries:<\/strong> the client secret. It lives in a If you’ve ever chased the v2 asks the obvious follow-up: what if the workload didn’t have to know<\/em> anything to prove who it is? What if its identity came from what it is<\/em>?<\/p>\n\n\n\n That’s what SPIFFE<\/strong> gives us. SPIFFE (Secure Production Identity Framework For Everyone) is an open standard for giving workloads unique and verifiable identities. A SPIFFE ID looks like a URL:<\/p>\n\n\n\n Package that identity as a signed JWT and you get a JWT-SVID<\/strong>, which is exactly the kind of token Anthropic’s WIF already knows how to consume. Same RFC 7523 exchange, different source.<\/p>\n\n\n\n SPIRE<\/strong> is the reference implementation. It has two parts, and the analogy from before extends cleanly:<\/p>\n\n\n\n The key word is attestation<\/strong>, and it’s the thing that replaces the secret. How does the agent know the process asking for an identity really is The chain in v2:<\/p>\n\n\n\n One implementation detail caught me out, so it’s worth flagging. v1’s Idira tenant is on the public internet, so Anthropic can auto-discover its keys via OIDC discovery. The SPIRE Server in v2 runs locally and isn’t reachable from the internet, so Anthropic can’t go fetch its keys. The fix is to register the issuer with an inline JWKS<\/strong>: you export the SPIRE Server’s public keys and paste them directly into the Anthropic Console. Verification still works the same way, you just hand over the keys manually instead of pointing at a discovery URL.<\/p>\n\n\n\n The code reflects how little actually changes between the two. v2’s auth module tries SPIFFE first, and if the SPIRE socket isn’t present, it falls back to the v1 OAuth path.<\/p>\n\n\n\n Both demos run in two phases. Phase 0 is the workload identity dance, the workload gets its JWT (from Idira in v1, from SPIRE in v2) and exchanges it for the Anthropic token. Phase 1 is the claim processing, where the three agents resolve Adam’s claim and each hop grows the In v1, Phase 0 prints the Idira JWT arriving with its In v2, the same step instead shows a SPIFFE JWT-SVID with Everything after that, the orchestration \u2192 verification \u2192 approval flow and the final audit trail, is indistinguishable between the two. That’s the proof we were after: swap the root of identity, and the rest of the system doesn’t even notice.<\/p>\n\n\n\n The audit trail at the end reads like the chain of authorization letters from Part 1: I’ve deliberately kept this post at the level of the ideas<\/em>, what each version proves and why the secret keeps shrinking, rather than turning it into a setup manual. The full step-by-step configuration for both versions lives in the README files in the GitHub repositories<\/strong>: how to set up the Idira tenant and OAuth2 client for v1, how to bootstrap the SPIRE Server and Agent for v2, how to register the federation issuer and rule in the Anthropic Console, and how to run each demo end to end.<\/p>\n\n\n\n If Part 1 was the “why,” this was the “how,” twice over, so the cost of each secret you remove is visible. We’d suggest starting where Part 1 pointed: inventory your agents, establish workload identity, route every agent-to-agent call through an STS, and build provenance into your logs. v1 is a reasonable first step if you already live in an OAuth world. v2 is where it’s worth ending up, because But let’s be precise about what Part 2 actually solved: one problem<\/strong>, how to issue a unique, verifiable identity to an agent using current standards. That’s it. We didn’t touch access control. We didn’t touch permissions. We didn’t ask what that agent is actually allowed to do once it has a valid token.<\/p>\n\n\n\n That’s the next frontier: Just-In-Time access and Zero Standing Privilege for agentic workloads<\/strong>. What does it mean to grant an agent the minimum privilege it needs, only for the duration of a specific task, with no persistent entitlements sitting around waiting to be abused? <\/p>\n\n\n\n That’s probably Part 3 \ud83d\ude09<\/p>\n\n\n\n Both demos are open, and the READMEs walk through the full setup for each.<\/p>\n\n\n\n Thanks for reading both parts.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" In Part 1 of this series, we explored why Agentic AI breaks the identity model we spent the last decade building: agents have no native identity, delegation chains collapse, and static credentials don’t fit dynamic behaviour. The promise was that in Part 2 we will stop talking and start building. So this is the practical […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-container-style":"default","site-container-layout":"default","site-sidebar-layout":"default","disable-article-header":"default","disable-site-header":"default","disable-site-footer":"default","disable-content-area-spacing":"default","footnotes":""},"categories":[17],"tags":[20,21,18,23,22,19],"class_list":["post-309","post","type-post","status-publish","format-standard","hentry","category-identity-security","tag-agenticai","tag-cybersecurity","tag-iam","tag-identiysecurity","tag-techstrategy","tag-zerotrust"],"_links":{"self":[{"href":"https:\/\/sme-access.com\/index.php?rest_route=\/wp\/v2\/posts\/309","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sme-access.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sme-access.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sme-access.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sme-access.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=309"}],"version-history":[{"count":5,"href":"https:\/\/sme-access.com\/index.php?rest_route=\/wp\/v2\/posts\/309\/revisions"}],"predecessor-version":[{"id":332,"href":"https:\/\/sme-access.com\/index.php?rest_route=\/wp\/v2\/posts\/309\/revisions\/332"}],"wp:attachment":[{"href":"https:\/\/sme-access.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=309"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sme-access.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=309"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sme-access.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=309"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The same scenario, made real<\/h2>\n\n\n\n
\n
act<\/code> chain from Part 1, citizen \u2192 orchestration \u2192 verification \u2192 approval, nested inside every token. This part is identical<\/em> in both versions, because the delegation story is independent of how the workload proved itself.<\/p>\n\n\n\nWhy two versions?<\/h2>\n\n\n\n
\n
sk-ant-...<\/code> API key. But it still holds one secret: an OAuth client secret<\/span>.<\/li>\n\n\n\nA quick word on Anthropic Workload Identity Federation<\/h2>\n\n\n\n
sk-ant-...<\/code>), paste it into an environment variable, and hope it never leaks. That key is a bearer secret. It doesn’t expire on its own. It’s exactly the kind of standing credential <\/strong>Part 1 warned about.<\/p>\n\n\n\nWIF<\/code><\/mark> flips this around. Instead of storing a permanent key, your workload shows up holding an external JWT<\/strong> issued by an identity provider (like Idira) you’ve registered as trusted. Anthropic then does three things:<\/p>\n\n\n\n\n
sk-ant-oat01-...<\/code>) that expires in 10 min (or less, depending on your configuration).<\/li>\n<\/ol>\n\n\n\ngrant_type = urn:ietf:params:oauth:grant-type:jwt-bearer<\/code>, with your external JWT dropped into the assertion<\/code> field. You trade a JWT you already hold for a fresh, short-lived token scoped to your service account.<\/p>\n\n\n\nv1 – OAuth2 federation: no API key but it keeps one secret !<\/h2>\n\n\n\n
client_id<\/code> and client_secret<\/code> over HTTP Basic auth, and Idira<\/strong> returns a signed JWT.<\/p>\n\n\n\nIdira\n \u2502 client credentials grant (client_id + client_secret)\n \u25bc\nOAuth JWT sub: <client-id> iss: https:\/\/tenantID.id.cyberark.cloud\n \u2502 presented to Anthropic (RFC 7523 jwt-bearer)\n \u25bc\nAnthropic WIF token (sk-ant-oat01-..., 10 min \/ 600 sec)\n \u2502 authenticates every Agent call\n \u25bc\nOrchestration \u2500\u2500[STS, RFC 8693]\u2500\u2500> Verification \u2500\u2500[STS, RFC 8693]\u2500\u2500<\/mark>> Approval\n \u2502\n \u25bc\nAudit trail: Idira --> Workload --> Citizen --> Agent --> Agent (all cryptographic)<\/mark><\/code><\/pre>\n\n\n\nid_token<\/code>). Step two performs the RFC 7523 exchange against Anthropic and gets back the sk-ant-oat01-...<\/code> token. From there, the three agents make their Claude calls with a Bearer token<\/strong>, not an x-api-key<\/code> header, and every agent-to-agent hop runs through the STS to grow the act<\/code> chain.<\/p>\n\n\n\nsk-ant-...<\/code> API key anywhere. The workload’s Anthropic credential is minted on demand and dies in an 10 minutes. If it leaks, it’s near-worthless within 10 minutes. Idira act as an OAuth server, so we can control and audit the usage of the client id and client secret.<\/p>\n\n\n\n.env<\/code> file. You have to store it, protect it, and rotate it. In production it belongs in a secrets manager (like Idira Secret Manager – conjur for the very old \ud83d\ude42), but it’s still a thing you know<\/em>, which means it’s still a thing that can leak. We traded a permanent API key for a permanent client secret. That’s progress, but it isn’t the finish line.<\/p>\n\n\n\nsecret zero<\/code> problem, the credential you need to bootstrap all your other credentials, you can probably already see where this is heading.<\/p>\n\n\n\nv2 – SPIFFE: remove the last secret<\/h2>\n\n\n\n
spiffe:\/\/sme-access.com\/workload\/benefit-processing\n \u2514\u2500 trust domain \u2518 \u2514\u2500\u2500\u2500\u2500 workload path \u2500\u2500\u2500\u2500\u2518<\/mark><\/code><\/pre>\n\n\n\nNote: the demo uses JWT-SVID. X.509-SVID exists and serves a different set of use cases.<\/mark><\/code><\/pre>\n\n\n\n\n
benefit-processing<\/code> and not an impostor? In this demo we use the Docker workload attestor: the agent inspects the calling process, traces it to its container, reads the container’s label (app=benefit-processing<\/code>), and matches it against a registration entry. No secret is exchanged.<\/strong> The identity is proven by what the container is<\/em>. There’s no client ID, no client secret, no API key stored anywhere.<\/p>\n\n\n\nSPIRE Server (trust domain: sme-access.com)\n \u2502 signs (no secret held by the workload)\n \u25bc\nJWT-SVID sub: spiffe:\/\/sme-access.com\/workload\/benefit-processing\n \u2502 iss: https:\/\/spire.sme-access.com\n \u2502 presented to Anthropic (RFC 7523 jwt-bearer)\n \u25bc\nAnthropic WIF token (sk-ant-oat01-..., 10 min)\n \u2502 authenticates every Claude call\n \u25bc\nOrchestration \u2500\u2500[STS, RFC 8693]\u2500\u2500> Verification \u2500\u2500[STS, RFC 8693]\u2500\u2500> Approval\n \u2502\n \u25bc\nAudit trail: SPIRE --> Workload --> Citizen --> Agent --> Agent (all cryptographic)<\/mark><\/code><\/pre>\n\n\n\nWhat this looks like running<\/h2>\n\n\n\n
act<\/code> chain through the STS.<\/p>\n\n\n\nsub<\/code> and iss<\/code>, then the Anthropic Bearer token being minted.<\/p>\n\n\n\nsub: spiffe:\/\/sme-access.com\/workload\/benefit-processing<\/code>, fetched with no secret.<\/p>\n\n\n\ncitizen \u2192 orchestration \u2192 verification \u2192 approval<\/code>, every hop cryptographically recorded, no caseworker involved, and full provenance preserved.<\/p>\n\n\n\nRunning it yourself<\/h2>\n\n\n\n
Where to go from here<\/h2>\n\n\n\n
the only secret you can't leak is the one you never had<\/code>.<\/p>\n\n\n\nReference<\/h3>\n\n\n\n
\n