Executive Summary

AI agents need identity and trust just like humans. In this article, we demonstrate a zero-trust approach to autonomous AI agents by integrating Identity and access management into an enterprise agentic workflow. Using a hotel booking scenario, we show how each AI agent has identity and issued access token for every action. This ensures no implicit trust between entities – every interaction is authenticated and authorized, following the principle of “never trust, always verify”[1]. The solution marries Asgardeo by WSO2(for identity and access management) with Microsoft’s Azure OpenAI service on Azure AI Foundry and Autogen (for powerful generative AI model and Multiagent orchestration). The result is a working example of autonomous agents that carry digital ID tokens, enabling end-to-end auditability and security in their workflow.

The contribution of this work is to empower anyone designing AI Agent-driven systems:

• For Solution Architects. Provides a reusable reference architecture for secure AI workflows, proving that identity and access management enables – not limits – innovative AI deployments.


• For Developers. Delivers a practical, open-source OAuth2 example beyond standard logins (username and password), empowering developers to build secure AI apps with tools like AutoGen and Semantic Kernel.


• For the AI/ML Community. Emphasizes the need for built-in identity and access management as AI agents grow more autonomous – ensuring actions are traceable, trustworthy, and governable.

Acknowledgement

This work was a collaborative effort between the Microsoft and WSO2 teams. We would like to specifically acknowledge the contributions of the WSO2 team – Nadheesh Jihan, Ayesha Dissanayaka, Nirhoshan Sivaroopan, Thilina Shashimal Senarath, and Pavindu Lakshan – who led the design and implementation of the solution. Their work included designing the overall solution architecture, developing the Hotel Assistant Agent, designing and implementing a secure tool extension for AutoGen, and building a Python authentication SDK based on OAuth. They also integrated key technologies such as AutoGen (Agent Framework), Azure OpenAI, and WSO2 Asgardeo as the identity provider to bring the scenario to life. Also, we would also like to acknowledge the contributions of Abdo Talema and Yogi Srivastava for their valuable guidance on identity and access concepts and direction on the development of SecureFunctionTool.

Introduction

Imagine a world where AI agents – not just human users – roam your systems, calling APIs, gathering data, and performing tasks autonomously. It sounds futuristic, but it’s quickly becoming reality.

Figure 1: Mult-Agent Workflow without Zero-Trust Agents

However, with great power comes great responsibility (and security concerns!). How do we trust these AI agents? This article addresses that question head-on by treating AI agents having full-fledged identities in a system, complete with authentication and access control. In other words, we make sure our AI agents must flash an “ID card” (Identity token) with scoped access token before they can do anything sensitive – just as a human user would in a zero-trust system.

Key highlights of the solution:

• Zero Trust Design – Introduces an extension to the agent framework that forces agents to authenticate and authorize via OAuth2 before accessing critical functions. This brings Zero Trust principles (continuous verification, least privilege) into Agentic AI systems [1].


• Collaborative Effort – Developed in close collaboration between WSO2 and Microsoft, combining WSO2 Asgardeo, with Microsoft’s Azure AI platform. (Credit to WSO2 for developing the code and providing WSO2 Asgardeo.)


• Azure OpenAI & Foundry – Leverages Azure OpenAI on Azure AI Foundry to power the agents’ intelligence with GPT-4 (ensuring enterprise-grade reliability and data security), and uses AutoGen to illustrate building zero-trust Agents [3].


• Alignment with Entra Agent ID – The approach anticipates Microsoft’s Entra Agent ID initiative, which similarly assigns unique Entra identities to AI agents for robust authentication and governance [2]. This open source solution is a practical step toward that vision of managing AI agents as first-class identities in a Zero Trust security posture.

In summary: Zero-Trust for AI agents is now not just theory but practice. In the following sections, we will double-click into how the code is structured, how the system works, and the key technologies (Azure OpenAI, Azure AI Foundry, Asgardeo – WSO2 Identity Server) that made it possible. We’ll also highlight the close WSO2-Microsoft collaboration. By the end, you’ll see a clear path for designing your own secure, auditable AI agent solutions.

