Managed coding agents change the control-plane question

The model is not the first boundary

InfoQ’s coverage of Anthropic’s Code with Claude describes managed agents and proactive workflows. The important architecture question is not whether a managed agent uses a smarter model than one I run inside my engineering environment. It is where the control plane sits: who grants the agent access, where it executes, and who can reconstruct what it did.

That question matters because a coding agent is not just a model receiving a prompt. It is a process that may read source, run commands, call tools, reach services and produce changes. Moving that process to a managed service can change where those actions happen and which system enforces the boundaries. Keeping the agent inside my environment does not automatically make it safe, either. A self-hosted model can still receive excessive permissions or run in a poorly isolated workspace.

I would compare the options by drawing the trust boundaries, not by comparing product feature lists. For each action, I want to know which system makes the decision, which identity it uses, and where the evidence is recorded. If those answers are vague, a polished orchestration interface has not solved the hard part.

Trace the agent’s path

I start with the repository. Does the agent receive access to a full repository, a branch, or a deliberately limited checkout? Can it read sibling repositories or shared configuration? Can its proposed changes reach a protected branch, or must a person or existing review process approve them? The more repositories and credentials an agent can see, the larger the consequences of a mistaken instruction or a compromised tool.

Next I trace credentials. A token passed into an agent’s environment is part of its effective authority, whether or not the model itself knows the token’s value. I want credentials scoped to the task and the systems it needs, not a developer’s broad personal token. I also want to know which service stores them, how they are supplied to execution, and whether they can be revoked independently of the agent session.

Then I trace network access and execution. Can the agent reach only the repository host and approved package sources, or can it call internal services and arbitrary endpoints? Where do shell commands run? What separates the workspace from other jobs, internal networks and persistent data? “Runs in a sandbox” is not enough detail for an architecture decision; I need to know what that sandbox can reach and what it retains.

Finally, I trace the audit record. I want a useful connection between the task, the identity, the repository revision, the commands or tools used, and the resulting change. A transcript alone may not answer which credentials were available or whether a command reached an internal service. The evidence should live somewhere the team responsible for the repository and its security controls can inspect.

A simple boundary sketch makes the comparison concrete:

flowchart LR
  accTitle: Coding agent trust boundaries
  accDescr: A team grants access to an agent runtime, which reads a repository, uses credentials, reaches tools, and emits an auditable change.
  Team -->|policy and approval| Runtime
  Runtime -->|scoped checkout| Repository
  Runtime -->|task-scoped access| Credentials
  Runtime -->|permitted calls| Tools
  Runtime -->|execution evidence| Audit
  Audit --> Team

The point is not that every system needs this exact shape. It is that repository access, credentials, network permissions, execution and records are separate decisions. A managed service may operate some of these layers; an internally hosted agent may operate others. Neither label tells me where the boundary actually lies.

Keep the policy legible

I would write down the intended boundary before choosing a service. A vendor-neutral policy sketch could look like this:

agent_task:
  repository: selected-repository
  checkout: isolated-task-workspace
  credentials: task-scoped
  network: approved-destinations-only
  writes: proposed-change-only
  evidence: team-accessible
  merge: existing-human-review

This is not a vendor configuration or a guarantee that the settings are enforceable. It is a list of questions I expect a design to answer. If a provider manages the runtime, I still need to understand which controls it exposes, which controls it owns, and what evidence I can retrieve. If I run the agent inside my environment, I still need to implement and maintain the isolation, credential handling, network policy and records myself.

Some controls should remain under the team’s ownership even when the execution service is managed. The team owns the repository’s permission model and the rules for approving changes. It owns which internal systems an agent task is allowed to reach. It owns the decision about what evidence is sufficient for review and incident investigation. A service can provide mechanisms for these policies, but the team should be able to state the policy without relying on a provider’s marketing term for it.

That does not mean every control must run on infrastructure the team operates. There is a real cost to building and maintaining execution isolation, credential brokering and observability. A managed service can be a reasonable choice if its boundaries fit the work and the organization can verify them. Running agents internally can be the better choice when repository or network constraints require direct control, but it makes the operating burden ours. I would choose based on those constraints, not on a general preference for hosted or self-hosted systems.

Orchestration is not reliability

A service that creates sessions, resumes work or coordinates multiple agents can make a workflow easier to operate. It does not establish that the code is correct, that a test is meaningful, or that an agent interpreted the task as intended. Nor does a record of actions prove that the actions were safe. Those are separate questions, and I would not treat orchestration as a substitute for review, tests or a controlled release path.

I would keep the change path boring: agents propose changes; the repository’s existing checks run; a person reviews the result under the same rules as other changes. If the work is consequential, I would make the allowed scope narrower rather than grant broad access in the hope that a better prompt will compensate. A smaller permission boundary limits what a bad decision can affect; it does not guarantee the decision will be good.

The comparison I want from a managed-agent proposal is therefore a boundary map: repository access, credential flow, network reach, execution isolation, and the audit trail. For an internally run agent, I want the same map plus an honest account of who will build and operate each control. Once those are explicit, model choice becomes a meaningful part of the decision—but it is no longer standing in for the decision.