Suraj Khaitan

Posted on Aug 30

Claude Code Can Now Run on Your Own Infrastructure: The Architecture Explained

#ai #claude #cloud #agents

Anthropic's new self-hosted environments move Claude Code cloud-session execution into your network, next to private repositories, internal services, and company toolchains. But the model is not running in your data center, and not all session data stays there. Here is the architecture I would want every platform, security, and compliance team to understand before deploying a runner.

“Self-Hosted” Does Not Mean What Most People Think

When I first saw that Claude Code could now run on my own infrastructure, I pictured the model inside my cloud account, source and prompts staying in my tenant, and Anthropic receiving only usage metadata.

That is not what this release provides.

Anthropic has introduced self-hosted environments for Claude Code cloud sessions. The execution environment moves to infrastructure the customer operates. The Claude model, session control plane, queue, web interface, and transcript storage remain Anthropic-hosted.

That distinction is not a footnote. It is the architecture.

The runner inside my network checks out the repository, launches Claude Code, executes shell commands, starts builds, calls local MCP servers, and accesses internal systems. To reason about that work, however, Claude Code sends prompts, model responses, and relevant tool results to api.anthropic.com. Anthropic also stores the session transcript so I can resume the same cloud session from another supported surface.

So the honest one-sentence description is:

Claude Code's tools and working directory can now run on customer-controlled compute, while orchestration and model inference remain in Anthropic's cloud.

That is still meaningful. Many organizations need an agent that can compile a private monorepo, use a company CLI, reach a private package mirror, and test against services with no public endpoint. A runner in the company's Kubernetes cluster can.

The feature changes the placement of execution, not the location of intelligence.

Once that is clear, the rest of the architecture makes sense.

TL;DR

This is self-hosted execution, not a self-hosted Claude model. Claude Code processes and tools run on your machines; model inference still uses the Anthropic API.
It applies to cloud sessions. Developers can dispatch from claude.ai, mobile, desktop, scheduled routines, or the terminal. Ordinary terminal and IDE sessions already execute on the developer's machine.
Anthropic does not open an inbound connection into your network. Runners poll the Anthropic control plane over outbound HTTPS, and session processes stream events and make inference calls over outbound HTTPS.
Repository checkouts, build artifacts, files, and secrets stay on your infrastructure. Content Claude needs to reason over can still appear in prompts or tool results sent to Anthropic.
Private network access is the major benefit. Sessions can reach internal Git hosts, registries, databases, test environments, and local MCP services without exposing those systems publicly.
You own the runner image and fleet. That includes operating-system packages, language runtimes, compilers, internal CLIs, MCP servers, scaling, patching, observability, and incident response.
The safest production pattern is ephemeral and one session per runner. Anthropic recommends fresh containers or VMs, --capacity 1, default-deny egress, least-privilege identities, and short-lived per-session credentials.
Session identity is verifiable. Internal services can validate an Anthropic-signed JWT, identify the session creator, and exchange it for narrower, short-lived credentials.
Compliance is not automatic. Standard commercial retention is 30 days, session transcripts are Anthropic-hosted, and self-hosted environments are currently unavailable to organizations with Zero Data Retention enabled.
This is a public beta for Team and Enterprise. It is off by default and requires Claude Code on the web to be enabled.

What Anthropic Actually Released

Anthropic announced self-hosted environments on August 6, 2026. The feature arrived in Claude Code v2.1.224 and is in public beta for Claude Team and Enterprise organizations.

A self-hosted environment appears beside Anthropic-hosted environments when someone starts a cloud session. The control plane queues that task for a customer-operated runner instead of an Anthropic-managed virtual machine.

Three nouns matter:

Component	Responsibility
Environment	A named routing destination created in Claude admin settings. It groups one or more runners.
Runner	A long-lived process on customer infrastructure that polls for work, prepares repositories, and starts Claude Code session processes.
Session	One Claude Code task. Each session gets a checkout and a child Claude Code process on a runner.

An Owner enables Allow self-hosted environments under Cloud environments in the organization's Claude admin settings. The simplest bootstrap path is:

claude self-hosted-runner setup

The setup creates an environment, issues its secret, and starts a runner. In production, a platform team would usually deploy a pinned image through its existing compute platform.

Developers do not need a separate interaction model. They choose the environment when starting a cloud session from supported surfaces, or dispatch directly from a terminal:

claude -p "Investigate the failing payments integration tests" \
  --environment ccpool_example \
  --ref main \
  --output-format json

