Agent Native Cloud: a cloud designed for AI agents

At WAIC 2026 in Shanghai, Alibaba Cloud presented Agent Native Cloud — a cloud architecture designed from the ground up for running AI agents. The 18 July announcement covers AgentTeams (orchestrating multiple specialised agents), Agentic Computer (secure cloud-based execution) and a redesigned infrastructure with native sandboxes, strong workload isolation, elastic scaling and enterprise identity integration.

For security practitioners this announcement is more interesting than it first appears — regardless of whether you ever use Alibaba’s product. The reason is simple: the component list of this platform is effectively a list of the problems today’s infrastructure fails to solve when you run agents on it. It’s worth reading as a diagnosis rather than a marketing document.

What was announced

The key elements:

Component	Function
AgentTeams	orchestration and governance across multiple specialised agents
Agentic Computer	secure cloud execution environment
AgentLoop	an extension of the existing AgentRun platform
Infrastructure	native sandboxes, workload isolation, elastic scaling
Identity	integration with enterprise identity systems

Alibaba also showed internal results: 15 coordinated agents handle 85% of developer support requests, reducing operational support time by 90% and compressing release cycles to a single day.

Those figures deserve caution — they come from the vendor, describe its own environment and haven’t been independently verified. As a directional signal about maturing agentic deployments they’re credible; as a promise of outcomes in your organisation, they aren’t.

Why “a cloud for agents” isn’t just marketing

Running an AI agent on classic infrastructure is like running a web application on a server designed for batch computation: it works, but every assumption is slightly wrong. Four differences matter in practice.

1. An agent executes unpredictable code

A classic application does what a developer programmed. An agent generates and executes actions at runtime: calling tools, running commands, writing and executing code. From a security standpoint that means you cannot enumerate the set of operations it will perform in advance.

The classic application security model assumes a known range of actions and secures its boundaries. With an agent that assumption collapses — hence the emphasis on sandboxes as a native element rather than something bolted on later.

2. Permissions are dynamic and broad

An application usually has a narrowly defined permission set: a specific database, a specific queue, a specific API. To be useful, an agent receives broad access — to documents, internal systems, integrations. That inverts least privilege, forced by the nature of the task.

Hence the enterprise identity integration. An agent shouldn’t operate on a shared API key but hold its own identity, lifecycle and revocable permissions — exactly what we described in non-human identities (NHI).

3. Multiple agents create new attack surface

AgentTeams addresses orchestration across agents. From a security standpoint each additional agent is not only another identity but another channel of influence: agents pass tasks and results between themselves, and one agent’s output becomes another’s input.

That opens a scenario worth naming explicitly: injected instructions propagating between agents. Agent A processes an external document containing a hidden instruction; its output reaches agent B, which holds broader permissions. The classic trust boundary (“external data is untrusted”) dissolves, because to agent B the input comes from a trusted agent A. We describe the mechanics of this attack class in our prompt injection guide.

4. Scaling is irregular and costly

An agent may do nothing in one session and fire dozens of parallel tool calls in the next. Hence the emphasis on elastic scaling — but it also implies a real risk: cost as an attack vector. An agent stuck in a loop, triggered by malicious input, can generate a bill before anyone notices. Budget limits and hard caps on call volume are a security control, not just FinOps.

What a sandbox for an agent actually means

The word “sandbox” is overused, so it’s worth specifying what we require of an agent’s runtime. This list is universal — it applies regardless of vendor.

Execution isolation. An agent shouldn’t reach the management layer of the environment it runs in. Practically: no access to the container daemon socket, no privileged mode, restricted kernel capabilities (seccomp, capabilities). Why that isn’t excessive was shown by the model that attacked its own test environment, attempting privilege escalation against the container daemon after its network was cut.

Egress control. A default of “the agent can reach the internet” is a straight path to exfiltration. Egress should be denied by default and opened only to specified destinations. Without that, any injected instruction can end in data leaving.

Ephemerality. The environment should be created for a task and destroyed afterwards. A persistent agent container is a persistent foothold for an attacker.

Read-only filesystems where possible, with narrowly defined writable directories.

Full action logging. Not just the result, but every tool call, every command, every file access. Without it you can’t answer “what did this agent actually do” — the first question in any incident.

Resource and budget limits. Execution time, call count, cost. A constraint that also protects against loops caused by errors or manipulation.

We expand on the technical background in container escapes and Kubernetes security — because in practice an agent sandbox is built from those same blocks.

What this announcement doesn’t solve

Honestly: no platform solves problems that belong to deployment design.

It doesn’t solve prompt injection. Isolation limits the impact of successful manipulation but doesn’t prevent the manipulation. If an agent has legitimate access to data and a legitimate tool to send it, an injected instruction will use those permissions in a way indistinguishable from normal work.

It doesn’t solve excessive permissions. The platform supplies the mechanism, but the deployer sets the scope. An agent with access to the entire company drive remains a risk regardless of sandbox quality.

It doesn’t solve output verification. A sandbox doesn’t check whether the agent performed the task correctly. That’s a separate layer — testing, evaluation, quality control — which we cover in LLM evaluation.

