Earlier in this series, a buyer's guide to securing AI coding agents argued that sandbox, vault, gateway, remote environment and control plane are answers to different questions, not competing answers to one. This article takes the pair teams most often confuse and sets them side by side: the remote development environment, and the agent control plane.
Remote development environments solved a real problem. Every engineer gets a consistent, centrally managed workspace instead of a machine that drifts: the same image, the same tools, compute that does not depend on what is under someone's desk. Platform teams adopted them for good reasons and should keep them.
Then the user in that workspace stopped being only a person. It became an agent that runs for hours, acts on input nobody vetted, and reaches for every credential within range. Hosting the place where an agent works turned out to be a different job from governing what the agent does there.
Two jobs, two layers. Treating them as one is how a team ends up believing a workspace product secured something it was never built to secure.
Remote development environments are genuinely good at hosting
Give credit where it is due, because the value is real and the comparison is not a takedown.
A remote development environment standardizes where work happens. It hands every developer an identical, reproducible workspace built from a central image, so "works on my machine" stops being a sentence anyone says. Onboarding drops from days to minutes. Heavy builds and test suites run on managed compute instead of a laptop. Images are patched in one place rather than across a fleet of personal machines. These are strong operational wins, and they do not go away when an agent shows up.
What a workspace governs, by design, is the environment: the operating system, the toolchain, the ports, the compute. That is its job, and it does it well.
What changes when the user is an agent
An agent uses that same workspace differently from a person, in ways that matter for security.
It runs continuously, not in the bursts a human works in, so the window in which something can go wrong is always open. It acts on untrusted input: a ticket, an email, a web page, a dependency it just fetched, any of which can carry instructions the agent treats as its own. And it reaches for whatever credentials are present in the environment, because that is the path of least resistance to finishing the task. A person has judgment about which of those credentials to touch. An agent has a goal.
The workspace hosting that agent was built for the person. It makes the environment consistent. It does not, on its own, decide which credential the agent may read, which verb it may run against production, or where its outbound requests are allowed to go. Those were never the workspace's questions.
Four questions a workspace does not answer by itself
When the user is an agent, four questions decide your actual exposure, and none of them is answered by standardizing the environment:
Which credentials can the agent read? A consistent image says nothing about whether the agent can reach the database password or the cloud profile sitting in it.
Which verbs may it run? Reaching the production database is not the same as dropping a table in it. Hosting the session does not classify the statement.
Where did its requests go? A workspace gives you process and container logs. Those tell you the session ran. They do not give you a per-request record of every destination the agent reached.
Who approved the run that executed at 3am with nobody watching? A headless run triggered by an event has no human at the keyboard, and the workspace has no opinion about that.
These are the questions a control plane exists to answer: credentials the agent never holds, actions judged by verb and target, egress recorded to storage you own, and governed approval for unattended runs. They sit at a different layer from hosting.
The two layers are complementary, not rivals
None of this means you choose one. The honest picture is that most platform teams will run both, because they do different things.
The workspace is the floor the agent stands on: the image, the compute, the ports, the developer experience. The control plane is the set of rules the agent operates under while standing there: what it can authenticate as, what it can do with that access, and what record it leaves. A workspace without those rules is a well-provisioned machine handing an improvising process your credentials. Control-plane rules without a good workspace are guardrails around a painful place to work, which developers route around.
Put them together and each does the job it is good at. The mistake is not adopting a remote development environment. The mistake is adopting one and checking "agent security" off the list.
How to evaluate what you already run
You can assess your current setup in an afternoon, reusing the scoring approach from the buyer's guide.
Take the four questions above and answer each with evidence rather than intention. Can the agent read any long-lived secret from the workspace, yes or no, show the output of env. Which verbs are blocked before they execute against production, and where is that enforced. For a request to an unexpected destination last week, where is the record, and is it in storage you own. For the last unattended run, what was it allowed to do, and who declared that scope. Where the answer is "the workspace does not do that," you have found the control-plane layer you are missing, not a flaw in the workspace.
The question is never "workspace or control plane." It is whether the layer that governs the agent exists at all, on top of the layer that hosts it.
Remote development environments earned their place by making where work happens consistent and fast. That is hosting, and it is a real job done well. Governing what an agent does in that environment, which credentials it holds, which verbs it may run, where its traffic went, and who approved an unattended run, is a second job at a second layer. Most teams need both. Solving only the hosting layer is not solving the agent problem.
This piece extends the category map drawn in the buyer's guide to securing AI coding agents →
Marshal is the control-plane layer: it runs your coding agents with credentials they never hold, actions judged by verb and target, and egress recorded to storage you own, on top of whatever workspace your team already uses. Book a demo →