Anton Staykov

Posted on Jun 4

Your AI agent doesn't need a PAT to work in Azure DevOps

#entraagentid #azuredevops #aiagents #identity

At Collab Summit 2026 in the beginning of May, a fellow I had not seen in years caught me between sessions. We did the usual catching up, and then he got to the real question: "We're building an AI agent that works inside Azure DevOps. It creates work items, pushes code to branches, opens pull requests. Right now it authenticates with a PAT. How do we do this properly?"

The room around us was full of people building similar things. AI agents that are not chatbots answering questions, but digital co-workers: autonomous participants on a development team, shipping code, triaging issues, responding to reviewer feedback. The pattern is already in production across more organizations than most conference talks acknowledge.

His question deserved a better answer than "use a service principal." So I went home and built one.

The identity primitives that were never designed for this

When a non-human caller needs to authenticate to Azure DevOps, two standard options exist today. Neither was designed for an autonomous AI agent acting as a member of a development team.

Personal Access Tokens (PATs). A PAT is a static bearer credential tied to a human user. It carries that user's identity and permissions, which means the agent's actions appear in audit logs as if the human performed them. There is no way to distinguish "the developer pushed a commit" from "the developer's agent pushed a commit." The token does not expire unless someone sets a date and remembers it. It cannot be scoped to a governed agent identity. It is a secret that sits in an environment variable and waits to be leaked.

Entra workload identities (service principals and managed identities). Azure DevOps now supports Entra workload identity authentication for pipelines, which is a genuine improvement: service principals and managed identities can be added as users to an Azure DevOps organization, and pipelines authenticate to Azure DevOps resources through Workload Identity Federation with zero stored secrets. The credentials problem is solved. But the identity model is still the pipeline model. A service principal added to an ADO organization has no concept of owner, sponsor, or blueprint. It has no delegated user pattern. Your SOC cannot filter its sign-in events as agentic activity. It is infrastructure plumbing designed for CI/CD jobs accessing repos and artifact feeds, not for a digital co-worker whose commits, work items, and PR comments should carry a traceable, governed agent identity with lifecycle metadata.

Both options were designed for a world where non-human callers were pipelines, scheduled jobs, or integration hooks. That world is not the one we are building in anymore.

What an AI agent actually needs

An AI agent that operates as a digital co-worker on a development team needs something fundamentally different from a pipeline credential. It needs an identity.

Not a token. Not a secret. An identity with the same governance surface that a human team member carries:

An owner who is accountable for what the agent does.
A sponsor with business context for why the agent exists.
Auditable sign-in events that your SOC can filter, correlate, and alert on, tagged explicitly as agentic activity.
A credential model where the agent's runtime code never touches secrets (because secrets in agent memory are an attack surface, not a convenience).
A lifecycle that ties the identity to the agent's existence, so decommissioning the agent means decommissioning its access.

This is not a wishlist for a future platform. This is what Microsoft Entra Agent ID provides today.

Entra Agent ID: the IAM shift

If you have followed this series, you have seen Entra Agent ID applied to calling third-party model APIs without API keys and to building secret-less agentic platforms with managed identities and Workload Identity Federation. The pattern is consistent, but it is worth stating the fundamental shift plainly, because it changes how we think about IAM for AI agents.

Traditional IAM for non-human workloads treats the workload as infrastructure. You create a service principal, hand it credentials, scope its permissions, and monitor it (if you remember) through workload identity logs that most SOC teams never look at. The workload has no owner in the governance sense. It has no sponsor. It has no blueprint that propagates policy to every instance. It is a row in an app registration table that someone created two years ago and nobody is sure whether it is still in use.

Microsoft Entra Agent ID treats the AI agent as a participant. The identity constructs are purpose-built:

Agent Identity Blueprints are the authentication foundation and the policy anchor. A blueprint holds (or federates) the credentials and parents one or more agent identities. Conditional Access policies applied to a blueprint propagate to every agent identity it creates. One policy decision, enforced across an entire family of agents.
Agent Identities are the runtime identity of a specific agent. No credentials of their own. They authenticate through their blueprint. They carry owner and sponsor metadata. They produce sign-in events tagged as agentic, visible in the same logs your SOC already monitors.
The Entra SDK Auth Sidecar handles all credential work in a separate container. The agent code never sees a secret, never handles token acquisition, never stores credentials in memory. The sidecar is not exposed to the host network, so the token acquisition surface is isolated from the agent's own attack surface.

This is not a better way to do service principals. It is a different category.

The delegated user pattern and Azure DevOps

For an AI agent that acts as a digital co-worker on a development team, the Agent ID User (delegated) pattern is the right fit. The agent acts on behalf of a specific user (its own agent user account in Entra), and every action it takes in Azure DevOps carries that user's identity.

The identity flow:

The sidecar authenticates to Entra ID using the blueprint's credentials.
The agent requests a token from the sidecar for Azure DevOps, specifying its Agent Identity and its Agent Username.
The sidecar performs the Federated Identity Credential (FIC) token exchange with Entra ID.
Entra issues a Bearer token scoped to the Azure DevOps resource (499b84ac-1321-427f-aa17-267ca6975798).
The agent calls the Azure DevOps REST API with that token.

The agent user is a real member of the Azure DevOps organization, with its own access level, project permissions, and repository access. When the agent creates a work item, it appears as created by the agent user. When it pushes a commit, the commit author is the agent user. When it opens a pull request, the PR creator is the agent user. The audit trail is clean, attributable, and governed.

No PAT. No service connection. No secret stored in agent code. The only credential in the system is the blueprint's, managed by the sidecar in an isolated container.

The proof of concept

I built a proof of concept that demonstrates the full pattern. The agent is powered by Azure OpenAI with function calling and can create work items, push file changes to new branches, open pull requests with reviewer assignments, read PR comment threads, and reply to reviewer feedback.

The architecture is deliberately simple: two containers on a Docker bridge network. The Entra SDK auth sidecar handles token acquisition; the agent handles DevOps operations. The sidecar has no host port exposure (per Microsoft's security guidance); the agent exposes a chat interface on port 4192 for demonstration purposes only.

The chat interface is there because it makes it easy to observe what the agent is doing during a demo. In a production deployment, the agent would be fully autonomous: triggered by events (a new issue, a failing build, a PR review request), executing its DevOps workflow, and reporting results through whatever channel the team uses. The identity model is identical either way.

The PoC includes a chat UI where you can give the agent instructions like "Create an issue titled 'Fix login timeout', push a fix to a new branch, and open a PR for it." The agent orchestrates the entire flow, calling Azure DevOps REST APIs through the sidecar-acquired tokens. The repository README covers the prerequisites, the Entra configuration (including the delegated permission grants that are easy to miss), and the Docker Compose setup.

What the Entra side requires

The Entra configuration involves four objects, and the relationship between them is worth understanding even if the README walks you through it:

A Blueprint app registration that holds the credentials (client secret for local development; managed identity as a federated credential for production, as covered in a previous article in this series).
An Agent Identity (service principal) created from the blueprint. This is the agent's runtime identity.
An Agent User in your Entra tenant. This is the user account the agent acts on behalf of.
Delegated permission grants created via Microsoft Graph's oauth2PermissionGrant endpoint. The Agent Identity needs user_impersonation on the Azure DevOps resource and the standard OpenID Connect scopes on Microsoft Graph. These grants must be scoped to the Agent User (consent type Principal, not AllPrincipals). This is the step most people miss on their first attempt.

What the Azure DevOps side requires

The Azure DevOps side is surprisingly straightforward:

The organization must be backed by the same Entra tenant.
The Agent User must be a member of the organization with Basic access level (Stakeholders cannot access Code/Repos).
The Agent User needs project-level permissions: Work Items (Read/Write), Code (Contribute), and Pull Requests (Create) on the target project and repository.

That is it. No service connection to configure. No PAT to mint and rotate. The agent authenticates through Entra, and Azure DevOps sees a regular user with scoped permissions.

From demo to production

The PoC runs on Docker Compose with a client secret for the blueprint. A production deployment changes three things:

Replace the client secret with a managed identity federated credential or a Workload Identity Federation credential from your compute platform (AKS, Container Apps, etc.). The sidecar supports both through its credential source configuration.
Use the sidecar for Azure OpenAI authentication too. The PoC uses an API key for Azure OpenAI because the focus is on the Azure DevOps identity pattern, but in production, the sidecar should acquire tokens for the Cognitive Services resource as well. No reason to have any static secret in the system.
Add the governance layer. Wire the agent's sign-in events into your SOC monitoring. Set up access reviews keyed to actual API usage, not calendar recertification. Apply Conditional Access policies to the blueprint. Earlier articles in this series (governance and discovering consents) cover the governance model in detail.

The answer to the question

The fellow at Collab Summit asked how to connect an AI agent to Azure DevOps properly. The answer is not a better secret. It is a better identity.

Microsoft Entra Agent ID gives the agent a governed, auditable, purpose-built identity. The Entra SDK auth sidecar keeps credentials out of agent code. The delegated user pattern makes the agent a traceable participant in Azure DevOps, not an anonymous caller hiding behind a PAT.

The proof of concept is on GitHub. Clone it, configure the Entra objects, run docker compose up, and watch an AI agent create issues, push code, and open pull requests, all authenticated through its own agent identity.

If your AI agents are still running on PATs, the question from Collab Summit applies to you too. And the answer is the same: stop managing secrets. Start managing identities.

DEV Community