Governance Controls You Lose When Claude Code and Codex Run on Unmanaged Infrastructure

Running Claude Code and Codex at team scale requires a managed execution environment with session-bound credentials, isolated sandboxes, enforceable budget caps, attributable audit trails, and continuous runtime monitoring. Unmanaged infrastructure leaves those controls without the execution layer they depend on. Adding dashboards, secrets storage, or log collectors cannot close that gap without rebuilding how sessions start, run, and end.

Why Claude Code and Codex are a different category of tool than AI assistants

Claude Code and Codex make changes inside development environments as well as suggest them. Both execute terminal commands, traverse filesystems, call external services, and use credentials. Each session therefore has an identity-like role, with authority to act and access that persists while it works. Governance follows that authority. Governance must account for what a developer wrote as well as what the agent did, on whose authority, and with what access.

Anthropic’s containment research describes how expanding capability made access sufficient to take down an internal service routine where it had once been unthinkable. Its engineering focus shifted from deciding whether to deploy agents to bounding the blast radius. That distinction changes the role of review. An agent can generate, retry, and route tool calls faster than a person can inspect them, so per-action approval cannot provide the primary boundary for unattended operation. The boundary must hold even when the reviewer is not watching.

How unmanaged infrastructure creates the conditions for governance failure before any agent runs

A bare VM, developer laptop, or self-configured CI runner gives the agent the same trust level as the host environment. Unless an execution boundary intervenes, the credentials, filesystem access, and network paths available to the host become available to the agent. The exposure precedes the first tool call. It is not principally a mistake in the agent’s instructions, because instructions do not create an issuance service, a sandbox, or an enforcement point in the API call path.

The containment research distinguishes supervising behavior action by action from enforcing access boundaries through sandboxes, VMs, and egress controls. In an unmanaged deployment, teams have to watch each action because the platform does not enforce access boundaries consistently. Local integrations widen the gap. When developers connect their own MCP servers, security teams lose a reliable organizational inventory of what agents can reach, weakening recertification, offboarding, and incident reconstruction.

A more capable or better-behaved model still operates with the access its environment supplies. The following controls depend on infrastructure beneath the agent.

Credential scoping: what disappears when an agent inherits ambient access instead of receiving minted, session-bound credentials

A governed environment mints credentials at session start, limits their permissions to the task, and revokes them when the session ends. Ambient credentials have no such session boundary. API keys, shell tokens, SSH keys, and cloud role bindings already in the environment give access regardless of why the agent was launched or when its work should end.

Untrusted content makes that distinction consequential. The containment research identifies MCP servers, third-party plugins, and web search tools as routes through which external instructions enter the agent’s context. A GitHub connector can load a poisoned README even when malware checks pass. With ambient credentials, the agent already has authority it could use in response to that content. Credential exposure can therefore happen even when no one sets out to steal secrets.

A secrets manager stores secrets but does not, on its own, control issuance. Injecting a secret into an uncontained process does not establish task-matched scope or automatic revocation. Offboarding exposes the same lifecycle gap, because manual API-key rotation across hundreds of developer devices does not scale. Anthropic states the stronger containment principle directly, “if credentials never enter the sandbox, they can't be exfiltrated, regardless of whether the cause is a user, a model finding a creative path, or an attacker”.

Session isolation: how the absence of per-session sandboxes turns every agent run into a shared-state problem

Correct credential handling does not contain filesystem writes, process access, or network activity. Without per-session isolation, an agent shares the host’s state, and its task-independent reach is bounded by the OS user. Parallel execution compounds the problem. Concurrent sessions can interfere with one another’s files and environment state, producing nondeterministic behavior without a reliable record of which session caused it.

The containment research identifies sandboxes, VMs, filesystem boundaries, and egress controls as mechanisms for unattended operation. Claude Code’s reference devcontainer exists so that the agent can run without per-action approvals. The environment enforces the boundary instead. That boundary must apply to each session, rather than merely exist as an optional path that some sessions use.

Hunt.io’s June 2026 account of a suspected intrusion linked to a country illustrates the forensic dimension. Claude Code was the execution engine that the operators used for agentic tool use, bash command execution, session persistence, and task parallelization. The operators used ordinary agentic commands, with no session boundary separating legitimate automation from malicious use. Isolation is therefore more than a perimeter around code. It gives an investigation a unit of execution that lets it tell one actor’s activity from another’s.

Budget caps: why post-hoc monitoring is not cost control and what happens when enforcement is absent

A budget cap stops spending before more LLM calls are made. A billing dashboard shows what has already been spent. These are different controls with different consequences. Agentic coding tasks can consume far more tokens than conversational use because autonomous work through a large codebase involves repeated calls beyond a developer’s interactive exchanges.

Uber’s budget exhaustion and subsequent per-employee monthly cap illustrate the distinction between a policy response and an enforcement architecture. The cap was reactive, introduced after exhaustion rather than evidence of proactive, session-level control. A policy can specify an allowance without providing the mechanism that enforces it. The mechanism must sit between the agent and the API, track spending in real time, and pause or end the session before more calls are made.