Solution Architecture and Code Outline

Let’s start by outlining the architecture of the Hotel Booking AI-Agent System and its code components. The GitHub repository (WSO2’s iam-ai-samples repo)[5] provides a complete reference implementation called “hotel-booking-agent-autogen-with-securetool.” At a high level, the system is composed of WSO2’s Asgardeo (for identity and access management), AutoGen (multi-agents framework) and Microsoft’s Azure OpenAI service on Azure AI Foundry.

Here’s a breakdown of the key components and how they relate:

 

These building blocks are illustrated in the architecture diagram below:

Figure 2: Building Blocks of Hotel-Booking AI-Agent System

Now, how do these pieces work together in code? The sample workflow is shown below:

Figure 3: Sample Workflow of the Hotel-Booking AI-Agent System

The above is an illustrative sample flow based on the actual code outline in the GitHub repo [5].

Auditing and Logging: Because all critical function calls go through the identity server checks, we inherently get an audit trail. WSO2 Asgardeo can log token issuance and validation events. Moreover, the system could log every tool invocation along with which agent invoked it and whether it was authorized. This means if later someone asks, “who booked this hotel?”, we can trace it to an agent acting on behalf of a user, with a validated credential, at a specific time – achieving accountability in an autonomous system.

In summary, the code structure combines standard multi-agent orchestration logic (thanks to the AutoGen framework) with additional security glue code (the SecureFunctionTool and OAuth2 interactions). The novel extension (SecureFunctionTool) is relatively small in code but high impact in design: it forces the AI agents to play by the rules of a secure distributed system.

Zero-Trust in Action: OAuth2 Identity via WSO2 Asgardeo

This section zooms in on the Zero-Trust aspect of the solution – the heart of the project. “Zero Trust” essentially means never trust, always verify. In practice, this breaks down into principles: no implicit trust for any entity, continuous authentication/authorization for each action, least privilege access, and thorough auditing[1]. We applied these principles to our multi-agent system using OAuth2 identity tokens and WSO2’s Asgardeo as the authorization server.

Here’s how the Zero-Trust agent workflow operates:

• No Implicit Trust Between AI Agents: Just because our User Agent and Booking Agent are part of one application doesn’t mean they trust each other. The Booking Agent doesn’t blindly execute a booking order from User Agent. Instead, it treats the request as coming from an external source that needs to be verified. Our SecureFunctionTool enforces this by requiring a valid token for the book_hotel action. In essence, each agent-to-agent interaction is treated like a service-to-service API call in a microservice architecture – it must carry credentials.


• Authentication & Authorization via OAuth2: We leverage OAuth2 standard – a battle-tested standard for authorization – to authorize AI agents. For example, when the Booking Agent is about to perform the booking, it must present an access token (JSON Web Token) issued by Asgardeo. This token has scopes/permissions for the agent’s Identity. Asgardeo, configured with the appropriate OAuth2 client (application) for the hotel booking AI agent, issues the jwt token if the agent (or the user on whose behalf it acts) is legitimate. The token might be issued using the Client Credentials OAuth2 grant flow (agent authenticating as itself) or OAuth2 Authorization Code Grant flow (when acting on behalf of a user). In our prototype, we imagined a simple approach where the agent uses a client credential to get a token with the scope hotel-book. This token is a JWT containing claims like issuer (iss:Asgardeo), audience (aud:Hotel Booking API) expiry time(exp), and allowed scope (s).


• SecureFunctionTool Validation: When the token is presented back to SecureFunctionTool, it performs continuous verification. How? There are a couple of ways:

1. Local JWT Validation: WSO2 Asgardeo publishes a JWKS endpoint (JSON Web Key Set) containing its public signing keys. SecureFunctionTool can use this to verify the JWT signature and then check claims (e.g., is the token unexpired? Does it have the required scope for this function?). This is a fast, offline check.


