Anthropic's Environment API distinguishes cloud and self-hosted execution, while its sandboxing architecture separates filesystem and network boundaries.
Self-hosting moves execution inside the enterprise boundary
Claude Code already occupies more of the delivery lifecycle than a traditional autocomplete tool. It can inspect repositories, edit multiple files, run commands, test its work, and participate in CI workflows.
Anthropic's earlier sandboxing architecture introduced filesystem and network isolation so the agent could operate with more autonomy inside explicit boundaries. Anthropic reported an 84% reduction in permission prompts in its own internal use.
Self-hosted environments extend that control story. Instead of requiring tool execution to happen in an external hosted workspace, an organization can provide infrastructure under its own operational control.
That matters for network access, internal services, compliance boundaries, and established development infrastructure.
It is also important to describe the feature precisely. Self-hosted execution is not self-hosted Claude model inference. The environment is where agent work and tool execution occur; Anthropic still provides the Claude model service.
The distinction exposes the emerging enterprise stack:
- model service;
- agent harness;
- execution environment;
- identity and security controls;
- architectural governance; and
- delivery verification.
Treating all of these as "the AI agent" hides which risks each layer can actually control.
A secure agent can still make the wrong engineering decision
Consider a project with an accepted decision that one component must use SQLite. The rationale may be portability, deployment simplicity, or a dependency elsewhere in the system.
Claude Code receives a task that requires persistence.
The session runs in a self-hosted environment. Its identity is valid. Repository access is authorized. Network access is constrained. Tool invocation is legitimate.
Claude concludes that PostgreSQL is the better implementation.
From the perspective of infrastructure security, nothing necessarily failed. The agent stayed inside the boundary it was given and modified files it was permitted to change.
The proposed implementation still contradicts an architectural decision.
That is architectural drift.
A permission system answers: May this agent edit this repository?
Architectural governance answers: Is this proposed change consistent with the decisions governing this part of the repository?
Those are different verification problems.
Runtime controls and architectural controls govern different objects
Anthropic's security work increasingly reduces implicit trust around execution.
- Filesystem isolation controls where an agent may read or write.
- Network isolation controls which hosts it may reach.
- Tool policies control which commands or integrations it may invoke.
- Managed configuration can standardize those rules across an organization.
- Self-hosted environments control where tool execution happens.
These controls are valuable because coding agents are becoming more autonomous.
They do not determine whether a permitted file change violates a service boundary, whether an approved tool introduces a prohibited dependency, or whether a technically valid implementation conflicts with a ratified ADR.
Sandboxing establishes the area inside which an agent may work. Architectural governance establishes which engineering decisions must remain invariant while it works there.
Shared infrastructure makes informal memory weaker
One developer working interactively with one agent can still carry organizational knowledge in conversation. The developer remembers why a dependency was rejected and notices when a generated change crosses a boundary.
That model weakens when coding agents become shared infrastructure.
A self-hosted environment may serve multiple engineers, remote sessions, automated workflows, or several classes of agents. Architectural intent can no longer depend on every operator restating the same history correctly.
The organization needs relevant decisions to reach the execution surface consistently.
That is governance propagation.
A decision written in an ADR but absent from the execution path has not propagated. A rule copied into one tool configuration but missing from another has not propagated reliably. A decision placed in context but never checked against the resulting change has propagated as information, not enforcement.
The enterprise coding-agent stack needs distinct controls
Engineering leaders should separate five layers.
1. Identity and access
Who may start a session? Which repositories and organizational resources may it access? What credentials does it receive?
2. Execution environment
Where does tool execution happen? Which filesystem and network boundaries contain it? Self-hosted Claude Code environments operate here.
3. Tool and runtime policy
Which commands, files, MCP servers, package sources, or external systems may the agent use? Sandboxing and managed policies operate substantially at this layer.
4. Architectural governance
Which project decisions apply to the proposed change? Which dependencies, patterns, technologies, or boundaries are required or prohibited? Has the relevant decision corpus reached this execution surface?
5. Verification
Did the result satisfy the properties the organization requires? Tests, static analysis, architectural enforcement, CI, security checks, and human review can all participate in the verification contract.
No layer replaces the others. A self-hosted environment without architectural enforcement can still produce drift. Architectural enforcement without sandboxing does not provide runtime security.
Self-hosting creates a natural enforcement point
Placing agent execution closer to infrastructure the organization controls creates a natural point for governance to travel with the workload.
Suppose a platform team maintains a decision corpus covering approved databases, ownership boundaries, prohibited dependencies, required abstractions, and repository-specific implementation constraints.
When a Claude Code session starts, the platform should not depend on every developer manually copying those decisions into a prompt.
The project should resolve the applicable decisions, and its verification contract should determine what is checked as the agent plans and modifies code.
The ADR still carries human rationale. A machine-enforceable representation serves a different purpose: making the consequence of that decision available where software changes.
Context is useful; enforcement is different
Project instructions improve agent behavior. The model should know the architecture before it changes the architecture.
But context delivery is not equivalent to governance.
Compare two systems.
The first tells Claude:
This component uses SQLite. Do not introduce PostgreSQL.
The second resolves the applicable decision when Claude proposes a persistence change and evaluates the modification against the constraint.
Both expose the decision. Only the second creates an enforcement point.
Models are probabilistic. More context can improve the odds of conformance, but the presence of an instruction does not guarantee that every relevant action will follow it.
Deterministic enforcement should remain outside the model wherever the decision can be expressed precisely.
The quiet risk is authorized drift
Agent-security discussions rightly focus on prompt injection, data exfiltration, compromised credentials, unauthorized tool calls, and excessive permissions.
Engineering leaders also need to account for a quieter failure mode: the agent behaves exactly as authorized and still moves the system away from its intended architecture.
It chooses a library that conflicts with an organizational standard. It bypasses an approved abstraction. It creates a second implementation of a capability the organization standardized centrally. It follows a locally optimal path that violates a system-level decision.
These changes may compile, pass tests, clear security scanning, and look reasonable to a reviewer who lacks the architectural history.
That is why architectural drift is not reducible to code quality or runtime security. It is a failure to preserve established engineering intent.
What platform leaders should require
Before treating self-hosted coding agents as a shared platform capability, teams should answer four questions:
- Which decisions form the decision corpus? Not every wiki page is policy. Authority and scope must be explicit.
- How does governance propagation work? The correct decision must reach the relevant repository, component, agent, and change.
- Which constraints can be enforced deterministically? Dependency rules and module boundaries may be machine-checkable; ambiguous trade-offs remain reviewable.
- What is the verification contract? Architectural enforcement should sit alongside tests, security checks, static analysis, CI, and human judgment.
This scales better than making code review responsible for remembering every decision the organization has accumulated.
The next question is what an authorized agent may build
The first enterprise questions about coding agents were about access: Can the model see our code? Where does execution happen? Which files and services can the agent reach? How are credentials protected?
Those questions remain essential. Self-hosted environments give enterprises another way to answer them.
The next question begins after all those controls succeed.
An authenticated agent is running in an approved environment. It has legitimate repository access. Its tools are correctly scoped. It receives a legitimate engineering task.
What ensures that the software it produces still conforms to the engineering decisions the organization has already made?
Security determines whether the agent may act. Infrastructure determines where it acts. Architectural governance determines which engineering decisions must remain true while it acts.
As coding agents become enterprise infrastructure, those controls need to operate as one system.