Skip to main content

Cross-Tenant ADO Work Items with OAuth

What you'll build

An Azure DevOps OAuth connector that lets the agent read repo content and create work items in a different tenant's ADO organization, signed in as you.

OAuth is the fastest way to validate cross-tenant ADO access. The connector uses your Entra ID sign-in, so the agent inherits whatever ADO permissions you have in the target tenant - no app registration, no Federated Identity Credential, no service principal to provision.

When you're ready to move off your personal identity for production, switch the same agent to the MI + FIC knowledge source path. The Azure DevOps MCP connector will pick up whichever per-organization auth you have configured.

Prerequisites​

  • An Azure SRE Agent in Running state
  • SRE Agent Administrator role on the agent (connector management requires admin)
  • A user account in the target tenant with Contributor access on the ADO project (required for work item creation)

Step 1: Add the Azure DevOps OAuth connector​

  1. Open your agent at sre.azure.com
  2. Go to Builder -> Connectors -> Add connector
  3. Select Azure DevOps OAuth connector
  4. Click Next

Step 2: Configure and sign in​

  1. Name: Enter a descriptive name (e.g., cross-tenant-ado-oauth)
  2. Organization: Enter the target ADO organization name (e.g., contoso or myorg)
  3. Authentication method: Select Auth
  4. Click Sign in to Azure DevOps
  5. Complete the Entra ID sign-in in the popup using your account in the target tenant
  6. On success, you'll see Connected to Azure DevOps with a green checkmark
Checkpoint

If you see "Authentication Failed," verify your account has access to the specified ADO organization.

Step 3: Review and add​

  1. Click Next to review
  2. Verify Name, Organization, and Type: Azure DevOps OAuth
  3. Click Add

The connector appears in your connectors list with Connected status.

Step 4: Test it​

Open a new chat thread and try both reading and writing:

Search code:

"Search for authentication error handling in the payment-service repo"

Reference a wiki:

"What does our team wiki say about the deployment rollback procedure?"

Wiki access uses Knowledge Sources

The OAuth ADO connector grants the agent code-search and work-item access only. To let the agent search a wiki, add it through Knowledge Sources -> Add Azure DevOps (the same flow used for ADO repos) - see Azure DevOps as a Knowledge Source.

Create a work item:

"Create a task in our Azure DevOps project to investigate the high CPU alert on web-prod-01"

"File a bug in the payment-service project for the P1 incident - include the root cause analysis"

Checkpoint

For reads, the agent returns code snippets. For work items, the agent confirms the action and includes a link to the new item in ADO.

When OAuth isn't enough​

OAuth tokens are bound to your identity, so the connector stops working when you leave the team or your sign-in lapses. For agents that run unattended in production, set up MI + FIC on the same agent - the Azure DevOps MCP connector will use it for the same organization automatically.

PAT fallback​

If neither OAuth nor MI + FIC is an option, the Add Repository dialog accepts a Personal Access Token:

  1. In the target ADO org, go to dev.azure.com/{org}/_usersSettings/tokens -> New Token with scopes Work Items: Read & Write and Code: Read.
  2. In the agent, open Knowledge sources -> Add repository, choose Azure DevOps, switch the auth method to Personal Access Token, enter the organization, paste the PAT, and save.
  3. Ask the agent to create a work item to confirm it's using the stored PAT.
Automate PAT registration via REST API

For unattended automation (CI/CD pipelines), you can POST the PAT directly to the agent's REST API instead of using the portal:

curl -X POST "https://<your-agent-endpoint>/api/v1/azuredevops/auth/pat" \
  -H "Authorization: Bearer <your-agent-token>" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "organization=<your-ado-org>&pat=<your-pat>"

PATs expire(max one year), are scoped to the user that issued them, are not centrally rotatable, and are a common leak vector. Microsoft Entra tokens, managed identities, and service principals are the recommended ADO authentication methods. Treat PAT as a last-resort fallback and switch to OAuth or MI + FIC when you can.

What you learned​

  • OAuth gives the agent full read + write access to a cross-tenant ADO org using your identity, with no FIC or app registration setup
  • For unattended production use, switch the same agent to MI + FIC
  • PAT via the Add Repository dialog is the last-resort path

Troubleshooting​

For OAuth sign-in failures, check the connector status in the portal. For MI + FIC issues on the same agent, see the Cross-Tenant ADO Access tutorial.

ResourceWhat you'll learn
Cross-Tenant ADO Access (FIC)persistent MI + FIC setup (read + write)
Cross-Tenant Connector Accessfull cross-tenant architecture
ADO OAuth ConnectorsOAuth connector capabilities

Next steps​

Last updated on
Was this page helpful?
Report an issue with this page