Skip to main content
Integrations · Azure DevOps
Guild agents read, create, and update Azure DevOps resources using OAuth 2.0 credentials stored and injected server-side by Guild. Credential policies let you allow or deny specific operations before any request leaves Guild. Every call is recorded in Guild’s audit trail so teams can see exactly what each agent did.

Book a demo

See how teams govern agents that use Azure DevOps.

Start free

Connect Azure DevOps and scope your first agent.

What the Azure DevOps integration exposes

The tools cover work items, repositories, pull requests, pipelines, builds, approvals, environments, deployment groups, agent pools, check configurations, variable groups, and Git refs. Tools follow the naming pattern azure_devops_{resource}_{action}, for example azure_devops_work_items_create or azure_devops_builds_queue. Agents can read commit history, retrieve build logs, queue new builds, update approvals, and manage pipeline definitions. Because agents perform better with fewer tools, you can use pick() to include only the tools a given agent needs.

How it works

1

Open Credentials in Guild

Go to Credentials in Guild. The page lists services you can connect.
2

Authorize through Microsoft

Click Azure DevOps and complete the authorization through your Microsoft account. Guild stores the OAuth token server-side; your agent code never sees it.
3

Import tools into your agent

Import azureDevOpsTools from the package and spread it into your agent’s tools object. Use pick() to select only the tools your agent needs.

Why Azure DevOps access needs governing

An agent with broad access could queue builds, update approvals, delete repositories, or modify variable groups. Guild’s credential policies let you write ALLOW and DENY rules that the credential proxy enforces before any request reaches Azure DevOps. Rules can target specific operations by name or glob pattern, scope access to particular agents or workspaces, and restrict HTTP methods so a credential grants only read access. Tokens are stored and injected by Guild’s credential proxy; agent code, prompts, and containers never receive them. You can scope a credential to a single workspace, a single member, or one installed agent, so different agents use different identities. Scoped rules on the same credential let one agent list work items while another is allowed to update approvals. Teams that need tighter boundaries can turn on workspace-level isolation so agents in that workspace never fall back to the organization’s shared credential.

About the Azure DevOps integration

The @guildai-services/guildai~azure-devops package provides agents with access to the Azure DevOps REST API through Guild’s OAuth 2.0 integration. This integration is generally available for all production users.

Authentication

  • Type: OAuth 2.0 (Microsoft identity platform)
  • Token expiration: 1 hour (auto-refreshed)

Setup

1

Open Credentials

Go to Credentials in Guild.
2

Connect Azure DevOps

Click Azure DevOps and authorize through your Microsoft account.
3

Grant access

Authorize access to your Azure DevOps organization.

Usage

Selecting specific tools

Agents perform better with fewer tools. Use pick() to include only what your agent needs. Tools are named with the azure_devops_ prefix — for example, work_items_list becomes azure_devops_work_items_list.

Tools

Tools in the latest published version of guildai~azure-devops:

Webhook events

Azure DevOps does not support webhook triggers in Guild. This integration is API-access only.

Limitations

  • No webhook or trigger support
  • API access requires the user’s Azure DevOps organization to be accessible via the authorized Microsoft account

Frequently asked questions

No. Azure DevOps does not support webhook triggers in Guild. This integration is API-access only, so agents must poll for changes using tools such as azure_devops_pull_requests_get_pull_requests rather than reacting to events.
Write a DENY rule in the credential policy targeting operations such as azure_devops_repositories_delete and azure_devops_builds_delete. Guild’s credential proxy enforces the rule before the request reaches Azure DevOps, and a matching DENY always overrides any ALLOW rule. See credential policies for syntax.
No. Guild stores the token server-side and injects it through the credential proxy only after the policy check passes. The token never enters the agent’s code, container, prompt, or state.
Yes. You can scope a credential to a single workspace, a single member, or one installed agent from the Credentials page. Credential policy rules can further restrict which operations each agent may call on the same shared credential, using the agents field in the rule.

Put a governed agent on Azure DevOps this week

Book a demo

See how teams govern agents that use Azure DevOps.

Start free

Connect Azure DevOps and scope your first agent.
Also runs on Guild: Bitbucket · GitHub · Google Compute · Linear Read: Docs: Credential policies · Credentials · Tools in agents
Last modified on October 16, 2026