2. Introspection Endpoint: Alternatively, the tool could call Asgardeo’s token introspection endpoint, sending the token and receiving a response about its validity and scopes. This is an online check and could enforce that the token hasn’t been revoked.

Either way, if the token is not valid or missing, the function call is denied. The AI agent could then either log an error or attempt to re-authenticate. This continuous enforcement means even if an AI agent was issued JWT token earlier, it was just-in time access to perform previous operation by setting shorter expiration time, hence ensuring that new token is requested every time a protected function is invoked else the call will fail until a new valid token is obtained.

Asgardeo – Authorization Server Role: Asgardeo was instrumental, as it provided a ready-made OAuth2 implementation with all the enterprise features (token management, auditing, scope management). We effectively treated Asgardeo as the “identity provider for AI agents (authorization server).” Notably, Asgardeo by WSO2 has been evolving to tackle modern challenges, including what they call “agentic AI security.” In fact, WSO2 positions its IAM suite as AI-powered and ready for the AI Agent era, highlighting features like access control for AI agents in recent releases[4]. It’s great to see a traditionally user-focused IAM product adapting to secure non-human actors (AI/ML agents) as well – exactly what we needed.

This zero-trust setup ensures our autonomous agents are auditable and accountable. We no longer have to worry, “What if the AI goes off and does X without permission?” Because in our design, the AI literally cannot do X without permission – the identity system won’t let it. This brings peace of mind for deploying such agents in sensitive workflows.

To put it humorously, we taught our AI agents that “you don’t talk to strangers (or call strange APIs) without showing your ID.” Every time they want to do something important, our agents must essentially say, “Hi, I’m Agent 007, here’s my token, license to book hotels.” Only then do they get to execute their mission. This lighthearted analogy aside, the ability to enforce and verify identity at each step is a serious leap forward for making AI solutions enterprise-ready.

Leveraging Azure OpenAI and Azure AI Foundry

While the security and identity parts are crucial, let’s not forget the AI smarts that make the agents useful. Our project uses Azure OpenAI Service and the broader Azure AI Foundry to supply the large language model intelligence behind the AI agents.

Azure OpenAI Service (GPT-4) as the Brain: Both the User Agent and Hotel Booking Agent are powered by GPT-4 models provided through Azure OpenAI. We chose Azure’s hosted version of OpenAI for a few reasons:

• Enterprise Compliance: Azure OpenAI offers the same capabilities as OpenAI’s GPT-4, but with added enterprise assurances (data encryption at rest/in transit, data not used for training the base model, regional isolation, etc.). For an enterprise scenario like booking with possibly sensitive user details, this is important.


• Performance and Reliability: Azure OpenAI comes with the scalability of Azure’s infrastructure. If our agents needed to scale to handle many requests, Azure can handle scaling out the inference endpoints.

The combination of Asgardeo by WSO2 , AutoGen and Azure AI Foundry for AI capabilities shows that we can implement secure agents using open-source multi-agent framework and integrate with cloud Identity as well as AI services effectively. It’s a best-of-both-worlds scenario: use the tools you need from wherever, while adhering to open standards. And importantly, this means Solution Architects and Developers can replicate this in their own environments – if you have a different identity provider (say, Entra ID or Okta), you could use that instead of WSO2; if you prefer a different AI service, you could swap that in. The patterns remain the same.

Alignment with Microsoft Entra Agent ID and Future Outlook

The blog demonstrates a standards-based pattern – an AutoGen agent retrieves a JWT from Asgardeo – WSO2 Identity Server (OAuth2 2.0 client-credentials flow) and presents it to a SecureFunctionTool, which validates signature, issuer, audience, expiry and a single scope. This shows that an agent can be treated as a first-class identity and that Zero-Trust checks can be enforced at every function call.

