Your AI Runs on Your Infrastructure. Who Controls It?

Claude Code moved the infrastructure conversation forward this week. On August 6, Anthropic announced a public beta that lets Claude Code cloud sessions run on infrastructure controlled by the customer. Repository checkouts, build artifacts, secrets, and files created during a session can stay inside infrastructure the customer provisions.

That is a meaningful enterprise feature. It is also easy to misunderstand.

Running an AI session on infrastructure your team controls is not the same as controlling the AI operation. The model may still process prompts, responses, and tool results outside your network. Session transcripts may still be stored by the vendor. The vendor may still control model updates, policy behavior, session routing, and parts of the observability layer.

For operational AI, that distinction matters more than the location of a server.

Infrastructure is only one boundary

When a local service business evaluates AI for calls, dispatch, quoting, or accounting, the workflow usually looks simple from the outside:

• A customer calls about an HVAC repair.
• The AI captures the address, equipment details, and urgency.
• A scheduling system checks crew availability.
• A quote is generated from pricing data.
• An invoice is created in QuickBooks.
• A person reviews an uncertain case.

The AI operation crosses several technical boundaries. Infrastructure is only one of them.

A useful evaluation asks where each part of the workflow executes and who has authority over it:

Component	Questions that matter
Customer data	Where are audio, transcripts, addresses, and payment details processed and stored?
Model inference	Does data leave your environment for inference? Can the provider retain it or use it for evaluation?
Tool calls	Where does the agent request scheduling, dispatch, CRM, or accounting actions?
Credentials	Who issues, rotates, scopes, and revokes the credentials used by the agent?
Logs	Who can inspect prompts, tool results, decisions, and failed actions?
Human handoffs	Where does an unresolved case go, and who owns the queue?
Policy changes	Can the vendor change model behavior or system instructions without your approval?

If a vendor answers only the infrastructure question, you have learned very little about operational control.

The execution boundary is the real unit of analysis

The most important question is not, "Where does the AI run?" It is, "What can the AI cause to happen, and what stands between its output and that action?"

Suppose an AI receptionist identifies a customer, creates a job, and schedules a technician. The model may run inside your network, but the scheduling API may be hosted elsewhere. The API credential may be managed by the vendor. The decision log may exist only in a vendor dashboard. The human escalation queue may be delivered through a third-party ticketing system.

In that design, your infrastructure hosts one part of the operation. It does not necessarily control the operation.

The same issue appears in finance. An accounts-payable agent might extract invoice fields inside your environment, then send the extracted data to a hosted model. It might call QuickBooks using a shared service account. It might write its confidence score to a vendor database that your accounting team cannot export. If something goes wrong, you may control the compute but lack control over the evidence needed to understand the decision.

That is operational ownership in reverse.

What customer control should actually provide

Customer-controlled infrastructure can be valuable. It can help keep repositories, temporary files, secrets, and internal network access within a boundary you manage. It may simplify certain requirements around access control, network segmentation, and data residency.

But those benefits depend on the rest of the architecture. At minimum, buyers should expect control over five things.

First, data flow. You should be able to identify every category of data that leaves your environment, including prompts, audio, transcripts, tool results, metadata, and error reports. "We do not train on your data" is not a complete answer. Ask whether the data is retained, sampled for abuse monitoring, accessible to support staff, or transferred to subprocessors.

Second, action authority. Every tool call should have a defined scope. An agent that can create a draft invoice needs different permissions from one that can approve payments. A dispatcher may need to suggest a crew without being allowed to overwrite a confirmed appointment.

Third, evidence. You need logs that show what the system received, what it proposed, what tools it called, what changed, and whether a person approved the action. These records should be exportable in a usable format, not trapped in a dashboard.

Fourth, change control. Ask who can change the model, system prompt, tools, routing rules, safety policies, and default behavior. A vendor-managed update can change an operational workflow even when your infrastructure and application code remain untouched.

Fifth, intervention. Your team should be able to pause the agent, revoke credentials, disable a tool, route work to a person, and recover queued tasks. Control that exists only during a successful session is not control you can rely on during a failure or investigation.

The questions buyers should ask vendors

Use these questions in a technical review or procurement call:

• Which data is processed outside our network, and for how long is each category retained?
• Does the session transcript leave our environment? If so, who can access it?
• Where do tool calls execute, and can we enforce an allowlist of approved actions?
• Are credentials customer-owned, short-lived, and scoped per workflow or user?
• Can we inspect and export complete logs, including rejected actions and human approvals?
• How are model, prompt, policy, and connector changes announced and approved?
• Can we pin a model or version, and what happens when that version is retired?
• Can we suspend the agent without disabling the underlying business systems?
• What happens to in-progress calls, jobs, quotes, and invoices when a session is interrupted?
• Which parts of the workflow remain functional if the vendor loses access to its control plane?
• Can our staff review and correct uncertain outputs before they change customer or financial records?
• What is the documented process for deleting data, credentials, logs, and session artifacts?

These questions test authority, visibility, and reversibility. They also expose whether "self-hosted" describes a real control boundary or simply a different place for the vendor's runtime to operate.

A better way to compare deployment models

This is not a cloud-versus-on-premise argument. Both models can be designed well or badly.

A hosted system may provide stronger managed operations, faster updates, and better vendor support. A customer-controlled deployment may provide tighter network boundaries and more direct control over artifacts. Neither option automatically gives you governance, auditability, or safe action design.

Compare deployments by control points instead:

• Who can see the data?
• Who can authorize an action?
• Who can change the behavior?
• Who can prove what happened?
• Who can stop the system?
• Who owns recovery when the workflow is incomplete?

That framework extends the lesson from The CEVA Lesson: Map Your AI Blast Radius. The question is not simply where a system is hosted. It is how authority and evidence move across the systems connected to it.

Reeve applies this operational perspective to calls, dispatch, quoting, invoices, and QuickBooks workflows, where the useful boundary is the one that preserves context and gives your team clear control over consequential actions.

Before you buy an AI system, ask the vendor to draw the full execution boundary. If they cannot show where data, credentials, tool calls, logs, and human decisions live, you are not evaluating infrastructure control yet. You are evaluating a promise.