AI Agents Move from Models to Managed Control

Codex Becomes an API

OpenAI has turned Codex's managed agent machinery into an API, letting any developer rent the harness instead of building every moving part themselves.

That is the development worth sitting with, because the hard part of an agent is increasingly everything around the model. OpenAI released its Agents API in public beta on 10 September. It gives developers API access to the managed harness and cloud infrastructure used by Codex, rather than access to a model alone.

The distinction is practical. A useful coding agent can run for a long time, lose track of old context, call the wrong tool, stall while waiting on another task or fill its prompt with tool definitions it never needs. OpenAI's managed layer handles several of those problems. It can compact context automatically during long sessions, discover tools through tool search, call tools programmatically, connect through the Model Context Protocol and orchestrate multiple agents. Those are pieces that capable engineering teams can build, but building and operating all of them takes time.

Compaction is a good example of the value. Long jobs can outgrow a model's usable context even when the model itself is capable. A harness has to decide what history to preserve, what to compress and what a later step still needs. Tool search tackles the other side of that pressure by finding relevant capabilities instead of loading every tool definition up front. Neither feature makes the agent correct, but both address operating problems that appear once a prototype starts doing sustained work.

Developers can run work in an OpenAI-hosted sandbox, use their own infrastructure or choose an integrated sandbox partner. That choice matters when code, data residency, network access or an existing execution environment rules out a fully hosted setup. It also separates two decisions that are sometimes bundled together: who manages the agent loop and where its actions execute. The product is available to all developers. OpenAI says there's no separate fee for the Agents API, although the underlying tokens and tools still cost money. So, no new line item called "harness", but definitely no free lunch.

The immediate benefit is a shorter path from a convincing demo to an agent that can keep working across a longer job. A developer can concentrate on the job, the tools and the checks around them instead of first assembling a context manager, a tool registry and an orchestration service. The more important shift is architectural: some application behaviour now sits inside an OpenAI-managed layer that can evolve separately from the application's own code.

For a developer, that creates a real trade-off. The managed harness may remove a pile of undifferentiated plumbing, while making performance, debugging and operating cost depend more heavily on decisions made inside the service. Hosting the execution yourself doesn't remove that dependency if the planning, compaction and tool coordination still come from the API. It also doesn't set the application's permissions or decide what counts as a successful result. Those controls remain the builder's job.

My read is that agent platforms are becoming the new competitive boundary. Model quality still counts, but a system that can hold context, find the right capability and complete a job safely is far more useful than a clever model waiting for somebody else to wire it up. The caution is timing: this is a public beta. Interfaces, stability and operational guarantees may change before general availability. It is now credible infrastructure for serious experiments, but the beta label belongs in any production decision.

A Data Agent at Work

That opens the shorter run of news, and the same push towards managed action is already reaching company data.

OpenAI has launched a Data agent in ChatGPT Work. It can connect to approved company systems, investigate a question, build an interactive dashboard and carry out an action after the user approves it. The supported sources include Redshift, BigQuery, Databricks, MongoDB, Snowflake, Google Drive and SharePoint, along with links to several business-intelligence tools.

The appeal is easy to see. Somebody who understands a commercial question but doesn't write SQL can ask for an analysis across systems and work with the result conversationally. The agent can move beyond producing a chart and act on an approved conclusion. That might compress a process that currently passes from a business user to an analyst and then into another operational system. It could also let an analyst spend less time translating simple questions and more time examining the difficult ones.

Access is controlled by administrators, who choose the available connections and the roles allowed to use them. OpenAI says each query respects the connected account's table, row and column permissions. That is the right foundation, but permissions only answer who can see a field. They don't settle whether two departments mean the same thing by "active customer", whether a stale table is still trusted or whether a dashboard has joined records correctly. Approval before an action helps with control, yet the person approving still needs enough context to recognise a bad conclusion.

OpenAI included adoption and customer-result examples in its launch material. Those are company and partner claims, not an independent test of accuracy across mixed data sources. There was no independent reliability evaluation on the launch page.

For organisations, lowering the skill barrier to analysis could make useful data available to many more people. My judgement is that the successful deployments will treat semantic definitions, least-privilege access and review of consequential actions as product work from day one. If those pieces are left for cleanup, a confident conversational answer can spread a data-quality mistake faster than a difficult dashboard ever did.

Copilot Gets Enterprise Guardrails

A conversational interface is only half the job; somebody still has to decide what an agent is allowed to touch.

GitHub has made enterprise-managed permissions for Copilot agent operations generally available. Administrators using Copilot Business or Enterprise can centrally block an operation, require approval for it or pre-authorise it. The policy covers shell commands, file reads and edits, and network domains.