Microsoft Entra Agent ID, announced at Build 2025 [6], bakes the same pattern directly into Entra ID: every agent created with Copilot Studio or Azure AI Foundry is automatically issued its own identity object in the tenant directory, allowing Conditional Access, least-privilege role assignment and full audit/audit logging out-of-the-box.
In our sample, we have not yet mint one identity per agent or wire up Conditional Access; nevertheless, because it relies solely on OIDC/JWT primitives, swapping the token issuer from WSO2 IS to Entra ID would only require new client credentials and issuer metadata. In short, the repository is conceptually aligned with Entra Agent ID while remaining implementation-agnostic.

Key Takeaway of Alignment – standards today, seamless interoperability tomorrow

The sample secures its AutoGen workflow with nothing beyond OAuth2 client-credentials and vanilla OIDC JWT checks. SecureFunctionTool ensures agent obtains a valid token that satisfy the required scopes for invoking business resources, while encapsulating sensitive information such as application credentials and tokens preventing unintentional exposure to LLM adhering to open standards.    That choice lines up perfectly with other Agentic Identity Services, such as Microsoft’s Entra Agent ID, which is built on the same primitives.

Because both Asgardeo and Entra Agent ID issue standards-compliant OAuth2 tokens, you can establish cross-trust in either direction – for example, add Entra Agent ID as an external  identity provider in Asgardeo, or register Asgardeo in Entra. After you update the validator to recognise both issuers (and map scope/scp and roles claims), tokens minted by either platform will clear the same JWT checks, letting WSO2-managed AutoGen agents and Azure AI Foundry agents collaborate inside a single Zero-Trust fabric while each IdP still applies its own Conditional-Access policies.

In short, adopting OAuth identity today is not a detour; it is the fast lane to a federated future where Asgardeo and Entra Agent ID jointly manage your “virtual employees” at enterprise scale.

Conclusion

The Zero-Trust Agents project illustrates a pivotal concept: as AI agents become more autonomous and capable, identity and security must be first-class citizens in their design. We can no longer afford to have free-roaming, opaque AI processes in our systems. By adding OAuth2-standard identity to each agent, we ensure that even in a fully automated multi-agent workflow, every action is accountable and authorized.

Future Directions:

Looking ahead, there are several avenues this work can evolve:

• Entra Agent ID Integration. Enabling multi-system integration by federating Asgardeo to Microsoft EntraID for invoking resources secured by Entra ID.


• Enhanced Security Monitoring. Strengthen security incident handling by using ML-based security anomaly detection via Azure Sentinel or Defender to monitor and flag unusual AI-Agent behaviour across systems.


• Open-Source Contribution. Open-source the SecureFunctionTool as an AutoGen plugin to promote reusable security best practices within the developer community.

Final Thoughts: We’re entering a new era where AI agents might become as common as human coworkers in certain tasks. Ensuring zero-trust and auditable operations for these agents is not just an option, it’s a necessity. The collaboration with WSO2 on “Zero-Trust Agents” has shown one way to achieve this. By giving our AI agents an identity and enforcing “need-to-know” and “need-to-act” principles, we can unlock their potential safely.

In a sense, we taught our autonomous agents some manners – they now politely ask for permission before acting, and they carry a token that says, “I’m allowed to do this.” With that in place, we can let them innovate and work for us, without losing oversight. This brings us closer to a future of AI that is empowered, yet secure and governable.

Thank you for reading! Now, go forth and give your AI agents their ID cards – the era of Zero-Trust Agentic AI has arrived. 🚀

References

[1] “Never Trust, Always Verify”. Federal Migration to ZTA and Endpoint Security

[2] Microsoft extends Zero Trust to secure the agentic workforce

[3] Using Azure AI Agent Service with AutoGen / Semantic Kernel to build a …

[4] Modernize Your User Access, Future-Proof Your Business

[5] Hotel Booking Sample

[6] Announcing Microsoft Entra Agent ID: Secure and manage your AI agents