The security of cloud work rests on three questions: where the data lives, for how long and where the agent may reach. Virtual machines are isolated, idle ones are reclaimed, and internet access is determined by the environment's policy. There are three network modes: allow everything, a default set plus an exception list, and the exception list only. An environment can inherit a team or user policy, extend the list or have its own mode, and at the corporate level this can be locked.
The naive model treats machine isolation as security itself. It closes one class of risks: the agent will not reach someone else's data on a neighboring machine. But it says nothing about what the agent can send outward through an allowed domain and what it reads inside. Those two things are most often what makes up the real risk of autonomous work, because both look like ordinary work and leave no trace resembling an incident.
It helps to lay the data lifecycle out in a table once. Below is that map: the working machine is isolated and reclaimed when idle; the disk state of builds and snapshots is reused and expires after a long inactivity; the conversation is stored and deleted together with the agent, while corporate policy may narrow the window; secrets live until deleted, and session variables leave with the agent; artifacts are tied to the agent; the version control token is determined by the connected provider and the account's scope.
| Data | Lifecycle |
|---|---|
| The working machine | Isolated; an idle one is reclaimed |
| Build and snapshot disk state | Reused; expires after long inactivity |
| The conversation | Stored and deleted with the agent; corporate policy may narrow the window |
| Secrets | Kept until deleted; session variables leave with the agent |
| Artifacts | Tied to the agent and available through the interface and the API |
| The version control token | Determined by the provider and the account's scope |
The last row of that table matters more than the rest. The agent's rights in the repository are not its own rights but the rights of the account it is connected under. A personal token gives the agent everything you can do, including repositories that have nothing to do with the task; a service account with a narrow scope gives exactly what is needed. The difference is visible only at the moment of an incident, which is why it is decided in advance.
Passing environment variables at launch is a convenient mechanism with its own limits: values are encrypted at rest, the number of entries and their length are capped, and names with a reserved prefix are not accepted. An important operational detail: the feature may be in gradual rollout, and in some cases values are silently not applied. Hence the practice - on the very first production run check that the variable is actually visible in the shell rather than relying on the fact that it was sent.
The chapter's main warning concerns allowlists of addresses. They govern where it is possible to reach but not what comes back from there. An allowed domain may serve user-generated or compromised content, and it will enter the agent's context as ordinary data. So the network policy is combined with narrowly scoped credentials, tool approvals, event handlers and a check of what the agent received.
This is worth unfolding on a concrete example, because it is not invented. An issue tracker is a domain you will almost certainly allow: without it the agent cannot read the task. An issue is created by anyone with access, and its text enters the context as an ordinary description of work. It is enough to embed an instruction there that looks like part of the requirements, and the agent will carry it out alongside the genuine task without breaking a single network rule. The same holds for pull request comments, documentation pages and responses from third-party services. Such an attempt is stopped not by the address list but by what stands after it: narrow account rights, approval of actions, event handlers and a human reading the result.
The strictest mode has a price, and it is the reason the mode is most often revoked. The list-only mode breaks ordinary work: installing dependencies, pulling images, reaching internal services - everything requires an explicit permission, and the first days go into widening the list as failures arrive. That is tolerable if the list is maintained deliberately, and it turns into a fiction if it is widened by every failure until half the network is in it. The two outcomes are told apart by one sign: in the healthy case the list grows and from time to time shrinks, in the fictional one it only grows, and nobody remembers what half of the entries are for.
The engineering conclusion is simple: cloud security is a composition rather than a switch. Machine isolation, network policy, secret storage, data lifetime and account rights close different classes of risk, and none of them covers the others. They are deployed together and verified separately.
The typical failures are predictable. Treating machine isolation as sufficient protection. Connecting the cloud with a personal token instead of a service account. Relying on session variables without checking their presence on the first run. Widening the allowlist with every failure and never shrinking it. And treating content from an allowed domain as trusted merely because the domain is on the list.