Microsoft opened a new public repository on October 27, 2026: microsoft/foundryx-plugin. It is a GitHub Copilot plugin that adds a /foundry-agent skill and a preview FoundryX Canvas so a coding agent can create, deploy, evaluate and operate Microsoft Foundry agents through a new command-line tool called foundryx. The repo is MIT-licensed according to the GitHub API, had zero stars when we looked, and has no description line. This is a release from a top lab's org, so it is worth reading closely, but it is also thin on public context, and we say plainly below what we could not confirm.
If you only want the answer: it is a thin wrapper. The plugin ships instructions and a UI panel; the real work happens in a separate CLI that is not in the repo and is aimed at tenants already onboarded to FoundryX.
TL;DR: the questions people will ask first #
| Question | Answer |
|---|---|
| What is it? | A Copilot plugin named foundry-agent , version 0.7.1, with one skill and one canvas extension |
| Who made it? | Microsoft ( plugin.json lists Microsoft as author) |
| What does it drive? | The foundryx CLI against customer-owned Foundry projects |
| Does it include the CLI? | No. You install a matching release separately |
Is it the microsoft-foundry plugin? |
No. It leaves that plugin alone and does not provide the native azd ai workflow |
| Is it free? | The plugin is MIT-licensed. Deploying, invoking, evaluating and publishing agents can cost money |
| Production ready? | The canvas is labelled Preview. Treat everything as preview |
| Who can use it? | People in a tenant already onboarded to FoundryX; Microsoft has not published a broad announcement |
What is actually in the repository #
The package layout in the README is small: a marketplace.json, a plugin.json, a skills/foundry-agent/ folder with a SKILL.md and references, and a com.github.copilot/extensions/foundry-canvas/ folder holding the canvas extension. The README also states that the generated skill and canvas come from a separate FoundryX source repository, so changes are supposed to go upstream and be re-exported rather than edited here.
Package of agent tooling gated by a permission boundary, illustrating the foundryx-plugin scope
That matters for how you read the repo. It is a distribution channel, not the product. The public repository, per its own README, includes no credentials, tenant inventory, native connection definitions or CLI installation packages. If you were hoping to read the agent-deployment logic itself, you will not find it here.
What the /foundry-agent skill tells the agent to do #
The skill file is the most informative part. It instructs the agent to use the foundryx CLI instead of az, azd, or the microsoft-foundry skill, and it lays out a workflow:
- Check auth first. Run
foundryx auth statusbefore any project or agent command, and usefoundryx auth login(optionally with a tenant) while letting the human finish the interactive sign-in. - Create or select a project. Check permissions, list subscriptions and regions, check initial model quota, then create the project.
- Pick a model deployment. List the catalog, check quota, deploy or scale a model and smoke-test it.
- Build the agent. Initialize a
foundryx.yamlfrom a sample (basic,toolsortoolbox), test hosted agents locally withagent run, then deploy and invoke. - Operate and measure. Read logs, run trace queries in KQL, pull operational metrics, and run a five-step
eval.yamlevaluation flow. - Publish, only on request. Publishing an existing ready agent to Microsoft 365 or Teams is separate from deployment.
The command surface listed in the skill covers auth, access, model, agent, connection and toolbox groups, plus foundryx-canvas. If you have followed Microsoft's Foundry naming changes, note that this maps to Foundry Agent Service concepts such as hosted agents and toolboxes, but with its own CLI and config file name.
Safety rules baked into the skill #
For an agent that can create cloud resources, the guardrails are the interesting design choice. The skill tells the model to:
- never infer, request, print or store credentials, tokens or headers, and to pipe secrets through protected stdin;
- never publish automatically after an ordinary deployment;
- not invent tools, connections or toolboxes, and use them only when the user asks;
- treat tool and connection management as an explicit, separate request, because all non-delete writes need Project Owner membership and writes run immediately with no dry run, so it must get user approval first;
- not change memberships or go hunting for Azure credentials to get around a permission error;
- report missing resources to an administrator instead of creating or repairing them;
- after an ambiguous upstream failure, inspect the resource before retrying, and remember that discovery shows configuration, not proof that credentials work.
The README adds that Project Users and Managers can discover and reuse configured connections and toolboxes, while writes require effective Project Owner membership even for subscription administrators, and that per-user tool consent is a manual step.
These are the same instincts security teams want from any coding agent with cloud access: least privilege, explicit approval for writes, no credential handling by the model. For a broader treatment of why agents with deploy rights need these limits, see our guide to secure agent skills and registries.
The Agent canvas: a side panel for deployed agents #
The second component is the FoundryX Agent canvas. Ask Copilot to open it and you get a graphical list of deployed agents. The README says it shares the CLI account and credential cache, so signing out in either place signs you out of both, and that opening it does not publish or modify an agent. It needs the GitHub Copilot App with canvas extension support; the skill itself also works in a compatible Copilot CLI session, and installing the skill does not turn on canvas features in hosts that lack them.
This is separate from, but clearly related to, the Foundry Canvas that innfactory describes: a Copilot App extension that lets you design, configure, test and deploy Foundry hosted agents from a side panel, built on the microsoft-foundry plugin and azd commands. That page notes that preview items come without a service-level agreement and are not recommended for production. FoundryX Canvas appears to be the sibling for the FoundryX path, with the CLI swapped in.
How to try it #
Per the README, the recommended route is the Copilot plugin marketplace:
copilot plugin marketplace add microsoft/foundryx-plugin
copilot plugin install foundry-agent@foundryx
copilot plugin list
A direct copilot plugin install microsoft/foundryx-plugin also works but triggers a deprecation warning. In VS Code, run Chat: Install Plugin From Source with the repo URL, or Chat: Add Plugin Marketplace with microsoft/foundryx-plugin and install foundry-agent. Start a new Copilot session afterwards. Local checkouts are cached, so reinstall after editing them.
Before using it:
- Uninstall any other copy of
foundry-agent, and disable a separately installedfoundry-canvasextension. Themicrosoft-foundryplugin itself can stay. - Install the
foundryxCLI only if it is missing; choose a release matching your environment, OS and architecture, prereleases included. Standalone binaries need no Node.js. - On Linux, sign-in needs
libsecret-1and a running Secret Service keyring. - Keep the CLI service profile for the FoundryX environment you mean to use. The plugin selects no environment.
- Verify with
foundryx --versionandfoundryx auth status.
Plugin updates do not update the CLI, and a repository setup alone does not publish binaries, so confirm a matching CLI release actually exists before pointing a team at this.
What we could not confirm #
Be careful with what you read into this repo. Our checks found:
- No official announcement. We found no Microsoft blog post, docs page or press note describing FoundryX itself. A search for the name returned only the older Foundry agent tooling, such as theAzure Developer CLI extension for Foundry agents , which is a different path.
- Unclear access. The skill is for users "in a tenant already onboarded to FoundryX". Whether that is an internal, staging or limited-preview program is not stated. The release workflow in the README defaults to a
stagingenvironment. - No pricing. Costs are described only as "can incur costs".
- Very new. The repo was created at 02:23 UTC and pushed again about half an hour later, so contents may change quickly.
That is why we frame this as a first look at a release, not a verdict.
How it fits with Microsoft's other agent moves #
Microsoft has been busy on the agent side this month. The company outlined local-plus-cloud agent patterns for Windows, cut cost per answer with model routing and prompt caching on Azure, and priced a fast decision model on Foundry. The foundryx-plugin is the tooling layer: it lets the same coding agent a developer already uses stand up the infrastructure those models run on.
For readers studying the platform, the AI-103 exam guide covers the Foundry concepts (agents, tools, evaluations) that this CLI manipulates. And if you are comparing skill-based workflows, the Superpowers framework shows how a skills layer can structure a coding agent, while our explainer on agent skills covers the format that SKILL.md files like this one follow.
Deploying an agent with one button to the cloud, the step the foundry-agent skill automates
What this means for what you build #
If you build on Foundry, the practical takeaways are:
- Skills are becoming the install surface for cloud platforms. Instead of reading a CLI manual, you hand an agent a skill that encodes the flow and the safety rules. Expect more vendors to ship this way.
- Write permissions are the choke point. Because the skill refuses to invent connections and defers writes to Project Owners, an agent run is only as capable as the human role behind it. Check who owns your projects before you let an agent loose.
- Costs are real. An agent that can deploy a model and invoke it in a loop can spend money fast. Set quotas and review what
agent deployandevalactually run. - Wait for docs if you are not onboarded. Without a FoundryX tenant, the plugin cannot do much; the established
microsoft-foundryplugin andazdpath is the documented one today.
Frequently asked questions #
What is the Microsoft foundryx-plugin? A Copilot plugin with the /foundry-agent skill and a preview canvas, version 0.7.1, that drives Foundry projects through the foundryx CLI.
How do I install it? Add the marketplace with copilot plugin marketplace add microsoft/foundryx-plugin, install foundry-agent@foundryx, then start a new session.
Does it bundle the CLI? No, and it does not sign you in or grant permissions.
Is it the same as the microsoft-foundry plugin? No, it leaves that plugin untouched.
Does deployment publish to Teams? No. Publishing is a separate step.
Related reading #
Details reflect the repository as of October 27, 2026 and may change; the project is new and in preview.