Cloud agents
Let team members hand tasks to a provider's cloud agent (GitHub Copilot, Cursor, Claude Code, Codex and others), and see every run.
A team member can work in the cloud: its tasks go to a provider's cloud agent instead of an agent on someone's workbench or a node. The member keeps its role and instructions. The task goes out under the person's own provider account, and the work comes back as a pull request the team reviews.
For each cloud task, your organisation:
- decides whether it may happen, by the Cloud Agents section of your policy;
- records the run: who started it, the provider, the member and task, the pull request and how it ended;
- gives the provider's agent the team's task tools (read the task, report on it, ask a person, read what the team knows) through a short-lived link that stops working when the task ends. Those calls go to the workbench that started the task, which checks them for sensitive data both ways.
Your organisation never keeps the task's text or anything a tool returned.
Cloud agents need AI Workbench signed in to your organisation. A node never sends tasks to the cloud, because a cloud task runs under a person's own provider account.
Allow cloud agents
Until a policy allows at least one provider, no workbench in your organisation places a member in the cloud.
- Open Policies and choose the policy that applies to the project, or the default one.
- Open Cloud Agents.
- Under Providers allowed, tick the providers your people may use: GitHub Copilot, Cursor, Claude Code, Codex, Jules, Devin, or Your own CI.
- Leave A person reviews cloud work before it merges on unless the team's own review is enough.
- Turn on Keys the organisation pays for only if a key your organisation holds (a Cursor service account, a Devin organisation key) may be used. Off, each person uses their own account.
- Set Cloud tasks at once, per project to cap how many run together. Leave it empty for no limit.
- Publish the policy.
In the policy document this is the cloudAgents clause:
"cloudAgents": { "allowed": ["github-copilot", "cursor"], "requireHumanReview": true, "maxConcurrent": 3 }Place a member in the cloud
In a team's configuration in Catalogue, give the member "runsOn": { "cloud": { "provider": "github-copilot" } }. A person can also choose In the cloud for a member in AI Workbench.
A published team template may place a member in the cloud. A provider is not a machine, unlike a node or a workbench, which templates may not name.
See the runs
- Activity shows a Cloud Runs panel. Administrators see every run; everyone else sees their own.
- A project's Activity tab shows its cloud runs to the project's owners, and to everyone else their own.
Each run shows the member, the provider, who started it, how long it ran, how many tool calls it made, links to the pull request and the provider's page, and how it ended: In the cloud, Handed back, Integrated, Cancelled, Failed or Expired.
Runs also appear in Audit:
cloud.run.startandcloud.run.endfor each run;cloud.run.refusedwhen the policy refused one;cloud.mcp.unauthorisedwhen something presented a wrong credential for a run.
The last two are warnings, so a connected Microsoft Sentinel receives them. With Microsoft Agent 365 connected, a finished run in a project is exported as an agent run, with the provider as its runtime and no cost.
When something is refused
| What the person sees | Why | What to do |
|---|---|---|
| The organisation's policy allows no cloud agents | No provider is allowed for the project | Allow providers under Policies, Cloud Agents |
| The policy does not allow this provider | The provider is not ticked | Tick it, or pick an allowed provider for the member |
| Already running the most the policy allows | maxConcurrent reached in the project | Wait for a run to end, or raise the limit |
| The cloud member works without live tools | The workbench is too old, or was not connected when the agent called | Update AI Workbench; keep the workbench that started the task signed in |