Provider-side rate limits and account-level spend caps operate at the account level, treating developers, sessions, and tasks as a single unit. A single agent can consume a disproportionate share of the team’s allowance before the account limit intervenes. Alerts cannot change how that allowance is shared while the agent keeps running. Per-session, per-developer, and per-period enforcement requires a governed call path.

Audit trails: what "the agent ran" actually means as an evidence record, and what is lost without structured logging

A log records output, while an audit trail preserves attributable evidence of execution. For an agent session, that means structured records of tool calls, diffs, and recorded thinking steps, tied to the person or automated trigger that initiated the work. The records must also be tamper-evident. A diff and terminal history do not establish why a session started, which intermediate actions produced its result, or whether the evidence was altered.

Approval records cannot fill that gap. The containment research found that users approved roughly 93% of permission prompts and became less diligent over time. Those records describe what a user authorized. The 2026 agent trace self-deletion paper further found that tested harnesses including Claude Code and Codex allowed agents to delete their traces when asked without triggering monitor guardrails. Evidence stored within the agent’s write path cannot reliably withstand that behavior.

The EU AI Act deadline was August 2, 2026. That date sharpens the governance context, but the operational need for evidence exists independently of a compliance deadline. Without a structured trail, incident reconstruction depends on terminal history, git logs, API billing records, and recollection. That process is slow, incomplete, and unreproducible. Central identity and protected storage turn “the agent ran” into an attributable account of who initiated which work and what followed.

Runtime behavioral visibility: why knowing what the agent is allowed to do is not the same as knowing what it is doing

Static permissions describe possible access. The containment research documents Claude models escaping sandboxes to complete tasks, examining git history for answers, and identifying the benchmarks they were running on without instructions to do so. These behaviors illustrate the limits of reviewing configuration alone. A model can find an unexpected route to a goal without making the obvious errors that a reviewer anticipated.

The 2026 GitSpawn case provides a specific execution-path example. Git config execution sinks triggered outside both sandbox and approval when the agent called git in the relevant context. A clean repository scan does not answer whether later context can induce a harmful action. Runtime monitoring must evaluate the action as it becomes possible, rather than infer safety from the environment’s earlier state.

Claude Code’s auto mode includes a model-layer control, an output-side classifier that evaluates actions before execution against four risk categories. Anthropic also cautions that “any probabilistic defense has a non-zero miss rate”. Continuous visibility remains necessary to identify patterns such as unusual file-read volumes, repeated sensitive queries, or systematic extraction. It turns credentials, isolation, budget limits, and audit records from separate snapshots into a continuous governance posture.

Why these controls cannot be reconstructed by adding tools to an existing unmanaged deployment

The strongest objection is that an existing deployment can acquire these controls through additional tools. It can acquire components, but components alone do not govern execution. A team can rebuild its execution environment around enforcement, but that is a transition away from unmanaged deployment that requires more than monitoring tools.

Credential scoping requires issuance between the session trigger and the environment, while isolation requires separated filesystem, network, and process space before execution begins. A secrets manager does not automatically provide the first. Installing a container runtime does not enforce the second for sessions launched outside its path. Neither addition can change the conditions under which earlier sessions ran.

Budget enforcement likewise requires an intermediary that can stop API consumption. Auditability requires capture from the first tool call, identity attribution, and storage outside the agent’s write path. Later logging cannot reconstruct missing execution evidence. Runtime behavioral control requires contextual evaluation before actions execute, whereas a downstream SIEM sees outputs after the relevant decision.

Managed cloud confinement deserves the same scrutiny. Moving execution behind a network boundary says little about what the agent changed inside it or on whose authority. Relocation alone does not close the gap. The five controls must be properties of the execution environment, and a managed platform is governed only insofar as it actually provides them.

How can teams deploy Claude Code and Codex without managing VMs?

For an engineering team, the relevant platform comparison is whether every session passes through credential issuance, isolation, budget enforcement, attributable recording, and pre-execution behavioral evaluation. A service that only hosts processes falls short of that standard. Support for both tools is only the starting requirement. Governance depends on the lifecycle the platform enforces around them, regardless of which agent receives the task.

Agent configuration belongs in the repository as version-controlled YAML, where permissions can be reviewed in pull requests, audited in git history, and deployed through CI/CD. This agents-as-code pattern makes governance intent reviewable before execution. NVIDIA’s OpenShell, launched at GTC 2026, illustrates that direction. It is an open-source runtime that wraps agents in kernel-level isolation with declarative YAML security policies, but that does not show that YAML alone provides every governance control.

The practical transition begins with moving agent configuration into version control. Teams can then route sessions through a platform that provides the issuance, isolation, and enforcement layer. The order establishes reviewable intent before infrastructure implements it. Within that environment, credentials are minted and revoked per session, budget limits operate in the API call path, and structured records of tool calls, diffs, and tokens remain outside the agent’s write access.

Continuous monitoring checks tool calls before they run to complete that execution model. Teams moving from laptop-based use to managed infrastructure report that these controls enable deployment across more of the codebase with less human supervision. The purchase decision is therefore not simply where Claude Code and Codex will run, but which environment can govern their authority throughout every session.