Secure Backend Agents with Access Intelligence
At Curity, we recently collaborated with the Azure Developer CLI (azd) team to produce an azd template hosted on the awesome-azd gallery. The repository’s goal is to demonstrate how enterprises should use authorization to implement AI initiatives safely.
The GitHub repository may initially seem a little complex, with deployment resources for both security and AI, as well as code examples that combine AI with token-based security. In this article, I provide some insights behind the implementation.
Enterprise Use Cases
The Microsoft Foundry provides a next generation enterprise-grade platform for AI. A common initial use case is for customers to operate their own resources using natural language commands. To get different results, customers simply issue a new command.
In such initiatives, authorization is a key requirement. Although customers can operate productively on their own data, mistakes by AI technology must never result in the customer gaining access to unauthorized data, like that of another user.
Developer Experience
From a development viewpoint, the Microsoft AI ecosystem provides productive tools for developers. Developers can use SDKs that enable external applications to integrate with Azure backend environments. The azd template uses C# code to demonstrate the following protocols, and the template could be adapted for other programming languages:
An external application uses the A2A protocol and the Microsoft A2A SDK to send a natural language command to a backend agent.
The backend agent uses the MCP protocol and the Microsoft MCP SDK to communicate with an MCP server.
Developers only need to write APIs and API clients, which they have been doing in their preferred language for years. Azure AI Foundry deals with the complexity of natural language processing (NLP). The authorization requirement should be met with the same experience.
AI Deployments
Azd templates include deployments, to spin up the backend infrastructure. The bigger picture that enterprises should consider is how such deployments will scale. You need a future plan to deploy multiple AI components, serve multiple clients and work with external organizations.
At the organizational level it is no different to how you already deploy APIs and applications. Typically, you externalize the management of these components from developers, and a platform engineering or DevOps team owns deployment and operational best practices.
The example azd template demonstrates uses layered provisioning to enable a clean separation between base infrastructure and the components developers deploy. It also uses an internal network, to enable the use of internal URLs and limit endpoints exposed to the internet.
Securing AI
The main enterprise concern with AI technology is that it can make mistakes, such as when processing complex text input from users. Malicious users may attempt to use tools that send dangerous commands, to cause backend API requests to try to access unauthorized data.
To mitigate authorization risks, APIs should use short-lived least-privilege OAuth 2.0 access tokens to authorize access to data. Agents should never be given permanent access to APIs, with mechanisms like API keys. When using short-lived access tokens, agents only gain short-lived access. Authentication and authorization must take place for internal endpoints as well as those exposed to the internet.
The azd template combines the use of Microsoft AI SDKs with OAuth security, to secure A2A and MCP endpoints. The example Portfolio MCP Server authorizes access to fictional stocks data and uses access token attributes like those shown here.
{
"exp": 1771434954,
"nbf": 1771434054,
"scope": "stocks/read",
"iss": "https://login.demo.example/oauth/v2/oauth-anonymous",
"sub": "62c839b8214aa1fe8cbcd823948a4bc705fbbba69c7666e334ee5c7fb348b60a",
"aud": "https://mcp.demo.example",
"iat": 1771434054,
"purpose": "access_token",
"customer_id": "132",
"region": "USA",
"client_id": "console-client",
"client_type": "agent",
"agent_id": "autonomous-agent"
}
If you inspect the code, you will see that developers continue to get a straightforward experience. The Portfolio MCP Server, and any upstream APIs, can easily use the highlighted token attributes to implement authorization.
The access token is integrity protected so that no malicious party, such as an untrusted AI agent, can alter the token values. In this example, the agent can only gain read-only access to stocks and only for the customer and region in the access token. APIs reject any incorrect or malicious access by AI components.
Designing AI Security
Typically, the only work for development teams should be to use access tokens that an identity person designs. An identity person or team should design access tokens for each component. Development teams then receive easy-to-use, short-lived, least-privilege access tokens that enable the correct authorization.
Access Intelligence
Once you have a token-based setup, the details of tokens, and flows to get them, are important, to enable real-world AI use cases. For a first milestone, ensure that you can issue access tokens with any runtime attributes that your APIs need. For future milestones, plan to issue access tokens to secure real-world AI flows like those summarized here:
A user expresses an intent to an agent, such as conditions for a purchase. When those conditions are met, the agent triggers human approval. The agent then gets a high privilege access token and can complete its task.
Agents can collaborate across organizations. Your agent may need to call an agent from another organization, and pass on any security context. For that, it is likely to need advanced token exchange capabilities.
Using access intelligence to meet end-to-end requirements like these is the goal of the OAuth 2.0 authorization framework. The central component is the authorization server, which should act as a specialist token issuer. In the azd template, the Curity Identity Server implements this role and can do so without changing user account storage or login screens. In the azd template, Entra ID stores users and manages user authentication.
Try the Architecture
For many organizations, AI is no longer optional. Instead, it is a critical success factor. Limiting the use of AI can create a competitive disadvantage. Meanwhile, ungoverned deployments create unacceptable levels of risk. Access intelligence bridges that gap, so that you embrace AI with confidence, and security provides a competitive advantage.
To implement access intelligence, you need end-to-end security for users, applications, agents and APIs. The azd template demonstrates the setup and deployment of that architecture. The template separates concerns across 3 main roles:
An operational-focused person can study the deployment resources.
An Identity-focused person can study the use of tokens.
A development-focused person can study the application code.
You can download the Curity Identity Server from the Microsoft Market Place, or use the template to run it as containers in Azure. You remain within the Azure platform and can choose best-of-breed components from both managed services (like Foundry and Azure SQL) and cloud-native services (like your backend agents and the Curity Identity Server).
