Back to the show

AI & Tech Daily

The New Battle to Control AI Agents

17:52

Cloudflare previews a durable, auditable computer runtime for AI agents, shifting attention from model intelligence to the systems that control files, tools and execution. Also: Alibaba launches its enormous Qwen3.8-Max model; AWS brings Superblocks app generation inside customer accounts; GitHub gives Copilot code review repository skills and read-only MCP context; Samsung removes smart-TV apps carrying residential proxy software; Apple challenges another British demand for encrypted iCloud access; Google expands IP-based ad personalisation in Europe; and Cloudflare makes more SaaS services usable through MCP portals.

Full transcript

Read the episode.

I'm Jesse Owen. This is AI and Tech Daily.

Cloudflare Gives Agents a Computer

The next contest in AI may be won by whoever can let an agent touch real files and run real commands without losing control of what it does.

That’s why Cloudflare’s new agent runtime is worth sitting with. On August 3, the company released an early preview of @cloudflare/computer, an open-source package that gives an AI agent durable files, shell-style tools and a choice of execution environments. The model can read, write, edit and list files, and it can execute commands. The runtime records those operations for auditing.

That sounds like familiar computer plumbing because it is. The useful change is that Cloudflare has put the pieces behind one interface designed for agents. A virtual filesystem is backed by SQLite storage inside a Durable Object, Cloudflare’s stateful Workers primitive, so files and state can survive after an individual task ends. When code needs to run, the system can choose between a lightweight isolate and a container rather than forcing every job into the same kind of sandbox.

Durable state also changes how an agent can recover. If a task stops halfway through, the next execution can inspect the files left behind instead of rebuilding its workspace from a prompt or an external database. That persistence is useful, but it raises the stakes of auditing: a bad edit can survive just as readily as a good one, and later runs may build on it.

The distinction matters in practice. Isolates can start quickly and suit smaller jobs. Containers can support heavier software and a more complete operating environment. An agent may need both across one workflow: inspect a document, edit a configuration file, then run a tool that expects a fuller Linux environment. Builders have been assembling storage, sandboxes and tool definitions separately to make that possible. Cloudflare is offering a packaged layer that presents them as one computer.

The more consequential feature may be the audit trail. Giving a model command execution is easy to demonstrate and hard to govern. Once an agent can change files or invoke software, a team needs to know what happened, which action failed and what state remains for the next attempt. Operational consistency won’t make the underlying model smarter, but it can make a capable model safer to deploy and much easier to debug. My read is that this is where agent platforms may differentiate: not through another clever demo, but by making risky actions visible and governable by default.

There are substantial caveats. Cloudflare calls this an early preview, not a production-mature service. It depends on Workers and Durable Objects, so adopting it also means accepting Cloudflare-specific architecture. We don’t yet have independent evidence about reliability, pricing at scale or how well the system chooses between isolates and containers under real workloads. The open-source label doesn’t erase those platform dependencies.

For developers, the immediate opportunity is a cleaner experiment. A team can test a durable, auditable agent workspace without first building every storage and execution interface itself. The trade-off is clearer too: less integration work now, in exchange for more dependence on one provider if the experiment becomes infrastructure. That’s a more useful question than whether the agent looks impressive in a five-minute run.

Alibaba’s 2.4-Trillion-Parameter Model

With the runtime in view, the model race itself looks a little different — although Alibaba has supplied a very large reminder that it’s far from over.

Alibaba launched Qwen3.8-Max on August 3 as a hosted model aimed at coding and agentic work. The company describes it as a 2.4-trillion-parameter mixture-of-experts model. In that design, only a portion of the model’s specialised components are activated for a given input, which can make an enormous total parameter count more practical than using every parameter for every token.

Alibaba also said model weights would follow the next week, alongside a smaller 27-billion-parameter release. That promise could matter for organisations wanting more control over deployment, but it wasn’t fulfilled on the launch date. The scope of the release, its licence and the exact timing remained unverified. Even if the full weights arrive on permissive terms, operating a model at this scale demands serious infrastructure. “Downloadable” and “widely usable” aren’t the same thing.

The performance story needs similar restraint. Alibaba says Qwen3.8-Max matches or beats competing frontier models on selected benchmarks. Those are vendor claims based principally on vendor-selected evaluations, not independent validation. The sensible test is whether it performs on a team’s actual coding tasks, tool use and failure cases, at a competitive cost and latency.

Still, another frontier-scale option increases pressure on Western providers. Developers can evaluate the hosted model immediately, and large cloud operators or well-funded labs may eventually have a new set of weights to work with. My assessment is that the near-term effect is more likely to be price and capability competition in hosted services than a sudden wave of people running 2.4 trillion parameters themselves. The smaller promised model may prove more accessible, but its capabilities also remain to be seen.

Superblocks Moves Inside AWS Accounts

For enterprises, where an AI app runs can be as important as what generated it. AWS and Superblocks are leaning directly into that concern.