That command creates the remote session, prints its ID, and exits. Execution happens on the selected runner fleet.

This differs from Remote Control, which lets me continue a laptop session from a phone or browser. A self-hosted environment is shared infrastructure operated by a platform team for many users.

The Architecture at a Glance

Here is the simplest useful model:

 Developer surfaces                         Anthropic infrastructure
 ┌─────────────────────┐                   ┌───────────────────────────┐
 │ Web / mobile /      │  create session   │ UI + session control plane│
 │ desktop / terminal  ├──────────────────►│ queue + transcript store  │
 └─────────────────────┘                   │ model inference           │
                                           └─────────────┬─────────────┘
                                                         ▲
                                  outbound HTTPS polling │ events + inference
                                                         │
 ╔══════════════════════ Customer network boundary ══════╪════════════════╗
 ║                                                       │                ║
 ║  ┌─────────────────┐     spawn      ┌─────────────────┴────────────┐   ║
 ║  │ Runner or       ├───────────────►│ Claude Code session process │   ║
 ║  │ orchestrator    │                │ + isolated checkout         │   ║
 ║  └─────────────────┘                └──────┬───────────┬──────────┘   ║
 ║                                           │           │              ║
 ║                                      git clone     tools / MCP       ║
 ║                                           │           │              ║
 ║                                  ┌────────▼───┐  ┌────▼────────────┐ ║
 ║                                  │ Private Git│  │ Internal APIs,  │ ║
 ║                                  │ host       │  │ DBs, registries │ ║
 ║                                  └────────────┘  └─────────────────┘ ║
 ╚═══════════════════════════════════════════════════════════════════════╝

The important network property is that Anthropic does not initiate a connection into the customer network. The runner polls api.anthropic.com for work and heartbeat; child processes open outbound connections for event streaming and inference. Session streaming uses server-sent events over HTTPS. The optional source-control connector is the documented WebSocket path.

This outbound-only model fits enterprise networks better than an inbound webhook or remote shell. A security team can place runners in a dedicated subnet or Kubernetes namespace, deny inbound traffic, and tightly allowlist outbound destinations.

But outbound-only does not mean data-local. It describes connection direction, not data residency.

The Actual Data Flow, Step by Step

The best way to understand the system is to follow one session from request to completion.

1. A developer creates a cloud session

The developer starts from claude.ai, the desktop or mobile app, a scheduled routine, or claude --cloud and selects the company's self-hosted environment.

Anthropic's control plane creates the session and places it on that environment's queue. The user's prompt begins on an Anthropic surface and becomes part of the cloud-session transcript.

2. A runner claims the session

A runner with available capacity polls the queue, claims the session, and receives a lease. Regular polling refreshes that lease. If the runner disappears for roughly 60 seconds, the control plane can requeue the session for another runner.

The runner registers with an environment secret and receives a runner token. With on-demand runners, that secret stays on an orchestrator that never executes user code; temporary runners receive single-use work orders.

3. The repository is prepared inside the customer network

The runner clones the selected GitHub or GitHub Enterprise repository into its working directory. The clone can go directly to an internal Git host over HTTPS or SSH using credentials the customer provides.

An optional checkout hook can use an internal mirror, apply per-session Git credentials, or bridge another source system.

At this point, the working tree is physically on customer compute.

4. The runner starts a child Claude Code process

Each session runs as a Claude Code child process with a scoped inference token and a signed JWT identifying the session and creator. The process gathers context, calls the Anthropic API, receives model output, and executes approved tools locally; the model does not run in the container.

5. Context crosses the boundary for inference

To answer the developer, Claude needs context. User prompts, assistant responses, and tool results are sent to api.anthropic.com over TLS.

The checkout stays on the runner, but source Claude reads can be included in a tool result sent for inference. Shell output and MCP responses can also become model context.

The file and the copy on disk stay local. The information Claude reads does not necessarily stay local.

6. Tools execute from inside the customer network

When Claude decides to run a test, invoke a compiler, query a local MCP server, or call an internal API, that action originates from the runner container.

The session sees the runner's private DNS, package mirrors, approved services, and installed tools without exposing internal services publicly.

7. Events stream back to Anthropic

The child process streams session events over outbound HTTPS. These events allow the web, mobile, and desktop interfaces to show progress, tool activity, permission prompts, and responses.

Anthropic stores the transcript for cross-surface resumption, one reason self-hosted environments cannot currently serve ZDR-enabled organizations.

