Understanding cloudrun's AI agent isolation boundaries

An AI agent's isolation boundary determines which files, credentials, processes, and services it can reach if a task goes wrong. Separate chat histories are useful, but they do not establish that boundary. For a hosted agent, the relevant questions concern the runtime machine, the control plane, and the permissions of connected services.

This guide covers cloudrun's published architecture and an implementation review completed on September 5, 2026. It distinguishes provider documentation from code-level findings. The review did not test running production environments or independently verify their isolation.

Where does the runtime boundary sit?

cloudrun's published architecture places a Hermes engine on its own runtime box, with the control plane communicating over HTTP. The reviewed implementation also has provider-specific Box and VM paths. Hermes profiles within an engine use the same environment; creating another profile does not, by itself, provision another container or VM. cloudrun architecture documentation.

That distinction matters when deciding where to put client work. A profile can organize an agent's instructions, sessions, and settings without creating a machine boundary between it and another profile. If two clients require separate execution environments, treat that as a deployment requirement rather than relying on their names in the interface. The agency fleet playbook turns those client boundaries into an operating inventory.

The Hermes profile documentation describes profiles as separate home directories on the same machine. It also documents shared root OAuth credentials for some providers. A claim that every profile has completely separate credentials would therefore need a much narrower definition.

What does the infrastructure provider isolate?

For Upstash Box, the provider documents container separation, including separate filesystems, process trees, and network stacks. It also documents restrictions on access to private networks and cloud metadata services. These are provider statements about Box; they do not describe every cloudrun deployment option. Upstash security documentation.

A container should not be described as a dedicated physical machine. Likewise, support for a VM deployment option does not establish that its entire physical host belongs to one customer. Buying a deployment tier and selecting a trust boundary are related decisions, but the tier name alone is insufficient evidence. Our hosting comparison explains how operational responsibility changes across local machines, VPS instances and managed hosting.

For a workload assessment, record the actual environment used by the engine. Include who controls it, which runtime version is installed, and whether other profiles share it. This small inventory prevents a security review from drifting into statements that apply to a different configuration.

Map the boundary before you deploy

Write down which users, credentials and workloads may share an environment. Use the architecture and access checks in this guide to evaluate that arrangement with harmless sample data before introducing client information.

The developer deployment guide connects the setup steps with the operating questions to resolve. When Hermes fits the task, create a test workspace and verify the boundary required by your use case. Passing a setup flow does not establish that a deployment meets every client's security requirement.

How does cloudrun authorize access?

The reviewed shell and provider-configuration routes identify the caller, resolve the engine's project within the caller's organization, and check whether the caller is the project owner or an organization administrator. These checks occur in the server routes, where they can control requests made outside the browser interface.

That is a description of inspected code paths. It is not evidence that every route has been audited or that production has passed a tenant-isolation test. A release review should exercise ordinary members, owners, administrators, revoked sessions, and requests for another organization's resource.

The same review should distinguish cloudrun platform keys from model-provider keys. In the inspected implementation, a platform API key carries organization-admin authority. A key that manages deployments deserves different handling from a key that only calls a model.

For an agency, these access rules should become an operational decision: which staff members need to administer all client deployments, and which only need to work on one project? Avoid granting broad credentials simply because they make initial setup convenient.

Does an isolated runtime hide data from the host?

Isolation between customer runtimes does not establish isolation from the hosting operator. The reviewed control plane can execute commands and read or write runtime files to provision and manage an engine. It also holds credentials used to reach the runtime dashboard.

A customer assessment therefore needs to include operational access. An application can keep agents on separate machines while still granting its own service the ability to administer those machines. Claims such as "only you can access your data" would require a different, independently verified design.

Data can also leave the runtime through model requests, authorized integrations, and configured telemetry. Review those destinations separately. A filesystem boundary cannot tell you where an application sends a prompt or which account receives a generated document.

What happens when an agent runs a shell command?

Treat code execution inside an environment as access to the permissions available there. Upstash specifically warns that environment variables are accessible to code running within a box. Putting a model key in an environment variable therefore does not make it secret from every program inside that environment. Upstash security documentation.

Before installing a skill or connecting an execution tool, review the files and credentials available to it. A reasonable starting configuration gives an agent the smallest set of accounts needed for its task. For example, a reporting agent may only need read access to its data source and write access to one output destination.

An agent that reads untrusted web pages while holding a broadly privileged connector needs more than separate storage. Decisions about tool permissions and approval requirements still matter within an isolated runtime.

Is a public runtime URL private?

A hard-to-guess URL should not be treated as authentication. Upstash supports public URLs with optional bearer-token or basic authentication; the selected configuration determines what protects the exposed port. Upstash public URL documentation.

The reviewed cloudrun code has runtime dashboard authentication and provider-specific access mechanisms. It does not justify a blanket statement that every port is private or that every endpoint uses the same protection. Review the dashboard, agent API, terminal, and any service the agent exposes as separate entry points.

When testing, use synthetic data and credentials created for the test. Confirm both permitted access and rejected access. A dashboard that loads successfully proves much less than a dashboard that also rejects the wrong organization and an invalid credential.

What should a deployment owner verify?

Before placing client data in an engine, identify its runtime environment, decide who may administer it, and list the external services the agent can access. Confirm that profile separation is sufficient for the intended workload. If machine separation is required, make that explicit in the deployment review.

Assess the release and configuration used by the actual deployment. A published architecture explains the design, while a code review explains the inspected implementation. Tests against that deployment are needed to establish whether its access rules and runtime boundaries behave as expected.