Microsoft AI-103: Agent Identity in Azure AI Foundry
Agent identity becomes an architecture problem as soon as an AI system can do more than generate text. An agent that calls an API, reads a knowledge store, creates a ticket, queries a database, or invokes another agent needs a principal that downstream systems can authenticate and authorize. If every agent simply inherits the same broad application identity, the system may work, but it becomes difficult to answer a basic security question: which agent was actually allowed to do what?
Microsoft’s current documentation uses the Microsoft Foundry name for the platform that many teams still know as Azure AI Foundry. The naming matters less than the security model. Foundry Agent Service can work with project managed identity, agent-specific identity, and user-delegated authorization patterns. The design decision should be driven by the authority the agent needs, not by whichever authentication option is easiest during a prototype.
This is directly relevant to the current Azure AI developer certification role. The associated AI-103 scope includes designing agent solutions, integrating tools and knowledge, configuring deployments, and operating them safely. Identity is the control plane that makes those capabilities governable.
An agent identity should represent the agent, not the whole project
Microsoft’s agent identity framework introduces an agent identity as a special service principal in Microsoft Entra ID. That distinction is important because it creates a principal that represents the agent’s own actions instead of treating every operation as if it came from a shared project identity. The agent can receive its own role assignments, appear separately in audit trails, and be disabled without necessarily disabling other agents in the same project.
The framework also uses an agent identity blueprint. In Foundry, the blueprint can establish a federated trust relationship with the project’s managed identity. At runtime, the project identity authenticates the blueprint to Entra ID, Entra issues a token for the agent identity, and the agent identity then obtains access appropriate to the downstream resource. The practical security benefit is that the blueprint does not need a long-lived client secret.
This follows the same managed identity logic: remove stored secrets where possible, but do not confuse secretless authentication with broad authorization. A managed identity can still be over-privileged. The valuable step is giving each principal only the resource access it genuinely requires.
Project identity and agent identity solve different problems
A project managed identity is useful when multiple components are intentionally meant to share one Azure identity. It can simplify access to common infrastructure and can be appropriate for tightly controlled services where the project itself is the security boundary. It is weaker when agents in the same project have different responsibilities or when an audit must distinguish their downstream actions.
Agent-specific identity creates a narrower boundary. A research agent might read a document index but have no write permission. A ticketing agent might create service requests but have no access to the HR system. A remediation agent might be allowed to invoke a limited automation runbook only after an approval step. Those differences are hard to express if all agents use the same identity.
That is why agent permissions have to be designed, not merely configured later. The role of the agent, the tools it can call, the data it can retrieve, and the identity used for those calls need to be designed together.
Federated credentials are stronger than embedded secrets
Client secrets are attractive in development because they are familiar and quick. They also create lifecycle work: storage, rotation, accidental disclosure, expiry handling, and incident response. Certificates improve authentication strength but still require certificate lifecycle management. A federated credential backed by managed identity avoids storing a reusable secret in the agent blueprint and lets Azure handle credential rotation underneath the trust relationship.
That does not make every credential problem disappear. Developers still need to control who can assign roles, who can modify a blueprint, who can deploy an agent, and who can alter its tool configuration. Administrative permissions can be more dangerous than runtime permissions because changing a tool or role assignment can quietly expand what the agent is capable of doing.
A useful review therefore separates three authority layers: platform administration, deployment identity, and runtime identity. The administrator may create or configure resources. The deployment pipeline may publish a version. The runtime agent should have only the minimum permissions needed to complete its function. Collapsing all three into one principal makes later governance much harder.
User-delegated access belongs where the user’s authority matters
Some agent actions should happen on behalf of a signed-in person rather than under an application identity. If an assistant needs to read a user’s own data, respect user-specific permissions, or perform an action that should remain attributable to the user, delegated authorization can be a better fit than a shared service principal.
The design question is whether the agent is acting as a service or as a user’s representative. A background classification agent may legitimately use its own workload identity. A personal assistant reaching into user-owned resources may require an OAuth flow and per-user consent or authorization. Trying to force both scenarios through the same credential model usually produces either too much access or too much friction.
This is also where zero-trust thinking becomes practical. Zero-trust architecture is not a slogan about authentication. It means each request should be evaluated in the context of who or what is acting, what resource is being requested, and what level of access is actually necessary.
Tool permissions should be narrower than conversational capability
An agent can discuss a subject without being allowed to change the system associated with that subject. A support agent might explain an account policy but should not automatically have permission to alter account status. A cloud-operations agent might analyze resource health while write actions remain behind approval. The tool layer is where that distinction becomes enforceable.
For each tool, document the authentication mode, target resource, required role, write capability, and failure behavior. Then ask whether every agent using the tool needs the same authority. If not, split the tool surface or assign separate identities. An all-purpose function that can read, create, update, and delete objects is difficult to constrain once it becomes available to an autonomous planner.
Least privilege is easier when tools themselves are designed for narrow actions. A function called restart-approved-service with strict server-side checks is safer than a generic execute-command tool even if both sit behind the same agent. Identity and tool design reinforce each other.
Agent-to-agent calls need an explicit trust model
Multi-agent systems introduce another boundary: one agent can become a caller and another can become a service. The receiving agent needs to know whether the caller is a trusted workload, another identified agent, a user-delegated actor, or an anonymous client. Treating agent-to-agent communication as internal and therefore trusted recreates the same assumptions that zero-trust architectures were designed to remove.
Foundry supports multiple authentication approaches for agent-to-agent scenarios, including agent identity, project managed identity, user passthrough, and key-based patterns. The right choice depends on whether each calling agent needs its own authorization boundary. Shared project identity can be reasonable for a tightly coupled workflow. Agent identity is stronger when permissions or audit requirements differ between callers.
If the system is moving toward multiple specialized agents, review multi-agent orchestration at the same time. Identity cannot repair an orchestration model in which any agent can call any other agent with any payload. Trust boundaries and execution paths need to agree.
Lifecycle controls matter because agents are easy to create
Agents can be provisioned much faster than traditional enterprise applications, which means identity sprawl can arrive quickly. A proof-of-concept agent may become a production dependency before anyone defines an owner, expiry policy, access review, or decommissioning process. The more automated agent creation becomes, the more important automated identity lifecycle becomes as well.
Maintain an inventory that connects each agent identity to an owner, project, purpose, deployment version, approved tools, and downstream roles. Expired experiments should not leave active principals behind. Role assignments should be reviewed when the agent changes function, not only on a calendar schedule.
The same principle appears in the broader agent lifecycle: production readiness is a sequence of controls, not a deployment event. Identity is one of the clearest indicators that a system has crossed from experimentation into something the organization must govern.
Audit the action chain, not just the final API call
Traditional audit logs often tell you that a service principal accessed a resource. Agent systems need more context. Useful telemetry connects the user request or triggering event, the agent identity, the reasoning or workflow step, the selected tool, the downstream API operation, and the result. Without that chain, an operator may know which credential was used but not why the action occurred.
This does not require storing every private prompt forever. It does require a deliberate observability model with correlation IDs, safe event metadata, authorization results, tool-call outcomes, and deployment versions. Sensitive content can be minimized while still retaining enough evidence to reconstruct the operational path.
For teams building on Azure AI engineering, identity therefore sits beside retrieval, safety, capacity, and monitoring as a first-class subsystem. The strongest pattern is not simply “use managed identity.” It is to make the agent a recognizable security principal, give it the smallest useful authority, keep user-delegated actions separate when necessary, and preserve an audit trail that explains what the agent actually did.