8. Code changes are committed or pushed

Git commands execute on the runner. The session can commit to its local working branch and, when credentials and policy allow it, push to the configured remote.

The customer controls Git identity and credentials. Production deployments should mint short-lived, session- and repository-scoped tokens, with branch protection and CI enforcing delivery.

9. The runner cleans up

When the child exits, a post-session lifecycle hook can archive logs, emit an internal audit event, or preserve uncommitted work. Then the runner cleans up the session workspace according to its mode.

For strong isolation, the entire runner container or VM should be destroyed. A fresh instance should handle the next session.

What Stays Local and What Does Not

This is the table I would put in front of a security review board:

Data or operation	Customer infrastructure	Anthropic infrastructure
Repository checkout on disk	Yes	No full checkout created by the runner architecture
Files created or modified by tools	Yes	Relevant content may appear in session context
Build artifacts and caches	Yes	Not automatically uploaded
Shell commands and test execution	Yes	Tool requests and results can be in the transcript
Internal service connections from local tools	Yes	No inbound connection into the customer network
Prompts and model responses	No	Yes
File content Claude reads	Source remains local	Relevant content can be sent for inference
Tool and MCP results Claude receives	Produced locally for local tools	Included in conversation context as needed
Session queue and orchestration	No	Yes
Session transcript and resumability	No	Yes
Model weights and inference	No	Yes, through the Anthropic API
Git credentials supplied by the customer	Yes	Not required to leave when Git is reached directly
Anthropic-delivered connector calls	No	Yes; connector traffic originates from Anthropic

The phrase “source code stays on your infrastructure” needs careful interpretation. The source checkout and build workspace stay there. This is useful for artifact custody, filesystem policy, private network access, and operational control. It does not mean no source text is processed by Anthropic. Claude cannot reason about code it never receives.

For Team and Enterprise customers under commercial terms, Anthropic states that it does not train generative models on Claude Code prompts or code unless the customer explicitly opts into a program that provides data for model improvement. Standard commercial retention is 30 days.

That may satisfy many enterprise policies. It will not satisfy every data-locality requirement.

Why Private Network Access Changes the Enterprise Story

Cloud coding agents and private enterprise environments often live on opposite sides of a wall. A repository alone is not the development environment, which can also depend on:

a private GitHub Enterprise instance;
an internal npm, Maven, NuGet, PyPI, or container registry;
a monorepo build cache;
proprietary compilers and SDKs;
schema registries and service catalogs;
ephemeral integration-test environments;
internal documentation search;
observability and incident systems; and
internal CLIs that encode platform knowledge.

A self-hosted runner can sit near those systems.

The platform team builds an image with pinned runtimes, Claude Code, build tools, certificates, internal CLIs, company instructions, hooks, policies, and local MCP servers.

For example:

FROM debian:bookworm-slim

ARG CLAUDE_CODE_VERSION

