GitHub

Airia discovers AI assets living in your GitHub repositories: agent frameworks, model SDK usage, prompt files, workflow definitions, MCP server configurations, and hard-coded LLM keys or endpoints.

How GitHub discovery works

GitHub discovery is powered by the Airia Code Scanner, which runs as a GitHub Actions workflow inside your repositories. Each scan analyzes the repository's contents and reports its findings to your Airia tenant; every scanned repository (or pull request) then appears as a GitHub connection under Discover → Connect, with the discovered code-based agents in the inventory. There is no credential form to fill in on the Airia side: the scanner authenticates to Airia with an API key you store as a repository secret.

What the scanner detects

Category	Indicators
Agent frameworks	CrewAI, LangGraph, LangChain, and similar framework usage and agent definitions
Model SDK usage	Imports and dependencies such as `openai`, `anthropic`, `azure-ai`, `google-genai` in `requirements.txt`, `package.json`, `pom.xml`, and similar
Prompt files	Standalone prompt assets and templates (`*.prompt`, `prompts/` directories, system-prompt strings)
LLM keys and endpoints in config	Model API keys and endpoint URLs in `.env`, config files, or infrastructure-as-code (a security finding as well as an inventory signal)
Model artifacts	Model files and references (including hosted model references such as Hugging Face)
Workflow files	n8n workflow exports, LangGraph graph definitions, and similar agentic workflow files
MCP server configs	Model Context Protocol server manifests and client configurations (for example `mcp.json`)

Customer-side setup steps

In Airia, generate an API key for the scanner: top-right user menu → Settings → Developer → API Keys → Generate Key. Keep Service account selected, since the key is shared with your CI pipeline. Under Roles, select End User. The scanner only reports findings, which needs a valid key but no particular permission, so the least-privileged default role is enough. Name it something like code-scanner, click Create, then copy the key (shown once).
In the GitHub repository (or organization), add two Actions secrets: the Airia API key, and your Airia API URL (both values come from your Airia environment).
Add the Airia Code Scanner workflow file under .github/workflows/ (your Airia team provides the current workflow template). It runs the scanner container on pull requests or on demand and reports findings to Airia.
Trigger the workflow (open a pull request or run it manually from the Actions tab).
In Airia, open Discover → Connect → GitHub: the scanned repository appears as a connection, and its discovered agents land in the inventory with their detected frameworks and model references.

Microsoft Foundry hosted agents

A Foundry hosted agent is one whose code you build and deploy, and that Foundry runs for you. Its definition lives in your repository rather than in the Foundry portal, so the Azure AI Foundry connector alone cannot tell you which repository it came from. The code scanner can: it recognizes the configuration that deploys a hosted agent and records where the agent comes from.

Hosted-agent provenance is enabled per tenant. Ask your Airia team to turn it on.

What counts as a hosted agent

The scanner reports an agent only when the repository deploys one. Using a Foundry SDK (azure-ai-projects, azure-ai-agents) without deployment configuration does not create an agent.

Configuration	Reported when
`azure.yaml` (Azure Developer CLI)	a service has `host: azure.ai.agent` and `kind: hosted`. Service `$ref` includes are followed.
`azure.yaml` with `<source>/agent.yaml`	the older two-file layout, where `agent.yaml` declares `kind: hosted`.
`agent.yaml` on its own	the deprecated format: `kind: hosted` with a `protocols` list. No Foundry project is known.

Prompt, voice and workflow agents are not reported from the repository: Foundry stores their full definition, and the Azure AI Foundry connector discovers them directly.

What the inventory shows

Open the agent in Discover → Inventory. The Source repository section shows:

the repository, its owner and the scanned branch, with a link to the file that declares the agent;
the Foundry project the agent deploys to, taken from the endpoint of the azure.ai.project service it uses. When the endpoint is an azd variable, or azd creates the project at deploy time, the section says so instead of showing a blank;
the deploy mode (source code, container or prebuilt image) and any CI step that runs azd deploy or azd up for the azd project that declares the agent;
Foundry deployment: whether a connected Azure AI Foundry project actually lists the agent;
anything the scanner could not determine from the repository.

The same repository, Foundry project and deployment status appear in the agent's Deployment section in Governance, which is where an agent linked to a use case opens. Hosted agents link to use cases like any other discovered agent.

Foundry deployment	Meaning
Confirmed	The connected Foundry project was read in full within the last 24 hours and lists the agent.
Not found in project	The connected project was read in full within the last 24 hours and does not list the agent. It may not be deployed yet, or it was deployed under another name.
Project unreachable	The Foundry connection has not read its project's agent list in full within the last 24 hours — its latest refresh failed, or none has completed — so the deployment could not be checked. The connection's last error is shown when there is one.
Project not connected	No Azure AI Foundry connection covers the project. Connect it to check the deployment.
Matched by name	The repository does not name its project; exactly one connected project lists an agent with this name.
Ambiguous match	The repository does not name its project, and several connected projects list an agent with this name.
Project unknown	The repository does not name its project, every connected project was read in full within the last 24 hours, and none lists an agent with this name. If any connected project was not, the status is Project unreachable instead.

The agent keeps its identity, and the date it was first discovered, across scans. Moving the declaration within the azd project does not create a new agent.

Notes

One connection appears per scanned repository/scan target; multiple repositories mean multiple connections (unlimited).
Discovered code-based agents carry the detected model reference where the scanner can extract one; agents whose model is not declared in code show without a model.
GitHub is the supported source for code scanning today. If your repositories live in Azure DevOps, see the Azure DevOps coverage page for the supported interim path.