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. Usepick() 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 ofguildai~azure-devops:
All 120 tools
All 120 tools
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
Can Guild trigger an agent when a pull request is opened in Azure DevOps?
Can Guild trigger an agent when a pull request is opened in Azure DevOps?
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.
How do I stop an agent from deleting repositories or builds?
How do I stop an agent from deleting repositories or builds?
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.
Does the agent ever see the OAuth token?
Does the agent ever see the OAuth token?
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.
Can one Azure DevOps credential serve some agents but not others?
Can one Azure DevOps credential serve some agents but not others?
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.