The two companies announced a multiyear commercial partnership on August 3 that embeds Superblocks deployments in customers’ private AWS environments. Superblocks generates internal applications with AI assistance. Under this arrangement, those apps can use Amazon Aurora for data and Amazon Bedrock for model access while remaining inside the customer’s AWS account. AWS is also helping market the product to enterprise customers. Financial terms and any exclusivity were not disclosed.

This answers a common objection to so-called vibe coding in large organisations. A business may be willing to generate an internal dashboard or workflow, but not if sensitive data, database calls or model prompts have to travel through an unknown external environment. Superblocks says customer data isn’t sent to outside model or database providers. That is the company’s claim, not the result of an independent security audit, but the deployment design gives security teams familiar AWS controls to inspect.

Data location is only one part of the risk. Generated applications still contain code, permissions and dependencies. A tool can remain inside a private cloud account and still produce insecure queries, excessive access or a vulnerable supply chain. Governance has to cover what the app does, who can publish changes and how generated code is reviewed, not simply which account receives the traffic.

For organisations already concentrated on AWS, this could make AI-assisted internal app development easier to trial without creating a separate data boundary. My caution is that the convenience comes with a double dependency: Superblocks for generation and AWS for the surrounding platform. There’s no independent evidence yet on code quality, security outcomes or enterprise-scale adoption, so the sensible early measure is whether teams can govern the generated apps as rigorously as the hand-written ones they replace.

Copilot Reviews Gain Skills and Context

There’s a quieter improvement in the everyday development loop, and it comes with a control that’s easy to appreciate.

GitHub made agent skills and Model Context Protocol connections generally available in Copilot code review on July 29. The features are available to Copilot Pro, Pro Plus, Business and Enterprise users. Repositories can place review-specific standards and instructions in SKILL.md files under the .github/skills directory, giving Copilot more than a generic request to inspect a pull request.

MCP connections extend that context beyond the repository. During a review, Copilot can consult issue trackers, documentation or service catalogues connected through the Model Context Protocol. Those calls are restricted to read-only operations. That doesn’t make external data harmless — teams still need to consider what context is exposed — but it prevents the reviewer from changing a ticket or another connected system while it gathers information. Review comments also identify when a skill or MCP context contributed to their generation.

Those two controls, attribution and read-only access, make the feature easier to evaluate. If a review comment reflects an internal standard, a developer can see that context was involved rather than treating the suggestion as unexplained model judgement. A platform team could encode expectations for error handling, deployment structure or service ownership and then check whether the reviewer applies them consistently.

GitHub hasn’t provided independent evidence showing how much this context improves review accuracy. More information can produce better advice, but it can also reinforce a bad local rule or generate confident noise. For development teams, my recommendation is to treat the rollout as a measurable reviewer, not an automatic gate: track useful findings, false positives and missed defects before making its approval part of a required workflow. The new context makes Copilot more relevant to a specific codebase; it doesn’t make it accountable for the result.

The Proxy Risk Hidden in Smart TV Apps

A television app can look low-risk right up until it starts affecting the network behind the screen. Samsung has now acted on exactly that problem.

On August 3, Samsung confirmed that it was restricting new Smart TV app registrations and removing apps identified as carrying residential proxy software. Security research cited by TechCrunch found proxy components inside television applications that could route strangers’ internet traffic through a household connection, effectively turning that connection into an exit node. To an outside service, the stranger’s activity can then appear to come from the home’s IP address.

There are important limits to what’s known. The reporting doesn’t establish that every identified app activated proxy sharing without consent. It doesn’t provide a complete app list, quantify the number of affected televisions or establish the installed base. Samsung’s store action also doesn’t prove that every previously installed app, component or related data flow has been remotely removed.

Even with those uncertainties, the exposure is unusual enough to take seriously. Residential proxies are valuable precisely because their traffic resembles ordinary household use. If someone else’s browsing or automated activity exits through your connection, the effects can range from degraded bandwidth to fraud flags or reputational trouble attached to your public IP address. A smart television often receives less scrutiny than a phone or laptop, despite sitting on the same home network for years.

Samsung’s removals reduce future distribution through its store, which is useful, but they don’t settle the status of devices already in homes. For the public, the practical lesson is narrow and concrete: connected-TV app permissions and publishers deserve the same suspicion as mobile apps, especially when an entertainment app claims a reason to share network resources. My view is that television platforms have allowed the “appliance” feeling to obscure a software supply-chain problem. Store review and clear disclosure need to catch network-level behaviour before it reaches the lounge room.

Apple Challenges Another UK Encryption Demand

The next story is less visible by design, which is part of what makes it consequential. Apple is reportedly fighting a second British demand involving encrypted iCloud data.

