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.
Building an AI agent is easier than ever. A startup can often get value from an agent as soon as it works: it answers questions, calls a few tools, updates a record, or helps a small team move faster. At that stage, the identity model is often simple because the team, data, customers, and risk are still small.
That same design usually is not enough for enterprise use. Enterprise customers expect to know who or what the agent represents, what the agent is allowed to do, whether it is acting on behalf of a user, which policy allowed the action, and how the action can be audited later.
For example, a startup might ship an internal support agent that uses one backend identity to search for tickets, summarize issues, and draft replies for a trusted operations team. That can be acceptable for a prototype or small internal workflow. It would not pass most enterprise reviews if the same identity could access every customer's tenant, use broad write permissions, or leave no reliable audit trail of which user requested which action.
This article explains how to evolve from a simple working agent toward an identity model with authentication, authorization, delegation, scoped permissions, policy enforcement, and auditing patterns for startups building AI agents on Azure and Microsoft Entra.
This page explains:
Explain why agent identity matters as agents move from prototype to enterprise use.
Identify the key actors in an agent workflow: user, app, workload, agent, tool, and resource.
Choose safe access patterns for delegated access, app-only access, managed identities, and agent identities.
Apply practical controls for scoped permissions, policy checks, approvals, and audit logs.
Understand where Microsoft Agent 365 fits enterprise observability, governance, and security.
Why identity for agents matters for startups
For a startup, the fastest path to shipping an AI agent is often to give the agent access to whatever it needs and move on. That approach might work for a demo, but it creates risk as soon as the agent can access customer data, modify records, call internal systems, or act across tenants.
Microsoft describes an agent as an application that attempts to achieve a goal by understanding its environment or context, making decisions, and acting on those decisions using available tools. That makes agent identity different from a traditional app or background job. The agent might choose which tool to call, operate with or without human intervention, and act across multiple systems.
A good identity model helps you answer basic questions:
Who initiated the request?
Which agent or application processed it?
Which tools or APIs were called?
Was the action performed on behalf of a user or by the application itself?
Was the action allowed by policy?
What resources changed?
Can the action be reviewed later?
If you cannot answer those questions, your agent might be useful, but it is not yet ready for enterprise-grade production trust.
Treat agents as accountable actors
Enterprises do not manage access only by asking whether software works. They need to understand every actor in the environment. For human users, that means knowing who the person is, what they can access, what they cannot access, what actions they can perform, and which actions require more control.
AI agents need a similar treatment. An agent is not a person, but it can behave like an actor in business workflows. It might read data, call tools, update records, trigger approvals, or interact with users. Enterprise customers need controls that make those actions visible, governed, and bounded.
| Enterprise question | Human user example | Agent equivalent |
|---|---|---|
| Who is this actor? | A named employee, partner, or customer account | A distinct agent identity, application identity, or workload identity |
| What can it access? | Files, apps, data, or systems assigned to the user | Tools, APIs, data sources, and resources assigned to the agent or application |
| What is off limits? | Restricted groups, sensitive apps, or privileged roles | Disallowed tools, tenants, records, permissions, or high-risk operations |
| What can it do? | Read, write, approve, administer, or delegate | Search, summarize, draft, update, submit, provision, or escalate |
| How is it governed? | Access reviews, Conditional Access, audit logs, and lifecycle controls | Agent identity, policy checks, approval gates, telemetry, audit logs, and lifecycle governance |
This parallel is useful for startups because it makes enterprise expectations easier to understand. The customer is not only buying an agent that works. They are evaluating whether the agent can be identified, constrained, monitored, reviewed, and retired safely.
Understand the identities involved
Agent systems usually involve more than one identity. Treat these identities as separate concepts, even if your first implementation is simple.
| Identity | What it represents | Startup guidance |
|---|---|---|
| User identity | The person using the product or initiating a request | Authenticate users with Microsoft Entra ID, Microsoft Entra External ID, or another appropriate identity provider |
| Application identity | The app, API, or backend service that hosts the agent experience | Use an app registration, service principal, or managed identity depending on where the workload runs |
| Workload identity | A non-human software workload such as an application, service, script, or container | Use workload identity patterns for software workloads that need to authenticate to other services |
| Managed identity | A Microsoft Entra identity assigned to a supported Azure resource | Use managed identities for Azure-hosted workloads when supported to avoid managing credentials |
| Agent identity | A distinct identity construct for an AI agent | Evaluate Microsoft Entra Agent ID when you need purpose-built identity constructs for agents |
| Tool identity | The credentials or authorization context used by a specific tool or connector | Keep tool permissions narrow and separate read actions from write actions |
| Resource identity | The target system, API, database, storage account, or business application | Protect resources with authorization checks, role assignments, scopes, and audit logs |
Do not collapse all of these into one shared secret or one highly privileged service account. Even in a prototype, keep enough separation that you can reason about who did what.
What makes agent identity different
Traditional applications usually follow predictable code paths. AI agents can be more dynamic. They can select tools, decide when to call them, chain multiple steps, and adapt behavior based on user input and context.
Microsoft describes agent identities in Microsoft Entra Agent ID as identity accounts within Microsoft Entra ID that provide unique identification and authentication capabilities for AI agents. Agent identities help distinguish operations performed by AI agents from operations performed by workforce, customer, or workload identities.
Think of these as the practical startup takeaways:
Do not treat the model as the security boundary.
Do not let the agent decide on authorization by itself.
Do not give an agent broad standing access because it is convenient.
Do keep deterministic application, identity, and policy checks around tool execution.
Do log enough context to explain important actions later.
The agent can reason about what to do next. Your application should still decide whether the action is allowed.
Now that you understand why identity matters for AI agents and the different actors involved, the next step is deciding how your agent actually accesses data and systems. This article focuses on the access patterns and controls that turn those concepts into a secure implementation.