I've been writing about why agentic AI needs a full identity ecosystem. Here's how I built mine — humans and agents, federated across platforms, governed by a single IDP — in an afternoon. For zero dollars.
I've spent the last several months arguing a position that some people find uncomfortable: securing agentic AI requires more than an IDP. It requires a full identity ecosystem. Open standards. Token exchange. Workload identity. Continuous enforcement. Not a single product. A pattern.
People nod along. They agree in principle. Then they ask: "But what does that actually look like?"
Fair question. So I built one.
One tenant. Humans and agents.
One IDP governing both.
Built in an afternoon. Zero cost.
This isn't a lab exercise. It's a working implementation. My agents authenticate through Microsoft Entra via SDK, exchange tokens with IBM Verify using RFC 8693, receive fine-grained authorization via RFC 9396 (RAR), and carry workload identity through SPIFFE/SPIRE. My human users access the same Microsoft 365 tenant — Teams, Outlook, SharePoint — but sign in through IBM Verify. Verify handles the MFA, the push notifications, the passkeys, the access policies. Entra trusts the federated assertion and grants the session.
Same tenant. Same trust fabric. Two populations. One governance layer.
And the whole thing started with a benefit most enterprise employees don't even know they have.
If your employer gives you a Visual Studio Professional or Enterprise subscription — and many large enterprises do — you qualify for a free Microsoft 365 E5 developer tenant. Not a trial. Not a sandbox that expires in 14 days. A real tenant with 25 user licenses, Entra ID P2, and the full M365 stack. And it auto-renews for the lifetime of your Visual Studio subscription.
Most people don't know this exists. They think getting an Entra ID environment requires a corporate IT request, an Azure subscription, or money. It doesn't.
my.visualstudio.com/benefits and sign in with the account that has your VS subscription. Find the Microsoft 365 Developer subscription (E5) tile. Click Activate.yourname.onmicrosoft.com), and password. Provide a mobile number for MFA. Your tenant is created in seconds.Why This Matters
Since January 2024, Microsoft has restricted free developer sandbox access. Active Visual Studio Professional and Enterprise subscribers still qualify. If your employer provides a VS subscription, you have this benefit right now — you just haven't activated it.
The default tenant gives you a .onmicrosoft.com domain. That's fine for throwaway testing. It's not fine for building a credible identity lab. If you want your Entra tenant to issue tokens under your own domain, register OIDC apps with real-looking issuer URIs, and federate with external IDPs using professional endpoints — you need your own domain.
Adding it takes about five minutes.
MS=ms12345678). Add it to your domain's DNS at your registrar. This proves you own the domain.Now your users are admin@yourdomain.com, not admin@randomthing.onmicrosoft.com. Your app registrations carry your domain in their identifiers. When you federate with IBM Verify, the trust relationship looks production-grade — because it is.
The M365 E5 developer subscription isn't a stripped-down sandbox. For identity architects, it's a fully functional environment with every feature that matters.
| Capability | Why it matters for identity |
|---|---|
| Entra ID P2 | Conditional Access, PIM, Identity Protection, risk-based authentication, dynamic groups. The full enterprise IDP stack. |
| 25 E5 User Licenses | Enough to simulate a real organization — users, groups, roles, assignments. |
| OIDC / SAML App Registrations | Register applications, configure federation, test SSO flows with external IDPs. |
| SCIM Endpoints | Test automated provisioning and deprovisioning workflows. Build toward agentic agent registries. |
| Microsoft Graph API | Full programmatic access to users, groups, applications, policies, and audit logs. |
| Exchange / Outlook / Teams | Real workloads that consume identity — federate them, protect them, observe how tokens flow. |
| Intune | Device trust, compliance policies, MDM. Test device-bound Conditional Access. |
The Identity Architect's Sandbox
This isn't just "an Entra ID tenant." It's a fully provisioned enterprise environment where you can test federation, build Conditional Access policies, configure SCIM provisioning, register OIDC apps, and observe how tokens move through Microsoft's stack — all without touching your production environment.
Here's where it gets interesting. You have a fully functional M365 tenant with Entra ID. Your users can sign in to Teams, Outlook, and SharePoint using Microsoft's native authentication. But you don't have to keep it that way.
You can federate your Entra ID tenant with IBM Verify as the external identity provider. When you do, every M365 login — Teams, Outlook, SharePoint, the admin centers — flows through IBM Verify. Verify handles the authentication decision. Verify presents the MFA challenge. Verify pushes the notification to your phone. Verify validates the passkey.
Entra receives a federated SAML assertion from Verify, trusts it, and grants the session. Microsoft's entire productivity platform, running behind IBM's identity governance.
Microsoft's platform.
IBM's identity governance.
That's federation done right.
What this gives you is control. Verify's access policies decide who gets in, how they authenticate, and under what conditions. You can enforce adaptive MFA, push notification approval, passkey-based passwordless authentication, location-based policies, and device posture checks — all before the user ever touches Microsoft's stack.
Why This Matters for Agentic AI
Federating your tenant with IBM Verify isn't just about human users. It establishes IBM Verify as the identity authority for the entire tenant. When you later add agents that authenticate through the same tenant, Verify is already the governance layer. Humans and agents, one IDP, one set of policies.
Now the real work begins. You have a federated M365 tenant. IBM Verify governs human access. The next step is to bring agents into the same trust fabric.
My agents authenticate to the Entra tenant using the Microsoft Identity SDK. They're registered as Entra applications with service principals. They get an Entra-issued token that proves they exist as a first-class identity in the tenant.
But that Entra token is just the starting point.
The agent presents its Entra-issued token to IBM Verify and performs a token exchange. This is RFC 8693 — the standard mechanism for exchanging a token issued by one authority for a token issued by another. The agent trades its Entra identity proof for a scoped IBM Verify token. No secrets are shared. No credentials cross trust boundaries. The token itself carries the identity across.
This is cross-platform identity federation at the agent layer. The agent was born in Entra. It now operates under Verify's governance.
The agent doesn't just request a generic scope like read or write. It uses RAR to specify structured authorization details — exactly what resource it needs, what action it intends to perform, and under what context. The authorization server can make a real policy decision based on the full intent, not just a coarse-grained scope string.
At the infrastructure layer, the agent carries a SPIFFE Verifiable Identity Document (SVID) issued by SPIRE. This cryptographically proves the workload is what it claims to be — independent of the application-layer OIDC tokens. Node attestation, workload attestation, automatic rotation. The identity is bound to the runtime, not to a config file.
The result: the agent has a verifiable identity at every layer. Entra knows it exists. Verify governs what it can do. RAR scopes the specific request. SPIFFE proves the workload is legitimate. Every hop is auditable.
If you've read the earlier posts in this series, you know the pattern: Discovery → Policy Binding → Token Scoping → Continuous Enforcement. Here's what each step looks like in this lab, with real components, not abstractions.
Every step uses an open standard. Every component is swappable. That's the point — the pattern is what matters, not the vendor. But IBM Verify happens to be the IDP that supports all four steps today, across both human and agent identity, in a single platform.
This blog post isn't a product pitch. If it were, I'd have put the buy button above the fold. It's a proof point.
The identity industry has spent the last year talking about agentic AI security in abstractions. Frameworks. Whitepapers. Slide decks with boxes and arrows. I wanted to show what it actually looks like when you stop talking and start building.
Here's what I showed you:
A free Microsoft 365 E5 developer tenant, provisioned in five minutes through a Visual Studio subscription most enterprise employees already have. A custom domain added via DNS verification. IBM Verify federated as the identity provider, replacing Microsoft's native authentication for all human M365 access. An agent authenticating through the same tenant via SDK, exchanging its Entra token for a Verify token using RFC 8693, scoping its authorization with RFC 9396 RAR, and carrying workload identity through SPIFFE/SPIRE.
One tenant. Two populations. One IDP. One set of policies. Every interaction governed by open standards.
The Open Standards Stack
Every protocol used in this lab is an open standard: OIDC, SAML, SCIM, RFC 8693 (Token Exchange), RFC 9396 (RAR), SPIFFE/SPIRE, CAEP/SSF. You could swap IBM Verify for any OIDC-compliant IDP that supports these standards. You could swap Entra for any SAML/OIDC-consuming service provider. The ecosystem pattern is the point — not the vendor.
But here's the truth most people won't say out loud: most IDPs don't support all of this. They support some of it. They're building toward the rest. IBM Verify supports it now. And you can prove it yourself, in an afternoon, for free.
Stop talking about
agentic AI security.
Build it.