RUN apt-get update && apt-get install -y --no-install-recommends \
    git curl ca-certificates openssh-client jq \
 && rm -rf /var/lib/apt/lists/*

RUN curl -fsSL \
    "https://downloads.claude.ai/claude-code-releases/${CLAUDE_CODE_VERSION}/linux-x64/claude" \
    -o /usr/local/bin/claude \
 && chmod +x /usr/local/bin/claude

COPY company-cli /usr/local/bin/company-cli
COPY managed-mcp.json /etc/claude-code/managed-mcp.json

ENTRYPOINT ["claude"]

That image is not merely packaging. It becomes the reproducible execution contract for enterprise Claude Code sessions.

There is one connector nuance teams should not miss. Claude.ai connectors such as GitHub, Slack, or Linear are invoked from Anthropic's infrastructure, even during a self-hosted session. If connector traffic must stay inside the company network, the equivalent capability should be exposed as a local MCP server on the runner and Anthropic-delivered connectors should be denied through managed MCP policy.

Internal Services Need Session-Aware Authorization

Putting the runner inside a trusted subnet does not make every session trusted.

A runner executes model-directed code on behalf of users who can dispatch sessions to its environment. Network location tells an internal service where the request came from. It does not reliably tell the service who requested the work, which session is acting, or what that session should be allowed to do.

Anthropic addresses this with CLAUDE_CODE_SESSION_ACCESS_TOKEN, a signed JWT available inside each self-hosted session.

An internal service can verify:

the sk-ant-cc- token prefix;
the ES256 signature against Anthropic's published JWKS;
issuer ccr;
the audience containing the expected environment ID;
role session_worker;
token expiry;
the session and organization identifiers; and
the act chain identifying the user or service identity that created the session.

The JWKS endpoint is:

https://api.anthropic.com/v1/code/.well-known/jwks.json

The useful design is not “JWT accepted, therefore give Claude the user's full access.” The useful design is token exchange:

session JWT
    │
    ▼
internal token broker
    │ verify signature, issuer, audience, role, expiry, creator
    │ evaluate repo + environment + task policy
    ▼
short-lived, task-scoped credential
    │
    ▼
specific internal API or repository

The derived credential should be narrower than the human's access, expire no later than the session token, and carry the session ID in audit records. The JWT remains a bearer token available to session code, with no published revocation feed. Verification proves Anthropic issued it for that environment, not that a particular trustworthy process holds it.

That is why the downstream credential must represent one coding session, not the full employee identity.

The Compliance Value Is Real, but Narrower Than “Everything Stays Here”

Self-hosted environments improve several controls that matter during enterprise review:

Workload placement: the organization chooses the region, account, subnet, cluster, storage, encryption, image provenance, patch cadence, and deletion behavior for checkouts and builds.
Network policy: existing egress proxies, mTLS, private DNS, firewalls, and network telemetry can govern sessions.
Toolchain governance: teams can pin binaries, trust approved package sources, scan images, and promote them through supply-chain controls.
Credential governance: secrets can come from the customer's vault or token broker and disappear with the session container.
Audit correlation: runner, network, Git, cloud, and internal-service events can carry a Claude session ID; the Compliance API provides transcript content and metadata on supported surfaces.

But self-hosting does not automatically deliver a compliance outcome.

The control plane and transcript remain outside the customer environment. Model context goes to Anthropic. The current beta cannot route inference through Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, or an enterprise LLM gateway. Self-hosted environments are also unavailable to ZDR-enabled organizations because cloud sessions require server-side transcript storage.

There is another subtle limitation: the current Compliance API coverage described by Anthropic includes Claude Code CLI and desktop sessions, but excludes Claude Code on the web. A self-hosted environment is fundamentally a cloud-session feature. Compliance teams should confirm exact coverage with their Anthropic account team rather than assuming every self-hosted session appears in every export.

The right compliance statement is therefore:

Self-hosting gives the customer control over the execution plane. It does not transfer the entire Claude Code service or inference data plane into the customer environment.

Fixed Runners Versus On-Demand Runners

Anthropic supports two fleet models.

Fixed fleet

A fixed fleet stays online and polls for work, making startup predictable. It also leaves the environment secret on hosts executing model-directed code, may preserve writable layers, costs money while idle, and can strand users when runners lock to other owners.

On-demand fleet

A separate orchestrator polls for sessions that have no runner available. It invokes a spawn-runner hook that creates a Kubernetes Job, VM, Nomad allocation, or equivalent workload for that session.

This is the architecture I would prefer for production:

the long-lived environment secret stays on the orchestrator;
the orchestrator never executes session code;
each runner receives a signed, single-use work order;
each workload serves one session at --capacity 1;
the container starts with a clean filesystem; and
the entire workload disappears after completion.

The cost is cold-start latency and a more sophisticated platform integration. The spawn hook must be idempotent, workloads must not retry blindly, and expected startup time should reflect the platform's p99 rather than its happy path.

For evaluation, a fixed runner in Docker Compose is reasonable. For sensitive production access, per-session ephemeral runners are the stronger default.

The Production Security Architecture I Would Use

If I were putting this in front of an enterprise architecture review, my reference design would include the following controls.

1. A dedicated environment and network segment

Give Claude Code runners a dedicated namespace, node pool, security group, or account boundary rather than placing them beside unrelated production workloads.

Allow no inbound path from Anthropic. Permit outbound access only to:

api.anthropic.com on port 443;
the approved Git host, unless using Anthropic's Git proxy;
explicitly required Anthropic download or documentation hosts;
approved internal APIs and package registries; and
the corporate egress proxy, when used.

The product cannot enforce this allowlist. Apply default-deny at the network layer; Bash permissions are not an egress boundary.

2. Ephemeral, single-session compute

Run each session in a fresh container or VM with --capacity 1 and the default drain grace of zero. Destroy the writable filesystem when the runner exits.

Do not treat a Git hard reset as sanitization: untracked files can survive checkout reuse.

3. No broad credentials in the image

Never bake broad tokens or cloud keys into the image. Verify session identity, mint narrowly scoped credentials, and block 169.254.169.254 so code cannot inherit the host identity.

4. Read-only operator configuration

Mount hooks, wrapper scripts, managed settings, and the host Claude configuration read-only. A session should not be able to rewrite the policy that launches it or modify a post-session hook that later runs with operator credentials.

Enable the repository-settings confinement guard in enforcement mode. Repository-controlled settings should not be allowed to grant writes outside the workspace, inject arbitrary environment variables, or disable the operator's sandbox posture.

5. Managed MCP allowlists

Use the enterprise managed MCP file to define the servers every session may load. Prefer local MCP servers for internal tools whose calls must remain inside the network.

Publish narrow tools with typed inputs, server-side authorization, bounded responses, and immutable audit events instead of a general internal HTTP client.

6. Branch protection as the delivery gate

Let the agent prepare code, tests, commits, and a pull request. Keep merge and deployment behind independent CI, CODEOWNERS, security checks, and human approval.

Limit pushes to agent branches where practical, and keep production deployment credentials out of the runner.

7. Version pinning and image promotion

Sessions use the same Claude Code binary installed in the runner image, and automatic updates are disabled for the child processes. Pin the version, scan and sign the image, test it in a dedicated self-hosted environment, and promote it using the same controls as any other build platform.

Extend Anthropic's end-to-end session test to exercise private Git, an internal MCP tool, credential exchange, push permissions, cleanup, and denied egress.

8. Operational telemetry and a kill path

Capture runner and failure logs, platform events, Git audits, token-broker decisions, MCP calls, and network denies. Alert on stale polling, queues, setup failures, unusual duration, denials, and restarts. Test how to disable the environment, rotate its secret, revoke credentials, and terminate workloads.

Two Product Details That Could Surprise Platform Teams

Dispatch does not currently have per-environment access control

Anthropic's production guidance says any member of the organization can dispatch to any of its environments. An Owner can enable or disable self-hosted environments, but the beta does not provide a fine-grained ACL saying only Team A may use the payments-production-like runner.

That means the environment itself must not be treated as an authorization boundary.

Only place data and baseline capabilities on a runner that every potential dispatcher is allowed to encounter. Enforce real authorization at Git, token exchange, MCP, and internal service layers using verified session identity. Separate Anthropic organizations may be necessary where populations require hard isolation, but that decision should be validated with Anthropic.

A runner is locked to one owner at a time

The first session a runner claims locks that runner to the session owner. It can run additional concurrent sessions for the same owner up to its configured capacity, but it does not serve another owner until it drains and exits.

This prevents checked-out code from mixing between owners, but it changes capacity planning. Four slots on one runner do not necessarily serve four developers. The minimum useful fleet is closer to the number of simultaneously active owners than the number of simultaneous sessions divided by capacity.

On-demand, one-session runners avoid much of that scheduling surprise.

A Practical Enterprise Rollout

I would not connect the first successful runner to sensitive internal services. I would use five stages.

Stage 1: Architecture and data review

Document every boundary before deploying:

which prompts, responses, code excerpts, and tool results reach Anthropic;
transcript retention and deletion behavior;
allowed repositories and data classifications;
required internal destinations;
connector traffic that leaves the network;
identity and credential exchange;
logs, audit ownership, and incident response.

Get written agreement that “self-hosted” means execution-plane control, not local inference.

Stage 2: Disposable sandbox

Use synthetic repositories and no valuable credentials to learn registration, owner locks, cloning, proxies, resumption, and shutdown.

Stage 3: Golden runner image

Build a pinned, non-root image with approved tools, read-only configuration, and managed MCP policy. Scan it, generate an SBOM, verify the binary, and smoke-test it.

Stage 4: On-demand identity-aware access

Move to ephemeral one-session runners, JWT verification, and a token broker. Begin with low-risk read access and narrow Git push rights.

Test the negative cases: wrong audience, expired token, service-identity session, blocked metadata endpoint, prohibited repository, denied destination, and compromised session attempting credential reuse.

Stage 5: Production operations

Add autoscaling, budgets, timeouts, dashboards, upgrade rings, and a kill switch. Measure accepted PRs, latency, queue time, denials, review effort, and incidents.

Expand access only when a real workflow requires it.

When I Would Choose Self-Hosted Environments

I would choose them when at least one of these is true:

the repository or Git host is reachable only from a private network;
builds depend on proprietary SDKs or licensed compilers;
internal package mirrors and build caches materially affect reliability;
the agent needs approved access to private services or databases;
the company must control where checkouts and artifacts are created;
runner images must pass internal supply-chain policy;
credentials must be issued through a company token broker; or
local MCP services are the approved interface to internal tooling.

I would keep Anthropic-hosted environments when repositories and dependencies are already reachable, standard images are sufficient, and the organization does not want to operate another privileged compute fleet. Anthropic explicitly says its hosted offering is the better fit for most enterprises because there is no runner infrastructure to maintain.

I would not choose the current self-hosted beta when the hard requirement is that prompts, code excerpts, and tool results never leave the customer boundary; when inference must route through Bedrock, Google Cloud, Microsoft Foundry, or a custom gateway; or when the organization requires ZDR for these sessions.

Self-hosting should solve an actual network, tooling, or compliance constraint. It should not be adopted because the label sounds safer.

FAQ

Is Claude itself running in my VPC or data center?

No. The Claude Code agent process and its tools run there. Model inference uses the Anthropic API, and the control plane remains Anthropic-hosted.

Does my source code stay entirely inside my network?

The repository checkout, build artifacts, files, and secrets remain on infrastructure you provision. Content Claude reads can be sent to Anthropic as model context or tool results. Do not interpret local checkout custody as zero source-content egress.

Does Anthropic need inbound access to my network?

No. The runner polls the queue over outbound HTTPS, and child sessions make outbound event-stream and inference connections. Corporate egress proxies and mTLS configuration are supported.

Can Claude reach private APIs and databases?

Yes, if the runner's network and credentials allow it. Use network segmentation, default-deny egress, verified session identity, and task-scoped credentials rather than relying on subnet trust.

Can I use Amazon Bedrock, Google Cloud, Microsoft Foundry, or my LLM gateway?

Not for inference in self-hosted environments today. The control plane supplies the Anthropic API endpoint and a session-scoped Anthropic OAuth token.

Does this work with Zero Data Retention?

No. Self-hosted environments are currently unavailable to ZDR-enabled organizations because cloud sessions store transcripts for session continuity.

Which plans support it?

The public beta is available to Claude Team and Enterprise organizations. It is off by default and must be enabled by an Owner.

Can every employee use every self-hosted environment?

The current production documentation says dispatch has no per-environment access control. Treat everyone who can dispatch as capable of causing code to run there, and enforce resource authorization downstream.

Should I run multiple sessions in one runner?

The product supports capacity above one for sessions owned by the same account. For production isolation, Anthropic recommends ephemeral containers or VMs with --capacity 1.

Who should own this platform?

A platform engineering, developer productivity, or developer experience team should own the image, fleet, network, credentials, policies, observability, upgrades, and incident response. This is not a one-time admin toggle.

Final Take: The Runner Is the New Enterprise Boundary

Claude Code self-hosted environments solve a real architectural problem.

They place agent execution beside private source control, toolchains, registries, builds, test environments, and company APIs while the organization controls compute, network, credentials, scaling, and telemetry.

But the value disappears when the feature is described inaccurately.

The model is not self-hosted. The control plane is not self-hosted. Prompts, responses, and tool results still cross the boundary. Session transcripts remain on Anthropic's infrastructure. The current beta is not compatible with ZDR, cannot route inference through another provider, and does not provide per-environment dispatch ACLs.

That does not make the architecture weak. It makes it a hybrid agent architecture:

Anthropic operates the interaction, orchestration, transcript, and intelligence layers;
the customer operates the execution, network, toolchain, credential, and artifact layers.

The security outcome depends on the contract between those halves.

If the runner is ephemeral, egress is default-deny, identity is verified, credentials are session-scoped, internal tools authorize every action, and pull requests remain behind independent review, this can be a strong enterprise pattern.

If the runner is a long-lived VM with production routes, shared disks, broad secrets, and an assumption that “inside the VPC” means trusted, self-hosting simply moves the agent closer to the blast radius.

For me, that is the real lesson of this release:

Owning the compute does not remove the trust boundary. It gives you the responsibility to design it.

Sources and Further Reading

About the Author

I am Suraj Khaitan, an AI and cloud engineer focused on production agents, Claude Code, MCP, RAG, and serverless architecture. I write practical deep dives for engineers who want to move past demos and build AI systems that are reliable, observable, secure, and economically sane.