Azure DevOps

Bring AI assets from Azure DevOps repositories into the inventory via the supported export path.

Status

There is no first-party Azure DevOps connector in Airia's discovery connector set today, so ADO-resident AI assets cannot be auto-enumerated through a connection. Two things follow:

  • Repos hosted on GitHub are covered natively now through the GitHub connector (unlimited connections). Use it for anything living in GitHub.
  • ADO-resident assets can still be brought into the inventory today through the supported export/import path below. Assets imported this way are first-class inventory entries, identical in standing to auto-discovered ones: they can be classified (risk level, ISO/IEC 42001 and EU AI Act tags), flagged for evaluation, and brought under guardrails. The workaround affects how assets are found, not what you can do with them afterward.

What counts as an AI asset in a repo

The export step scans repository contents for these indicators; anything matching becomes a candidate inventory entry. Tune the exact patterns to your stack during the first run.

CategoryIndicators
Model SDK usageImports and dependencies such as openai, anthropic, azure-ai / azure-ai-inference, google-genai in requirements.txt, package.json, pom.xml, and similar
Prompt filesStandalone prompt assets and templates (*.prompt, prompts/ directories, system-prompt strings, templating-language prompt files)
Agent and pipeline definitionsAgent manifests, orchestration definitions, chain or graph specs checked into the repo
LLM keys and endpoints in configModel API keys and endpoint URLs in .env, config files, or infrastructure-as-code (a security finding as well as an inventory signal)
Workflow filesn8n workflow exports, LangGraph graph definitions, and similar agentic workflow files
Copilot extensionsGitHub Copilot Extensions and Copilot agent definitions committed to the repo
MCP server configsModel Context Protocol server manifests and client configurations (for example mcp.json)

Export from Azure DevOps

Goal: a normalized inventory file (CSV or JSON) of AI assets found across your ADO repos, using read-only access. A read-only PAT with the Code (Read) scope is sufficient for everything below; no write scopes are needed.

Step 1: inventory the repositories. List every Git repo in the org via the Azure DevOps REST API (GET https://dev.azure.com/{org}/_apis/git/repositories?api-version=7.1), authenticating with the read-only PAT (HTTP Basic, empty username, PAT as password). (Verified live 2026-08-05: a Code (Read)-scoped PAT returns 200 on this call and on /_apis/projects; no broader scope is needed.)

Step 2: scan each repo for the AI indicators. Two practical options:

  1. ADO Code Search API: query for the indicator strings (SDK import names, prompt-file globs, mcp.json, and so on) across repos. Requires the Code Search extension enabled on the org.
  2. Pipeline grep step: a CI pipeline that clones each repo and greps for the indicator patterns, emitting matches. Portable, no extension dependency, and it runs on your own agents inside your boundary.

Step 3: normalize the findings into a CSV/JSON with the same columns as the AI inventory import expects:

ColumnExample
namecontract-summarizer-agent
repo{org}/legal-ai-tools
typeagent definition / prompt file / SDK usage / MCP config
ownerteam or committer, from repo metadata
model/provideranthropic / azure-ai / openai
notesfile path, match snippet, detection method

The ADO endpoints, API versions (7.1), and the Code (Read) PAT scope were verified live against a real organization on 2026-08-05; the code-search endpoint (almsearch.dev.azure.com/{org}/_apis/search/codesearchresults) also authenticates with the same PAT and returns 200 (it needs the Code Search extension installed on the org to return matches).

Import into the Airia inventory

Airia supports three ways to get assets into the inventory:

  1. Native auto-discovery: connect an external platform and let Airia enumerate. Not applicable to ADO today.
  2. Manual entry: add an asset by hand in the UI. Good for one-offs.
  3. Bulk import: push the full normalized CSV/JSON in one operation. Use this for the ADO export.

Keep the inventory current

Because this discovery is manual until a native connector ships, re-run the export on a fixed schedule (weekly is a reasonable starting cadence) and re-import each refreshed export, so newly added repos and newly committed AI assets get picked up. The export pipeline can run as a scheduled ADO pipeline on your own agents, handing the normalized file to the bulk import with no manual scan each week. Retire the loop once a native ADO connector ships and is in production.

Was this page helpful?

On this page