The Microsoft Copilot harness runs free for 27 more days, and on December 1 you start paying for a preview that has no SLA and that Microsoft does not recommend for production. Test it now on a throwaway agent with Shell turned off. Keep it out of production until you know who approves its built-in tools, how the sandbox meter behaves while an agent waits, and how you would leave. If you need generally available terms today, the closest options are a Foundry hosted agent or the AWS AgentCore harness.
Microsoft announced the harness in Foundry on October 28. An agent harness is the orchestration layer around a model: the instructions, context, execution environment and controls that let it finish multi-step work. GitHub's engineers built this one, and Microsoft says it runs Copilot Code, Copilot Studio, the GitHub Copilot app, the CLI and VS Code. Foundry customers can now rent it instead of building their own.
What Microsoft Put in Foundry
The harness is an optional managed runtime for prompt agents, and you pick it when you create the agent. Microsoft's implementation guide, updated October 29, says Foundry operates the harness and its sandbox while your resource stays a prompt agent called through the Responses API. You supply the model, instructions, skills and tools. There is no harness code for you to deploy or patch.
New agents get five built-in tools: file read, file write, shell, web fetch and subagents. All five are on unless you configure them. Each conversation gets its own workspace, which survives normal sandbox idling and replacement but is not a durable store, so outputs you care about belong in Foundry Files or another service.
Two details tell you how early this is. The configuration value is literally microsoft_copilot_preview, and azd users must set AZD_ALPHA_ENABLE_AGENTS_MANAGED_HARNESS=true in every new shell or CI job. The guide also carries the standard warning: the preview comes "without a service-level agreement, and Microsoft doesn't recommend it for production workloads."
The choice cannot be undone on an existing agent. The guide says the harness selection is fixed during the initial public preview, and creating another agent version does not change it. Moving onto or off the harness means creating a new agent, and every caller has to move with it.
Availability is also narrower than the rest of Foundry. Microsoft's limits page lists nine regions: Australia East, Canada Central, Central US, Germany West Central, Japan East, Sweden Central, UK South, West Europe and West US. East US and East US 2 are absent, while hosted agents run in both. If your data residency plan assumes either region, stop here and re-plan.
Microsoft Sets the Approval Policy for Its Own Five Tools
During preview, your team cannot set approval rules on the harness's built-in tools. The guide is explicit: "During public preview, the service manages the approval policy for harness tools." The require_approval setting you may already use applies to customer-configured MCP tools only. The guide does not say what the managed policy allows or denies, so your security review has nothing to read.
You do have an on/off switch for each tool, and it matters. A microsoft_copilot_toolset_preview block can disable everything by default and enable exceptions one at a time. Be careful with partial settings, because Microsoft warns that Shell is the broadest tool and that disabling file read, file write or web while leaving Shell on "isn't a strict security boundary." A separately declared shell or Code Interpreter tool also ignores these settings.
Network egress controls exist too, and they are also in preview. You attach a Responsible AI policy with host rules, starting in Audit mode. A running sandbox does not reload policy edits, so you have to start a new conversation before testing a changed rule. Microsoft also warns that a separate egress decision span might not appear in the response trace, which means you verify the block directly with a test request. If you are unsure why that matters, read how Cohere caught an open-weight agent attempting an outbound upload.
If an action needs a human, the workable pattern today is a function tool. Function tools run in your application, so your code decides whether to proceed, and an MCP server can be set to require_approval: always. Neither covers Shell, which is the reason to leave Shell off unless the workflow cannot run without it.
Futurum's November 3 analysis reached the same place, recommending that platform teams start with shell disabled and that CIOs make approval control a procurement condition. The AgentCore harness has an allowedTools list, and its lifecycle hooks let a Lambda function deny a tool call before it runs, with the model-generated input in hand. AWS's defaults are just as open, with shell and file tools available in every session unless you restrict them, but you can write the rule yourself.
What the December 1 Meter Will Cost You
From December 1, sandbox compute costs $0.0994 per vCPU-hour and memory $0.0118 per GiB-hour, on top of model inference and separately billed tools. Microsoft notes prices may vary by region and agreement. Inference is already charged today, so the free window covers only the runtime.
Those are the same figures as the Hosted vCPU and Hosted Memory meters in Microsoft's retail price list, effective February 1, 2026. When we queried that list on November 4, no meter carried the word harness. The Foundry pricing page did not mention the harness either, and it says there is "no additional charge" for running Foundry-native prompt agents. So selecting the harness moves a prompt agent from no runtime fee to a metered sandbox.
The hard part is sizing. The limits page says the sandbox's "CPU, memory, and lifecycle settings aren't customer-configurable," and Microsoft publishes no size, so you cannot compute a bill from the rate card alone. Hosted agents let you choose 0.5, 1 or 2 vCPU and set an idle timeout. On the harness, Foundry decides.
Here is our own estimate, using a size Microsoft has not confirmed. At 1 vCPU and 2 GiB, the sandbox costs $0.123 per hour. An agent handling 10,000 sessions a month, each holding a sandbox for 15 minutes, comes to 2,500 hours and about $308. At 2 vCPU and 4 GiB it is about $615. Neither figure includes model tokens, which will usually be the larger number.
Microsoft's post calls the pricing "consumption-based" and does not say whether the vCPU meter stops while an agent waits on a model. That rule can flip your vendor choice. Our October 31 comparison priced a 10-minute job at 1 vCPU and 2 GB with 30 seconds of real CPU at about $0.0078 on AgentCore Runtime v2. At the harness rates, the same 10 minutes costs about $0.0205 if every minute meters, roughly 2.6 times as much. If Microsoft bills active CPU only, that gap shrinks sharply. Ask before you size anything. Ask AWS too: that $0.0078 uses Runtime v2 rates, while AWS's harness docs and CreateHarness API name no platform version, and Runtime itself defaults to v1.
AWS is no cure for bill surprises. The AgentCore harness has no separate charge, but a Classmethod engineer's July test ran up $5.63 in 29 minutes, $5.36 of it runtime memory, after parallel invocations scaled out sessions. That bill works out to the v1 rates and predates Runtime v2. The author also found no way to set memory size on the AWS harness.
Your cost controls are thinner on Microsoft's side for now. The limits page says max_output_tokens, max_tool_calls and prompt_cache_key are harness-managed on response requests, and sending them returns an error. A FinOps team that caps runaway agents with those fields will need to do it elsewhere, such as at the model deployment's quota.
Watch for one naming trap in your budget. CRN reports that from November 2, Copilot Business licenses sold through CSPs default to usage-based billing, metered in Copilot Credits at 1 cent each, for eligible services including "GitHub Copilot Harness in Copilot Studio." That is a separate meter on a separate product from the Foundry sandbox rates above.
The Multi-Model Claim Narrows Inside Foundry
Microsoft's headline says "truly multi-model," and inside Foundry your choice is limited to models Foundry can serve. The launch post promises 20+ frontier models plus bring your own key. The implementation guide says bring your own model isn't currently supported with the harness, and that page defines the feature as models behind your own gateway, such as Azure API Management. The agent's model must support reasoning and tool calling and be available to prompt agents in your region.
The two statements appear to describe different products. The GitHub Copilot SDK, which you run yourself, does support bring your own key, though only with key-based authentication: its README says Entra ID and managed identities are not supported there. That reconciliation is our reading, since Microsoft's post does not separate them. If your plan routes every model call through an API Management gateway for logging and spend limits, the Foundry harness cannot join that path today.
The SDK is also the route that keeps approvals in your hands, because its README says tool execution is "governed by each SDK's permission handler." You give up the managed sandbox to get that, and usage counts against a Copilot allowance per prompt. Other Foundry limits to check against your design: Foundry Memory is not available on the harness, and function tools cannot use strict: true.
AWS is broader here. Its harness docs list Bedrock, OpenAI, Gemini and any LiteLLM-compatible provider, with provider switches mid-session.
The Published Numbers Measure GitHub Copilot, Not Your Foundry Agent
The strongest case for Microsoft is the evidence behind the runtime, and it is real, with limits on how far it travels. Artificial Analysis's Coding Agent Index v2.0, read on November 4, scores GitHub Copilot with Copilot Fusion at 60 against 62 for Claude Code with Opus 5.5. Copilot costs $5.59 per task against $11.42 and uses 7.3 million tokens against 14.5 million. Half the cost for two points of index is a good result, and harness design can move rankings more than the model does.
That test covers coding tasks through GitHub Copilot, using its Fusion routing. It says nothing about a claims or procurement agent on Foundry models under a Foundry sandbox. Fusion is a GitHub Copilot feature, so check whether your Foundry agent gets that routing at all.
The Rust claim has the same shape. GitHub's engineering post shows a client, session and one turn falling from 5.25 seconds to 1.33 seconds out of process and 292 milliseconds in process, though the post's text and chart give about 55 milliseconds for that in-process case without explaining the gap. Those runs hit a deterministic local server, which removes inference and network latency, and the author says other changes landed in the same period. They were run through the C# SDK by the vendor. The same post concedes that serialization overhead is "generally small potatoes" next to the model round trip for inference-heavy work. Your agent spends most of its turn in that round trip.
Microsoft's launch posts give no GA date. The Foundry post quotes two customers, Confluence Technologies and Fashable, and Futurum notes they describe a first build and plans, not production results. Futurum asks for customer results before December 1, and you should expect to generate your own.
Copilot Harness vs Hosted Agents vs AgentCore
Pick by what you must own. Use the harness to evaluate; use a hosted agent if you need to control the loop on Azure under GA terms; use AgentCore if you are not tied to Azure and want the exit path now.
| Copilot harness (Foundry) | Hosted agent (Foundry) | AgentCore harness (AWS) | |
|---|---|---|---|
| Status, November 4, 2026 | Public preview, no SLA | GA since July 9 | GA since June 17 |
| Who writes the loop | Microsoft | You, in any framework such as LangGraph | AWS, configured by you |
| Built-in tool approval | Microsoft-managed; on/off per tool | Your code | allowedTools plus Lambda deny hooks |
| Sandbox size | Not configurable, not published | 0.5, 1 or 2 vCPU, your choice | Not settable, per Classmethod's test |
| Runtime rate | $0.0994 vCPU-hour, $0.0118 GiB-hour | Same on the retail list | Runtime v1: $0.0895 vCPU-hour, $0.00945 GB-hour. Runtime v2: $0.1276 and $0.0169. AWS does not say which a harness uses |
| Bring your own gateway or provider | No | Models from the Foundry catalog; your code owns the rest | Any LiteLLM-compatible provider |
| Exit path | None documented, per Futurum | Your container is your exit | One-command export to Python Strands |
| Who should not pick it | Anyone with a production date before GA | Teams without the staff to run agent code | Azure-committed shops with no AWS footprint |
The AWS export deserves a caveat of its own. It generates editable Strands code and records what it could not map in EXPORT_NOTES.md, and AWS's docs say it omits Gateway, Browser and Code Interpreter tools and AWS skills. Treat it as a head start on a rewrite. Futurum's review of Microsoft's documentation as of October 29 found no equivalent export path, so on the harness your portable assets are skills in the Agent Skills format and your MCP servers. That standard now travels between vendors, which limits the damage. For the wider commercial question, read how your cloud commit shapes the platform choice and our exit-focused scoring framework.
What to Do Before December 1
This Week:
- Create one throwaway agent in Microsoft Foundry, in a supported region, with
defaultConfig: enabled: falseand onlyfilesystem_readswitched on. Add tools one at a time and record what each one was needed for. - Give your security lead the guide's approval sentence and its Shell warning, then get a yes or no on paper on whether a default-on Shell under a Microsoft-managed policy passes your review.
- Attach an egress policy in Audit mode and run your real workflow for a few days. The log tells you which hosts to allow before you switch to Enforce.
- Send your account team four written questions: what the harness approval policy allows, whether the vCPU meter runs while an agent waits on a model, what size the sandbox is, and when harness switching or export arrives.
Before December 1:
- Run the same workflow on the harness and as a hosted agent, as Futurum recommends, and compare accepted results, human interventions and cost at the December rates.
- Inventory every harness agent created during the free window and name an owner for each. Delete the ones nobody will pay for. Microsoft Ignite runs November 17 to 20, so re-read the guide and the limits page the week after, because either could change terms 11 days before billing.
- Write skills in the portable format and keep MCP servers outside anything Foundry-specific. Expect Foundry connections and approval settings to need reconfiguring if you move.
Before Any Production Date:
- Make approval control over built-in tools and a documented exit path written conditions of the deal, and do not ship on the harness while its status still reads preview.
The Bottom Line
Renting the agent loop is a sound default for most teams, for the same reason few of them run their own Kubernetes control plane. The harness is a credible candidate, and GitHub Copilot gives it more mileage than most new runtimes get. AWS shipped its GA version about four months earlier, and Amazon Bedrock buyers already have the deny hook and the export command. Microsoft has published a price for its harness and no GA date.
Get the approval policy, the idle-billing rule and the exit path from Microsoft in writing before November 30.
Continue Reading
- Google Agent Runtime's $510 Meter Beats AgentCore's $846
- Your Bake-Off Ranked Harnesses, Not Models. Re-Run It.
- Agent Orchestration Platforms: Score Exit, Not Features
- E2B vs Modal vs Daytona: Idle Time Sets Sandbox Bills
- Agent Authorization: Standing Privilege Is the Whole Problem
- Bedrock vs Vertex AI vs Foundry: Your Cloud Commit Decides