Microsoft published a short post on the Microsoft 365 Copilot Blog on September 4 confirming that OpenAI’s GPT-6 Astra is rolling out in Copilot Cowork and Copilot Studio. The post runs to about four sentences. It notes that availability varies by region and organization, that admins can manage access through the Microsoft 365 admin center, and that the Roadmap and release notes carry the rollout detail.
Four sentences is a reasonable length for a model availability notice. It is a poor length for what this particular model actually asks of an administrator. Astra is not a quality bump on the same shape of workload. It is a model built for long-horizon, multi-step execution across applications, including applications reached through their user interface rather than an API. That changes what a Copilot Studio agent can do on a bad day, and it changes what your governance model has to be able to prove afterward.
Here is what shipped, where the control points sit, and what belongs on an admin’s list this week.
What actually shipped
Charles Lamanna, EVP of Microsoft Copilot, framed this as a day one release across four surfaces: Microsoft Copilot, Copilot Studio, GitHub Copilot, and Microsoft Foundry. Each surface has its own availability story and its own admin control, and they do not line up neatly.
- Copilot Cowork and Copilot Studio. Astra joins the existing set of frontier models available for selection. Rollout is gradual and varies by region and tenant.
- GitHub Copilot. Generally available for Copilot Pro+, Max, Business, and Enterprise across VS Code, Visual Studio, JetBrains, Xcode, Eclipse, the CLI, the coding agent, GitHub.com, and GitHub Mobile. Billed at provider list pricing under usage-based billing.
- Microsoft Foundry. Generally available for all customers, with Standard and Provisioned Throughput deployment options across Global and US Data Zone geographies.
- ChatGPT and the OpenAI API. Available to Pro, Enterprise, and Business Premium users in ChatGPT Work and Codex, with Plus and standard Business following within days. OpenAI states that enterprise administrators enable Astra for their workspace and that access is off by default at launch.
That last detail is worth holding onto. OpenAI shipped Astra off by default for enterprise workspaces. Microsoft’s surfaces do not all inherit that posture, and the difference is where the governance work lives.
Why this release is not the same as the last one
The Microsoft Foundry announcement is more candid than the Copilot one, and it is the better read for anyone writing policy. It describes Astra as built to take an open-ended challenge, reason through it in multiple steps, create a plan, and produce a finished result. It describes computer-use capability that interprets on-screen information and interacts with approved interfaces to update records, navigate development tools, test software, and assemble reports.
Then it says the part that matters most. Capability this direct demands containment. Content displayed in an application may be incomplete, misleading, or designed to influence an agent’s behavior.
That is Microsoft naming prompt injection through the user interface as a first-class risk in a product launch post. If you have been following the agent security work of the last year, this is the same class of problem as tool poisoning, moved from the tool description into the rendered screen. A Copilot Studio agent using computer use does not have a connector boundary in the way a Dataverse or SharePoint action does. It has whatever is on the screen.
The distinction is not academic. Most Power Platform governance programs were built around a model that answers. The controls reflect that: DLP policies classifying connectors, sensitivity labels on grounding data, environment routing so makers land somewhere appropriate. Those controls are still necessary. They are no longer sufficient once the model is the thing taking the action.
Where access is actually controlled
Microsoft’s post says admins can manage access through the Microsoft 365 admin center. True, and incomplete. For Copilot Studio specifically, there are several layers between an OpenAI release and a maker picking Astra in the model dropdown, and they are administered by different teams in most organizations.
Tenant level
The Microsoft 365 admin center holds the provider-level switches under Copilot and Settings. Two are relevant. The first is the OpenAI subprocessor setting introduced with message center post MC1422074 in July, which governs OpenAI-operated models and which auto-enabled on July 24 for tenants that took no action. The second is the set of controls governing Copilot Frontier and external model providers.
If your organization never reviewed the subprocessor setting, it is on. That was the designed behavior, and it was communicated. It is still worth confirming rather than assuming, because it determines whether an OpenAI-operated model can serve your tenant at all.
Environment level
The Power Platform admin center carries the environment-scoped switches under Manage, Environments, Settings, Product, and Features. Historically this is where preview and experimental AI models and external models are enabled or withheld per environment. Microsoft Learn documents these as separate sets that can overlap: an admin can block external models while allowing preview and experimental ones, or the reverse.
This layer is the one most worth using well. It is the only place where you can give a sandbox environment access to a new frontier model while production stays on a model you have already evaluated. If your environment strategy already distinguishes exploration from production, you have the structure. Use it here.
Agent level
Inside Copilot Studio, model selection happens twice: once for the agent’s primary model, and again at any prompt node that specifies its own model. Both are bounded by what the two layers above permit. An agent inventory that records only which agents exist is no longer enough. It needs to record which model each agent runs on, because that is now a variable that changes cost, behavior, and risk profile without the agent’s logic changing at all.
Runtime
Everything above decides whether Astra can be selected. None of it decides what happens when an agent running Astra encounters a screen containing instructions aimed at it. That is DLP and connector policy, scoped credentials, approved resource lists, human checkpoints on consequential steps, and log retention sufficient to reconstruct a run.
Which specific toggle governs Astra in your tenant is the thing to confirm before you write policy language. Model availability settings in Copilot Studio have been renamed and restructured repeatedly over the past year, and a policy document that names a setting incorrectly is worse than one that describes the intent and points at the admin center.
The safety context that did not make the Copilot post
Two items from OpenAI’s own materials belong in any serious evaluation, and neither appears in the Microsoft 365 Copilot announcement.
First, OpenAI stated in a September 1 update that it assesses Astra as meeting the Critical cybersecurity capability threshold under its Preparedness Framework. This is the first model OpenAI has designated at that level. The practical meaning, in OpenAI’s framing, is that with sufficient tooling and access the model can find previously unknown security flaws and develop ways to exploit them against well-defended systems without step-by-step human direction. OpenAI has correspondingly limited access to its most advanced cybersecurity capabilities.
Second, Astra uses a reasoning approach OpenAI calls recurrent depth, which obscures some or all of the model’s chain of thought. Reporting on the launch has noted that this has drawn concern about monitorability. For an enterprise, the question is narrow and answerable: if your assurance model relied on inspecting reasoning traces to explain an agent’s behavior, confirm whether that inspection still returns what you need on this model before you route regulated workloads to it.
Neither point is a reason to withhold the model. Both are reasons to write down what you tested and when.
The cost picture
Astra is metered differently on every surface it landed on, which makes tenant-wide forecasting harder than the announcement suggests. Copilot Studio usage draws on Copilot Credits. GitHub Copilot bills at provider list pricing under usage-based billing. Foundry bills per token, published as follows.
| Deployment | Context | Input | Cached input | Cached writes | Output |
|---|---|---|---|---|---|
| Standard Global | Short | $10.00 | $1.00 | $12.50 | $50.00 |
| Standard Global | Long | $20.00 | $2.00 | $25.00 | $75.00 |
| Standard Data Zone (US) | Short | $11.00 | $1.10 | $13.75 | $55.00 |
| Standard Data Zone (US) | Long | $22.00 | $2.20 | $27.50 | $82.50 |
Microsoft states that Astra is designed for token efficiency on complex work, and OpenAI reports meaningfully lower latency per task than the previous generation. Both may be true and still leave you spending more, because agentic workloads consume tokens in a different pattern than assistive ones. A single long-horizon run that plans, executes, verifies, and retries is not comparable to a single chat turn. If you are modeling this, model the run, not the message.
A first-week checklist
- Confirm the current state of the OpenAI subprocessor setting in the Microsoft 365 admin center, and record who owns it.
- Review model availability settings per environment in the Power Platform admin center. Decide deliberately which environments may select Astra rather than inheriting whatever the default is.
- Check whether GitHub Copilot default model enablement is on in your organization. New models enable automatically there unless an administrator has turned off the global default, which is a different posture from the one OpenAI applies to ChatGPT workspaces.
- Extend your agent inventory to record the model behind each agent and each prompt node.
- Identify every agent using computer use. These are the ones where model capability translates directly into action on systems of record, and they need review first.
- Confirm which identity agentic runs execute under, and whether that identity’s permissions are scoped to the task or inherited from a maker.
- Define human checkpoints for consequential actions before an agent gets the capability, not after an incident.
- Verify that your logging captures which model handled which run and what changed as a result. This gets much harder to retrofit at volume.
- Set a cost baseline now, before Astra usage is mixed into your existing Copilot Credit consumption.
- Write down what you evaluated and when. Model-level assurance is going to be asked about, and reconstructing it later is expensive.
The pattern worth noticing
Model releases now reach production tenants faster than governance cycles run. Astra went from OpenAI announcement to general availability in Copilot Studio, GitHub Copilot, and Foundry inside roughly forty-eight hours. That cadence is not going to slow down, and building a review process that assumes it will is building the wrong process.
The organizations that handle this well will not be the ones that evaluate every model. They will be the ones whose environment strategy already separates where new capability is allowed to land from where the business runs, so that a day-one release is a controlled experiment somewhere specific rather than a tenant-wide event nobody decided on. That structure is the same one the Power Platform administration guidance has been pointing at for years. This release is a good reason to check whether yours actually works.
Sources
- Available today: OpenAI GPT-6 Astra in Microsoft Copilot, Microsoft 365 Copilot Blog
- GPT-6 Astra: Frontier intelligence for work, now generally available in Microsoft Foundry, Microsoft Azure Blog
- GPT-6 Astra is generally available in GitHub Copilot, GitHub Changelog
- GPT-6 Astra: A new generation of intelligence, OpenAI
- Select a model for an agent, Microsoft Learn