JetBrains launched Air on September 22, 2026, and built the whole release around one line from JetBrains' announcement of Air: "As agents take on more of the execution, the bottleneck shifts from producing change to understanding, verifying, and owning it." Everything else in the launch hangs off that sentence. If your team already runs GitHub Copilot or GitLab Duo permissions, JetBrains Air is pitching a different question: who's watching every agent across every tool, not just the one JetBrains sells.
What JetBrains announced on September 22, 2026
JetBrains describes Air as "an open, coherent system of products for developers, teams, and organizations, inside and beyond JetBrains IDEs." In practice that means three separate products shipped together, rather than one feature inside IntelliJ or PyCharm: Air in JetBrains IDEs, Air Teams, and Air Governance, the last of which used to be called JetBrains Central.
Air in JetBrains IDEs, Air Teams, and Air Governance
Air in the IDE
This is the layer developers actually touch day to day: directing an agent on a task inside the editor and verifying what it produced before it merges. It's the closest of the three to what a Copilot or Cursor user already does, agent output reviewed in the same window where the code lives.
Air Teams
Air Teams moves the work out of a single developer's machine and into shared cloud environments. It automates repetitive tasks, code review, release notes, routine fixes, and gives each project a dedicated environment with configurable VM size and internet access controls. It also centralizes MCP server connections, so a team isn't wiring the same tool integration into five different agents separately. That last detail is what the product page lists under Air Teams, and it's the piece most likely to save real engineering time, since MCP setup sprawl is exactly the kind of thing nobody notices until three people have reinvented it.
Air Governance (formerly JetBrains Central)
Governance is the part this article is actually about. JetBrains describes its scope as "organizational policy, visibility, auditability, cost management, and accountability for AI-assisted and agent-driven development." Concretely, that means role-based permissions and model access policies that an org can tailor by organization, team, or individual, plus an audit trail and cost attribution sitting underneath. The rename from JetBrains Central to Air Governance isn't cosmetic. It signals JetBrains wants this treated as the control plane for the whole Air system, not a settings page someone finds later.
Which agents Air runs
Air isn't limited to JetBrains' own agent. It connects through the Agent Client Protocol (ACP), a standard for wiring an IDE to an agent regardless of who built it. The September 22 announcement names only Junie, JetBrains' own agent and optional rather than required, and otherwise describes multi-vendor support in general terms through ACP rather than naming other agents. The actual roster shows up on the product page: Claude Agent, Codex, Junie, GitHub Copilot, and OpenCode, plus a note that any ACP-compatible agent works.
What changes for a team already running Copilot or GitLab Duo permissions
Whether Air Governance matters to your team depends on what you're already running. HighCircl has covered two single-vendor answers to the agent-permission question already, in the AI in the engineering workflow: tools, permissions and policy hub. Both are worth knowing before you decide whether Air Governance is solving a problem you have.
GitHub ships Copilot's own deny, ask, allow permission model, enforced at the admin level and unable to be weakened by a developer's local settings. GitLab, in the same window, shipped its own default for read-only versus write-and-delete tool access. Both are real, working controls. Both also govern one vendor's tools only. A developer running Copilot on one repo and GitLab Duo on another is subject to two separate permission systems that don't talk to each other, with no shared audit trail across them.
That's the gap Air Governance is pitched at closing, at least on paper: policy, visibility, and cost tracking that sits above whichever agent a developer actually picks, rather than one more permission screen scoped to a single vendor's product. It's the same fragmentation problem that shows up in JetBrains' own adoption data on how fast developers are switching tools: a team running three different assistants across three teams doesn't have one permission policy to audit. It has three, and Copilot's and GitLab Duo's controls, the ones covered above, only ever govern the agent each vendor ships itself. Air Governance is pitched as the one that doesn't stop at a single vendor's agent.
Worth being honest about what JetBrains hasn't published, because a buyer evaluating this against Copilot or GitLab Duo will hit these gaps fast. There's no pricing anywhere on the Air pages. There's no worked example of what an actual Air Governance policy looks like, the kind of concrete deny-ask-allow walkthrough GitHub published for its own permissions. There's also no committed general-availability date, just a rollout described as gradual. A cross-vendor governance pitch is a stronger claim than a single-vendor permission screen, and stronger claims need more evidence before a team should act on them, not less.
It's also the same instinct behind the gate-before-enabling logic HighCircl argued for with Cursor's own Rollouts and Security Review bots: before you extend trust to an automation layer, know exactly what it's allowed to touch and who signed off on it. Air Governance is pitching itself as the place to answer that question once, across vendors, instead of once per tool. Whether it actually delivers that in practice is still unproven.
Availability and what's still rolling out
JetBrains says cloud runs are "already available for some customers in JetBrains IDEs and the browser," with the rest of the rollout arriving "gradually over the coming months." Read that as: parts of Air are live now, in a limited release, with no committed date for when everyone gets access. That's consistent with how JetBrains rolled out an earlier, narrower version of Air on Windows in an earlier post about Air's Windows debut, back in June 2026, months before this broader three-product system existed. Don't confuse that June release with what shipped on September 22. It's an earlier chapter of the same product name, not evidence for how fast the current rollout will move.
FAQ
What is JetBrains Air?
JetBrains Air is a system of three products launched September 22, 2026: Air in JetBrains IDEs for directing and verifying agents inside the editor, Air Teams for shared cloud environments and automated repetitive tasks, and Air Governance for organization-wide policy, audit, and cost tracking across whichever agents a team runs.
What is JetBrains Air Governance, formerly JetBrains Central?
It's the control layer of Air: role-based permissions and model access policies that an org can set by organization, team, or individual, alongside an audit trail and cost attribution. JetBrains pitches it as covering AI-assisted and agent-driven development broadly, not just work done through JetBrains' own tools.
Which AI coding agents does JetBrains Air support?
Air connects to agents through the Agent Client Protocol, a vendor-agnostic standard. JetBrains' September 22 announcement names only Junie, its own agent, optional rather than required. The Air product page names the actual roster: Claude Agent, Codex, Junie, GitHub Copilot, and OpenCode, and states that any ACP-compatible agent works.
Is JetBrains Air generally available, and what does it cost?
Not fully. JetBrains says cloud runs are already available for some customers, with a gradual rollout to everyone else over the coming months and no committed general-availability date. JetBrains hasn't published pricing for Air or Air Governance anywhere in its own materials.