OpenAI Acquires Ona to Build Secure Cloud Execution for Long-Running Codex Agents

OpenAI reportedly announced an agreement to acquire Ona, a platform that runs teams of AI software engineers in secure cloud development environments. Financial terms were not disclosed. The intended integration, per OpenAI’s announcement, is to allow customer-controlled cloud execution environments for long-running autonomous agents, multi-hour and multi-day workflows that current Codex deployments can’t reliably sustain.

Ona’s platform description is straightforward: background agents operating inside isolated, secure development environments in the cloud. That architecture addresses a specific gap. Codex is already in production at scale, OpenAI states the platform has surpassed 5 million weekly active users, with knowledge workers now representing approximately 20% of that base, per reporting. The user base climbed from 3 million to 4 million in roughly two weeks before reaching the current milestone. That growth rate is outpacing what the existing execution infrastructure was built to handle.

The catch is that rapid adoption and production-grade agentic deployment aren’t the same thing. Teams can run short-horizon Codex tasks today. The problem surfaces when those tasks need to run for hours, branch across multiple tool calls, maintain state across sessions, and do all of it inside a customer’s own security perimeter. That’s the gap Ona is designed to close. The acquisition is intended to bring that secure execution layer inside OpenAI’s stack rather than require customers to build it themselves.

This is an orchestration story, not a model story. The Codex model hasn’t changed. What’s changing is the infrastructure beneath it, the environment where agents actually run, who controls that environment, and what audit and access controls are visible to the customer. For enterprise teams evaluating Codex for anything beyond one-shot tasks, those questions aren’t secondary. They’re the deployment decision.

The compliance angle deserves specific attention. Customer-controlled cloud environments shift where data processing occurs and who holds the audit trail. Before extending Codex to long-running autonomous workflows, teams should have clarity on what “customer-controlled” means in practice under this acquisition: which infrastructure components remain with OpenAI, what logging persists, and whether the execution environment satisfies existing data residency and access control obligations. The announcement doesn’t yet answer those questions. Acquisition terms and integration timelines haven’t been disclosed.

Don’t expect immediate architectural changes. Acquisitions of this type typically require months of integration work before the acquired capability surfaces in production APIs. Codex’s growth trajectory, from 3 million to 4 million to 5 million weekly active users, demonstrates the demand already exists. The Ona acquisition suggests OpenAI is building the infrastructure to serve the next phase of that demand, not the current one.

What to watch

integration timeline disclosure in Codex API documentation, pricing impact on enterprise tiers, and whether “customer-controlled environments” translates to actual data residency guarantees or remains a positioning claim. The first Codex API update post-acquisition will be the signal worth tracking. If Ona’s secure execution model surfaces as a configurable option rather than a default, that tells teams something important about how OpenAI is pricing the infrastructure layer relative to the model layer.

The part nobody mentions: orchestration security isn’t solved by owning the execution environment. It requires clear identity and privilege frameworks for the agents running inside it. Ona’s architecture handles the environment boundary. Whether the acquisition includes opinionated agent identity management, or leaves that to customers, will determine how much of the agentic security problem this actually closes.