Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
After you understand why agent identity matters and the different actors involved, decide how your agent accesses data and systems. This article focuses on the core access patterns and control mechanisms that turn identity concepts into a working, secure implementation. You learn how to choose between delegated and app-only access, apply managed and workload identities, scope permissions by tool, and add policy checks and approvals before actions execute. The goal is to help you build an agent that can act usefully while still enforcing predictable, auditable controls.
Choose an access pattern
Most agent workloads need one or more access patterns.
| Pattern | Use when | Example |
|---|---|---|
| Delegated access | The agent acts on behalf of a signed-in user | A support agent reads tickets the user is allowed to access |
| App-only access | The application acts without a signed-in user | A background agent summarizes system events overnight |
| Managed identity | The Azure-hosted workload accesses Azure resources that support Microsoft Entra authentication | An agent hosted on Azure App Service accesses Azure Storage without storing a secret |
| Service principal | The workload needs an application identity, especially when managed identity isn't available | A multitenant SaaS application accesses resources through an app registration and service principal |
| Agent identity | You need a distinct governed identity for the AI agent itself | An enterprise customer needs agent-specific identity, access, lifecycle, and audit controls |
The Microsoft identity platform supports both delegated access and app-only access. Delegated access uses delegated permissions, also called scopes, and the application acts on behalf of a signed-in user. App-only access uses application permissions, also known as app roles, and the application acts as itself without a signed-in user.
Tip
For user-owned data, prefer delegated access when possible so the agent can't access more than the user is allowed to access. For background automation, use app-only access with the smallest set of permissions required.
Use delegated access carefully
Delegation is important when an agent acts for a user. In the Microsoft identity platform, the OAuth 2.0 on-behalf-of flow describes a web API calling another web API using delegated user identity and permissions through the request chain.
Use delegated access when:
A user signs in.
The user asks the agent to perform an action.
The downstream API should enforce what that user is allowed to do.
The action should be traceable back to the user's request.
Don't use a backend identity to bypass user permissions. If the agent reads customer records, documents, tickets, emails, or files, preserve user-level authorization unless there's a clear product reason and explicit control for app-only access.
Use managed identities and workload identities where they fit
A managed identity is a Microsoft Entra identity that you assign to supported Azure compute resources and app hosting platforms. Managed identities enable applications to get Microsoft Entra tokens without developers managing credentials. They can replace secrets such as access keys or passwords for service-to-service dependencies.
Use managed identities when:
The workload runs on Azure.
The Azure service supports managed identity.
The target resource supports Microsoft Entra authentication.
You want to avoid storing secrets in code, configuration, or prompts.
For workloads outside Azure, CI/CD pipelines, containers, scripts, or multitenant application scenarios, use workload identity patterns such as service principals or workload identity federation where appropriate. Microsoft recommends managed identities for services hosted in Azure when the service supports them, and service principals when managed identities can't be used.
Scope permissions by tool
Agents usually call tools. A tool might search, read, update, delete, submit, send, provision, or approve. Each tool should have the smallest useful permission set.
| Tool | Safer permission model |
|---|---|
| Search knowledge base | Read-only access to approved indexed content |
| Draft email | No send permission until the user approves |
| Update CRM record | Write access only to allowed fields and allowed customer scope |
| Create support ticket | Permission to create tickets, not administer the ticketing system |
| Query billing data | Read access to billing data for the current tenant only |
| Provision Azure resource | Narrow Azure RBAC role at the smallest practical scope |
Azure RBAC helps manage who has access to Azure resources, what they can do, and what scope the access applies to. Role assignments include a security principal, role definition, and scope. Use this model to avoid broad subscription-level access when a resource group or resource-level assignment is sufficient.
Avoid giving an agent or tool the Owner role unless there is a specific administrative scenario and strong governance around it. The Owner role grants full access to manage all resources, including the ability to assign roles in Azure RBAC.
Separate read and write actions
Read and write actions have different risk profiles. Keep them separate.
| Action type | Recommended control |
|---|---|
| Read public or low-risk content | Allow through normal application checks |
| Read customer or tenant data | Require user or tenant authorization |
| Draft content | Allow draft creation without external side effects |
| Send, submit, delete, or update | Require policy checks and often explicit user approval |
| Change permissions or infrastructure | Require privileged workflow, audit logging, and human review |
This separation helps you move quickly without giving every tool production-level power. A startup can allow the agent to draft, summarize, classify, or recommend before allowing it to write, send, delete, or provision.
Add policy checks before tool execution
A policy layer is the deterministic part of the system that decides whether an action is allowed. It should run before tool execution.
A useful policy check can include:
Who is the user?
Which tenant or customer does the request belong to?
Which agent is acting?
Which tool is being called?
Is the tool read-only or write-capable?
What resources are targeted?
What permission, role, or scope applies?
Is approval required?
Should the action be logged, blocked, or escalated?
Early on, this policy layer might be application code. Later, it might become a centralized policy service. The important part is that authorization is enforced outside the model.
Audit agent actions
Identity controls are only useful if you can explain what happened later. For agent workloads, audit and observability should connect to the user request, agent decision, policy check, tool execution, resource touched, and final outcomes.
Start with:
Application logs for important agent decisions and tool calls.
Azure Monitor for collecting, analyzing, and acting on metrics, logs, traces, and events.
Azure Monitor Application Insights for application performance monitoring and OpenTelemetry-based telemetry.
Microsoft Foundry tracing for supported agent scenarios.
Microsoft Entra logs for identity and access events.
Microsoft Foundry tracing can capture details such as latency, exceptions, prompt content, retrieval operations, tool usage, inputs and outputs, token consumption, and conversation details. Microsoft currently states that tracing is generally available for prompt agents, while workflow, hosted, and custom agents are in preview.
Because tracing can capture sensitive information, don't store secrets, credentials, or tokens in prompts, tool arguments, or span attributes. Redact or minimize personal data and other sensitive content before it appears in telemetry.
The goal isn't to build a full observability platform on day one. The goal is to make sure every important agent action can be traced from request to decision to execution.
With access patterns and controls in place, the final step is preparing your agent for production and enterprise use. This article explores how to evolve your identity model to meet real-world requirements for governance, observability, and trust.