Apple has filed a challenge with the UK’s Investigatory Powers Tribunal against another Technical Capability Notice, according to reporting published on August 3. A notice of this kind can require a communications provider to build or maintain a capability for government access. The latest notice was reportedly issued in October 2025, after an earlier demand for global access was withdrawn. Apple did not comment on the new report.

Much of the notice and the proceeding is secret under national-security restrictions, so the precise scope isn’t public. That leaves a central question unresolved: whether the British government is seeking access confined to UK accounts or a capability that could affect encrypted iCloud data elsewhere. The earlier dispute already produced a concrete loss for British users. Apple’s Advanced Data Protection, its strongest optional end-to-end protection for iCloud data, remains unavailable in the UK.

End-to-end encryption is designed so that the service provider doesn’t hold the keys needed to read protected content. A government access requirement therefore isn’t merely a request for Apple to search data it already controls. Depending on its design, it can demand a new technical path into a system built to deny that path. Even if officials intend tightly controlled use, the existence of the capability can alter the security architecture and the credibility of the promise made to users.

For the public, this legal contest is not abstract. UK users continue without an optional protection available elsewhere, while users outside Britain have no complete public account of the notice’s reach. My analysis is that precedent is the larger risk: a capability created for one jurisdiction may be copied by others or weaken confidence in the service globally. Apple’s challenge keeps that question before a tribunal, but secrecy means the eventual outcome may be harder for users to assess than an ordinary court ruling.

Google Adds IP Addresses to Ad Personalisation

Privacy controls are also shifting in a much more routine system: the advertising machinery attached to an IP address.

Google began allowing IP addresses from users in the UK, European Economic Area and Switzerland to be used for advertising measurement and personalisation on or shortly after August 3. IP addresses are treated as personal data in those jurisdictions. Google says advertisers remain responsible for obtaining valid consent, so the change doesn’t remove the consent obligations that apply to personalised advertising.

An IP address is an imperfect identity signal. Households can share one, addresses can change and privacy tools can obscure them. Even so, it adds another piece of information that can contribute to measuring and selecting ads, especially when combined with other signals. No equivalent August 3 change was announced for Australia.

The awkward part is the sequencing. Google said user-facing controls specifically covering IP-based personalisation would arrive later, without giving a precise completion date for every service or those controls. The data-use change can therefore begin before people receive a dedicated control framed around that use. In my view, that creates a transparency gap even where existing consent mechanisms remain legally required.

People in the covered regions may now have an additional identifier feeding personalised advertising. Advertisers, in turn, have renewed reason to verify that their consent handling matches the expanded data use rather than assuming Google’s platform settings settle compliance for them. The important limitation is timing: the rollout was described as happening on or shortly after August 3, so its exact availability may differ across services.

What Changes for You

One last change is useful if you’re trying to connect an agent to the services your team already uses.

Since July 31, Cloudflare’s MCP server portals can connect to upstream servers that require a pre-registered OAuth client. Previously, a portal depended on Dynamic Client Registration, where software creates its OAuth identity automatically. Services including Slack and GitHub don’t currently support that process for their MCP servers, so they couldn’t fit neatly behind the portal.

An administrator can now register an OAuth client with the upstream service, then supply its client ID and secret to Cloudflare, along with custom endpoints, scopes and one of two supported client-secret authentication methods. Cloudflare says it encrypts the client secret. Each user still signs in with their own upstream account, so the shared client credential doesn’t replace individual authentication.

For developers and platform teams, that makes a managed MCP access layer usable with more mainstream software now. It can centralise how agent clients reach those services instead of leaving every connection to a separate integration. The limitation moves into credential operations: an administrator has another secret to register, protect and rotate, while compatibility beyond the named services depends on each provider’s OAuth implementation.

My assessment is that this closes an unglamorous but real interoperability gap. It also concentrates risk in the portal configuration. The feature is most useful where a team already has disciplined OAuth ownership and wants one governed route to several MCP servers; without that discipline, easier connectivity can simply create a more important credential to lose track of.

You'll find the sources and full transcript at owenonthenet.com. Thanks for listening.

Sources

Reporting behind this episode.

  1. blog.cloudflare.com/cloudflare-computer
  2. bloomberg.com/news/articles/2026-08-03/alibaba-drops-another-china-ai-model-with-breakthrough-performance
  3. techcrunch.com/2026/08/03/aws-is-helping-vibe-coding-startup-superblocks-and-the-implications-are-big
  4. github.blog/changelog/2026-07-29-copilot-code-review-agent-skills-and-mcp-now-generally-available
  5. techcrunch.com/2026/08/03/samsung-bans-smart-tv-apps-that-share-users-internet-connections-with-strangers
  6. techcrunch.com/2026/08/03/apple-challenges-uk-governments-latest-demand-for-icloud-backdoor-report
  7. bleepingcomputer.com/news/security/google-to-use-uk-and-eu-user-ip-addresses-for-ad-personalization
  8. developers.cloudflare.com/changelog/post/2026-07-31-mcp-portal-manual-oauth