The operational question is no longer whether an AI agent can complete a workflow. It is whether the organisation can bound its access, verify its output and stop it safely when it is wrong. The arrival of longer-running, connected work agents makes those controls a prerequisite for scale—not a clean-up task after a pilot.
What changed: connected work is becoming a product surface
OpenAI introduced ChatGPT Work on 9 July as an agent for longer tasks that can research, analyse connected apps and files, create documents and run scheduled or change-triggered tasks. Its Enterprise and Edu preview is off by default, while important actions can require user approval. The same release introduced public publishing for lightweight Sites, although that publishing capability was not available in the EEA, Switzerland or the UK at launch. OpenAI’s Enterprise release notes are the primary record for these capabilities and rollout conditions.
This matters because the risk boundary has shifted. A chat answer normally ends at a human reader. A connected agent can ingest proprietary context, traverse tools and produce an artefact or an external action. A useful-looking result is not evidence that the retrieval scope, tool permissions, action path and audit trail were appropriate.
Why a workflow needs an operating boundary
An operating boundary is a deliberately narrow contract: one business outcome, named input sources, approved tools, permitted actions, a maximum run time or spend, an accountable owner and a defined escalation route. It separates “the model can try this” from “the organisation permits this in production.”
This is not vendor-specific. Microsoft documents comparable controls for Copilot Studio: data policies can govern knowledge sources, actions, connectors, skills, HTTP requests, triggers and publishing; administrators can use audit logs and data-loss-prevention controls. Microsoft’s security and governance documentation makes the relevant implementation point clear: governance has to cover the agent’s connections and actions, not merely the model setting.
For European organisations, this also creates evidence that is useful when assessing a deployment under the EU AI Act’s risk-based framework. The regulation is not a generic checklist for every assistant, and classification needs legal and factual review. But a documented purpose, permissions, human responsibilities, logs and change history are practical engineering inputs to that assessment. See the European Commission’s AI Act overview for the risk-based framework; it is not legal advice.
The production trade-offs are operational, not cosmetic
Broad connectors reduce integration work, but they enlarge the blast radius of an incorrect instruction or compromised account. Autonomous scheduling removes routine work, but it can execute during an incident window when nobody is watching. Publishing a generated internal site can improve access to a report, but changes the data-distribution question. The right control is not always human approval: for a low-impact read-only reconciliation, a hard permission boundary and sampled review may be better. For payment, customer communication, production configuration or sensitive HR decisions, an explicit approval gate should be non-negotiable.
Cost needs the same treatment. Token price is only one component. OpenAI’s investment guidance recommends measuring cost per accepted outcome, including attempts, completion rate, latency and human review. That is a sound production metric: a cheaper model that retries, produces untraceable work or triggers rework is not cheaper in the operating model.
A practical control set for the first deployment
Start with a read-only workflow that has a stable input schema and a measurable accepted outcome—for example, reconciling a daily operations report against approved source systems. Give the agent a service identity with the minimum required scopes; do not pass a user’s broad session by default. Keep write actions behind a separate approval service or queue rather than granting a general-purpose browser or API tool.
Before expanding scope, require five pieces of evidence: a representative evaluation set including failure cases; a log of retrieved sources and tool calls; an owner for each connected system; a kill switch tested outside a tabletop exercise; and a review of data location, retention and supplier terms. The implementation patterns in this guide to enterprise controls for faster agents, human approval and audit evidence and production agent evaluation provide useful starting points.
The decision: scale a controlled workflow, not an agent brand
Procurement teams should ask for the control plane before approving a new agent capability: which identities act, which data can cross the boundary, which actions need approval, where is the evidence, and how quickly can access be revoked? If the vendor cannot answer those questions precisely, the pilot is not ready for broader enterprise data.
The near-term opportunity is real: connected agents can remove structured, repetitive coordination work. The durable advantage, however, will go to organisations that make each capability observable, reversible and accountable before giving it more autonomy.
Sources
OpenAI: ChatGPT Enterprise & Edu release notes.
OpenAI: How to manage AI investments in the agentic era.
Microsoft: Copilot Studio security and governance.
European Commission: AI Act.
