How a2a cloud isolates agents

How a2a cloud isolates agents

Autonomous agents need room to act. They need to read files, call tools, write artifacts, run code, and sometimes hand work to other agents. The hard part is giving them that power without turning every run into an all-access pass.

a2a cloud treats isolation as a product surface, not an implementation detail. Every agent run is shaped by four boundaries: who is allowed to act, what workspace it can see, where code executes, and how authority can be passed forward.

Authority starts with a grant

An agent does not receive broad workspace credentials. It receives a signed grant.

A grant says who issued it, which agent may use it, which workspace it covers, what paths are readable, what paths are writable, how long the permission lasts, and whether related resources such as model budget or source access are in scope.

That means a callee agent does not need to trust the caller's process. It verifies the grant. If the signature is invalid, expired, aimed at the wrong audience, or outside the allowed scope, the run is rejected.

Delegation follows the same rule. When one agent hands work to another, the child grant cannot exceed the parent grant. It cannot switch buckets, increase write authority, widen source access, escape deny rules, or live longer than the authority it came from.

Workspaces are bounded views

Agents do not operate on raw host files. They operate through a workspace interface.

That interface exposes search, read, write, delete, and artifact operations, but every operation is checked against the active grant. Read paths must match the grant's allow rules and avoid deny rules. Write paths must match the active write prefixes or approved output area.

This makes the workspace feel practical for agents while keeping the authority narrow. A research agent can receive read-only source context. A build agent can write under a generated output prefix. An agent builder can be given a specific source tree when the user intends to create or update that agent.

The important distinction is that the platform performs the storage operation after policy has been checked. The agent is not handed a general storage key and asked to behave.

Code runs in a sandbox

When an agent needs to run code, install packages, transform files, or execute a shell command, that work happens inside a sandboxed execution environment with the workspace mounted at a known path.

The sandbox is intentionally general purpose. It can run Python, shell tools, build systems, package managers, or other binaries in the requested image. But it still runs through the platform's policy layer. The sandbox receives the same workspace boundary, resource limits, and network controls as the rest of the invocation.

Inside the sandbox, writes are constrained before they reach durable storage. By default, generated files belong in the output area. When broader workspace writes are needed, that has to be reflected in the grant. The storage backend still enforces the grant as the final authority.

If code writes outside the mounted workspace, the runtime can capture those changed files into a controlled output area rather than silently losing them or letting them leak into the host.

Source access is separate from file access

Agent source is treated as a distinct capability.

A workspace path may point at an agent's source, but source access still needs to be explicitly represented. When write access to source is needed, the platform checks that the user is allowed to access that agent or organization, then mints a short-lived source-control token for a dedicated service identity.

That token is scoped to the repo and permission needed for the job. Agents do not receive admin source-control credentials. The resulting edits can be audited back to the user, grant, and run that requested them.

Secrets stay behind runtime interfaces

Secrets are not passed as ordinary prompt text or general files. Platform secrets, user setup values, model credentials, and per-agent environment values are projected through runtime interfaces.

Agent authors use logical names. The platform decides which values exist for that invocation and prevents user-defined secrets from overwriting reserved platform names. Model credentials follow the same pattern: the agent asks the runtime for model access, while the control plane decides whether the call is funded by the platform, the caller, or the agent's own configured provider.

Isolation has to compose

The real test is not whether a single agent can be isolated. It is whether isolation survives composition.

A useful agent system has handoffs. One agent calls another. A builder creates a new agent. A reviewer inspects source. A sandbox runs a build. A workflow retries. A user resumes a paused run.

That is why the isolation model is built around portable claims instead of process-local assumptions. Grants carry audience, bucket, scope, write prefixes, source permissions, and time limits. Receipts and replay metadata then give the platform a record of what happened under that authority.

The goal is not to make agents powerless. The goal is to make every unit of authority visible, bounded, and revocable.

The shape of a safe agent platform

The design principle is simple: agents can be autonomous without being ambiently trusted.

They can read the files they were granted. They can write where the grant permits. They can run code in a sandbox. They can ask for more scope when the skill explicitly allows it. They can delegate only within the bounds they already hold.

That is the difference between hosting code and hosting agents. A code runtime needs containers, storage, and logs. An agent runtime needs those things plus authority, receipts, replay, source boundaries, and a way to prove that every action stayed inside its grant.