It doesn’t remove questions of data location and sovereignty. Where data is physically processed, who can access it, what contractual terms apply — those remain your decisions, not the vendor’s. With non-EU providers there’s a regulatory dimension to settle before deployment, not after.

A practical agentic deployment checklist

Whatever platform you choose, these questions are worth working through before production:

Identity and permissions

Does each agent have its own identity, or do they share a key?
What exactly is the permission scope, and who approved it?
Can you revoke one agent’s permissions within a minute?
Is there a periodic review of agent permissions?

Isolation

Can the agent reach the environment’s management layer?
Is outbound traffic restricted to an allowlist?
Is the environment destroyed after the task?

Visibility

Do you log every tool call, not just the final result?
Can you reconstruct a full action sequence from last week?
Do you have alerts for unusual patterns (a spike in calls, access to new resources)?

Trust boundaries

Which inputs come from outside and are treated as untrusted?
Does one agent’s output reach another without filtering?
Do high-risk operations require human approval?

Response

Who can stop an agent immediately?
How do you revoke its credentials and integration consents?
How do you establish the scope of what it reached?

That last block is effectively an AI incident response plan, and the whole is best validated with an agent red-team harness.

Why multi-agent orchestration needs separate thought

It’s worth expanding on something that appears in agent platform announcements as a feature but is in practice the hardest security problem: what happens when agents talk to each other.

The single trust boundary disappears. In a classic application you can point to where untrusted data enters and place validation there. In a multi-agent arrangement data travels a chain: agent A fetches an external document, summarises it, passes it to agent B, which acts on that basis. To agent B the source is a trusted internal component — even though the content came from outside. Validation at the system’s edge doesn’t protect later links.

Permissions accumulate. Each agent may individually hold a narrow scope, but a set of collaborating agents creates a path whose permissions are the sum of the parts. An agent that reads mail and an agent that sends files are two acceptable roles separately; connected by a workflow, they’re a ready-made exfiltration channel.

Accountability becomes harder. When an action was taken by agent B based on agent A’s output, which processed a user-supplied document, answering “why did the system do that” requires the full event chain. Without logging every step, reconstruction is impossible.

Three practical conclusions follow. First, treat every agent’s output as untrusted data for the next one, especially when external content appears anywhere in the chain. Second, irreversible operations (sending a message, making a payment, deleting data, changing permissions) should require human approval or a separate, narrowly privileged component — not an agent’s decision mid-chain. Third, design workflows so the path’s cumulative permissions are explicit: if nobody can draw it, nobody is managing that risk.

The wider context: infrastructure catching up with practice

This announcement fits a clear trend: the market is building an operational layer for agents, because deployments have moved beyond demos. You can see it in the hardware layer too — we wrote about the race toward custom inference silicon and the falling cost of a token.

The sequence is familiar from IT history: first the technology arrives, then mass adoption, then — usually after a series of painful incidents — the security and management layer. That’s how it went with virtualisation, cloud and containers. With agents we’re exactly at “infrastructure catching up with practice”, and the incidents demonstrating why it’s needed already exist: AgentForger and ransomware run by an agent.

For organisations deploying agents the practical conclusion is: don’t wait for a finished platform. The controls listed above — identity, isolation, egress, logging, limits — can be implemented on existing infrastructure. A platform makes them easier; their absence is a risk regardless of whose product you pick.

Frequently asked questions (FAQ)

Does this mean existing clouds aren’t suitable for agents? They are, but they require deliberate configuration. Everything described as “native” in this platform — sandboxes, isolation, identity, limits — can be built from existing components. The difference is the effort involved and how easy it is to skip a control when it isn’t the default.

Should we consider this vendor? That’s a business and regulatory decision, not just a technical one. For EU organisations the key questions concern processing location, contractual terms and compliance — settle those before evaluating features. What is worth doing is treating the component list as a template of requirements to put to any vendor.

Is a sandbox enough to run agents safely? No. A sandbox limits impact but doesn’t replace least privilege, egress control, logging and output verification. An agent in a perfect sandbox, with access to all company documents and the ability to send email, remains a serious risk.

What about results like “15 agents handle 85% of requests”? Treat them as a directional signal, not a benchmark. That’s vendor data from the vendor’s own environment, without independent verification or a described methodology. Before deploying, measure your own case on a representative sample of tasks.

Where do we start if we’re only now deploying agents? With three things: give each agent a separate identity, deny outbound traffic by default, and log every tool call. That’s the foundation everything else builds on — and what’s most painfully missing during a first incident. If you want to work through it methodically, we do that as part of an AI/LLM security audit.

Summary

Agent Native Cloud is worth attention not as one vendor’s product but as a specification of what agentic deployments demand from infrastructure: native sandboxes, strong workload isolation, identity for agents, multi-agent orchestration and elastic scaling. Read that way, it’s useful whichever cloud you choose.

The key caveat is unchanged: a platform limits impact but doesn’t replace security design. Prompt injection, excessive permissions and unverified outputs are the deployer’s problems. The best sandbox won’t help an agent we granted access to everything and nobody supervises. If you’re deploying agents and want confidence that controls keep pace with scope — let’s check it together.

Sources and further reading: Alibaba Cloud — WAIC 2026, Alibaba Group, OWASP Top 10 for LLM Applications, NIST AI Risk Management Framework.