The enforcement hierarchy is the useful detail. A managed restriction can't be weakened by a developer's user settings, a workspace setting, auto-approval or a saved approval from an earlier session. The controls apply in the GitHub Copilot app, Copilot CLI and Visual Studio Code sessions that use Agent Host. An organisation can therefore set one boundary for a role or group rather than hoping every developer makes the same decision every time an agent asks to run a command.

That central layer also makes policy easier to review. A security owner can see whether agents used by a particular group are allowed to edit files, reach a network domain or execute a command without relying on a screenshot of somebody's local settings. Different roles can still have different boundaries, but those differences become deliberate enterprise policy.

This won't decide whether a proposed code change is sensible. It does give security and engineering owners a consistent place to stop predictable classes of action: writing outside an approved area, contacting an untrusted domain or running a command that needs a person to look first. It also reduces approval fatigue when an operation has already been assessed and can be pre-authorised centrally.

For engineering organisations, I would treat this kind of policy as part of deploying an agent, alongside repository permissions and CI controls. Autonomy without a shared boundary produces a different security posture at every desk. GitHub's release makes those boundaries enforceable across the supported Copilot surfaces, which is a much firmer base than a collection of individual preferences.

The Security Tool That Exposed Source

The next case shows why a polished agent interface can't compensate for one unsafe infrastructure assumption.

AWS has disclosed and patched two vulnerabilities in its Security Agent plug-in and MCP server. CVE-2026-87912 and CVE-2026-87913 involved missing ownership checks for an S3 bucket used during scanning. Because the bucket name was predictable, a remote attacker could register it first and receive a workspace archive intended for the scan.

That archive could contain source code, credentials and infrastructure state, according to AWS. The affected releases are the aws-agents-for-devsecops plug-in through version 1.0.0 and the Security Agent MCP server from 0.1.0 through 0.1.5. AWS recommends moving to current patched releases. The exposure could therefore cross several trust boundaries at once: application source, deployment configuration and credentials gathered into the same archive for analysis.

There is an important second step. Updating the software doesn't take a bucket name away from another AWS account that already owns it. AWS also tells users to verify ownership of the scan-input bucket or pre-create that bucket before the first scan. Anyone responsible for these tools needs to do both: update the affected component and confirm that the storage destination belongs to the expected account. A software inventory alone won't reveal whether an old run used a bucket controlled somewhere else.

The failure is striking because the product is a security agent. It packaged the material an attacker would most want, then relied on the name of a cloud resource without proving who owned it. The model wasn't the weak point. Ordinary resource provenance was.

AWS didn't say whether it had seen exploitation in the wild, so the bulletin doesn't support a claim that archives were actually stolen. It does support urgent verification wherever an affected version ran. For developers building agents that move code or credentials through temporary storage, ownership checks need to sit in the control path and fail before upload. A generated bucket name may look obscure, but obscurity isn't authentication.

AI Capacity Meets Nuclear Time

Zoom out from one storage bucket and the infrastructure commitment stretches from seconds to decades.

Google has announced thirteen billion euros of planned investment in Finnish digital and AI infrastructure during 2027 and 2028. It describes that as its largest single investment in Europe. Alongside the data-centre build-out, the programme includes new wind capacity, a contracted ninety-four-megawatt battery system and a twenty-two-year power-purchase agreement with Finnish energy company Fortum.

Fortum says the agreement supports extending the life of the Loviisa nuclear plant. The contracted supply will ramp up to as much as half of the plant's capacity from 2030 through 2049, providing revenue certainty for operation through 2050. About seven hundred million euros of capital spending needed for the life extension was still subject to separate investment decisions when Fortum announced the deal. That last figure is a useful reminder that a power contract supports a project; it doesn't make every remaining investment automatic.

The scale is revealing even though Google didn't disclose how much additional data-centre compute the investment would provide. Large AI buyers aren't shopping for electricity one server rack at a time. They are using long contracts to secure power and, in this case, help make generation and grid assets financeable. Wind, nuclear generation and battery storage each cover a different part of that capacity problem. The battery can help manage when electricity is available, while the nuclear agreement secures long-duration supply.

For organisations planning substantial AI infrastructure, energy contracting is becoming part of compute strategy rather than a facilities detail dealt with later. A long-term clean-power agreement can support new capacity and give both buyer and generator more certainty. It also links the economics of AI growth to assets, demand forecasts and capital decisions measured across decades.

Both the investment timetable and its economic effects are forward-looking company plans. The missing compute figure also makes comparisons difficult. Still, the commitment shows where the constraint has moved: access to chips is only one part of scaling AI. Power that is dependable, financeable and available in the right place can shape the build just as much.

Misuse After Release

Some risks only become visible when a model is already in people's hands and a pattern forms over several requests.

Anthropic has published its third report on misuse of Claude, saying it blocked attempts involving malicious cyber activity, surveillance and research that could have supported biological weapons. The Associated Press reports that Anthropic described nine cases and stressed they were notable, novel examples rather than a picture of typical use.

One case involved assistance with a grant application for research into chikungunya transmissibility and immune evasion. That work could have legitimate public-health value, while similar knowledge could also support harm. Anthropic said all of the reported activity was blocked and that newer models have stronger safeguards for dual-use biological research.

This is where a simple list of prohibited prompts runs into the real world. A single request about a virus, software weakness or surveillance technique may be entirely legitimate. Harmful intent can emerge from the user's sequence of questions, the detail being assembled and the surrounding account behaviour. Detecting that pattern calls for monitoring after deployment, investigation and, when justified, account enforcement. Pre-release model testing can't observe every way a live system will be used.

That creates an uncomfortable operating problem. A provider that sees only the current prompt may miss the pattern. A provider that gathers more context can make a better assessment, but its monitoring and enforcement decisions carry more weight for legitimate researchers. The report shows the shape of that tension without measuring how well Anthropic resolves it.

There is a hard limitation on what we can conclude from this report. Anthropic selected the cases, described its own intervention and didn't provide an independently audited set. Dual-use intent is difficult to establish even with access to the full interaction. Nine unusual cases don't tell us the overall misuse rate or how often safeguards inconvenience legitimate experts.

For organisations deploying powerful models, my takeaway is that safety becomes an operating function, not a test the model passes once. Providers need enough context to distinguish expert work from a harmful campaign, while accepting that the distinction will sometimes remain uncertain. Anthropic's examples make the need for continuous oversight credible; they don't prove that the industry's current detection methods are complete.

Health AI Beyond Approval Day

That need for oversight across time also appears in a very different setting: health care.

An independent commission hosted by the United Kingdom's medicines regulator has recommended a future framework for health AI based on proportionate lifecycle regulation, shared responsibility and transparency. Its central point is that a one-off assessment before an AI-enabled medical device reaches the market isn't enough. Safety and performance need continued monitoring after deployment.

The recommendations cover medical devices and wider uses of AI in health, including accountability, governance inside health organisations, information for patients and assurance across the health system. That broader scope recognises that failures can come from how a tool is introduced or supervised, not only from the model considered in isolation.

No new binding rule took effect with the report on 10 September. The recommendations are advisory, and the UK government says a cross-government response will follow. Final obligations, adoption and implementation dates are all unknown.

Developers and health organisations therefore have a signal, not a compliance deadline. The sensible preparation is to preserve evidence of real-world performance, define who responds when that performance changes and make monitoring part of the deployment design. That work could make a later regulatory transition less disruptive, but it shouldn't be presented as compliance with rules that don't yet exist.

Apple Folds the iPhone

A more visible experiment arrives from Apple, although nobody has put the shipping hardware through its paces yet.

Apple unveiled iPhone Duo on 9 September, its first foldable iPhone. It has a seven-point-six-inch inner display, a five-point-four-inch outer display and Apple's new A20 Pro chip. Pre-orders are scheduled for 16 October, with availability from 23 October, so this remains an announced product rather than one consumers can test today.

Apple says the A20 Pro is made on a two-nanometre process and includes two sixteen-core Neural Engines, delivering twice the compute for AI models running on the device. Those performance figures come from Apple. Independent testing of speed, battery life and durability will have to wait for shipping phones. Foldables add moving parts and a display crease to the familiar questions about phone longevity, so the absence of real-world evidence is especially relevant here.

Siri AI will run in beta through iOS 27. Apple says it can use personal context and understand what is on the screen, with processing divided between the phone and Apple's Private Cloud Compute. That combination is Apple's attempt to make a more contextual assistant useful without sending every task to a conventional cloud service.

For app developers, the immediate work is more concrete than the AI promise: interfaces need to behave sensibly across the outer screen, the larger inner display and changes between them. For buyers, the attraction is a phone that combines multitasking space with more on-device AI. My read is to separate that product idea from proof that Apple has nailed it. Siri is still beta, and the performance and durability claims have not yet met independent reviewers.

What Changes for You

For builders who want to act on one item now, the Agents API is the practical change to examine.

It is available to all developers in public beta, and it exposes the long-running context, tool discovery, MCP connections and orchestration layer behind Codex. You can choose an OpenAI-hosted sandbox, an integrated partner or your own execution infrastructure. That means a developer can test a serious agent workflow without first writing every supporting service, while keeping execution in an environment that fits the application.

The first useful comparison isn't another model benchmark. Take one bounded job your current prototype struggles to finish, then account for the full token and tool spend, the observability you can obtain and the controls you still have to build around it. OpenAI doesn't charge a separate Agents API fee, but those underlying costs remain, and a long-running agent can accumulate them in ways a single chat request doesn't.

The limitation is maturity. Public beta means the interface and operating guarantees may change, and using your own infrastructure doesn't make the managed harness portable. The new option is valuable because it removes substantial plumbing. That same convenience is the lock-in question worth measuring before it becomes the foundation of the application.