Your Coding Agent Is an Unmanaged Endpoint: Runtime Security Controls for Copilot, Claude Code, and Codex

Your security team spent years getting every laptop enrolled in MDM, every endpoint under EDR, every SaaS app behind SSO. Then engineering installed coding agents, and now there is a process on every developer machine that reads arbitrary files, executes arbitrary shell commands, holds ambient access to every credential in the environment, and takes instructions from text it downloads off the internet. Nobody filed a ticket. It does not show up in your asset inventory. It is, by any reasonable definition, an unmanaged endpoint - and it is one that follows instructions.

This is not a hypothetical framing. When researchers went after Claude Code, Copilot, and Codex this year, every successful exploit went for the credential, not the model. Nobody bothered jailbreaking anything. They hid instructions in the places agents read - repo files, issues, dependency metadata - and let the agent do what agents do: run commands, read files, make network calls. The model behaved exactly as designed. The runtime around it had no boundaries.

The fix is not a better system prompt. It is the same discipline you already apply to CI runners and production workloads: a filesystem boundary, a network policy, a credential scope, and an audit trail. This post lays out that control set and maps it to what Copilot, Claude Code, and Codex ship today.

Why the attacks skip the model entirely

The pattern across the 2026 disclosures is consistent enough to be boring. Ken Huang's analysis of in-the-wild incidents across Claude Code, Codex, Copilot, and Cowork shows the same kill chain repeating: untrusted content enters the context (a README, a linked issue, a package's install script output), the content contains instructions, the agent has both the tool access to read secrets and the network access to send them somewhere. Done.

Simon Willison named this combination the lethal trifecta: private data access, exposure to untrusted content, and the ability to exfiltrate. Coding agents are the purest expression of it. A support chatbot might have two of the three. A coding agent on a default install has all of them, plus shell execution, and it runs on the one class of machine in your fleet that holds cloud admin credentials, signing keys, and production database strings in dotfiles.

The OWASP LLM Top 10 catalogs prompt injection as LLM01, and it is worth internalizing why it sits at the top: there is no reliable way to prevent it at the model layer. A sufficiently capable model following instructions in its context is not malfunctioning. Which means the security question is never "will the agent get injected" - assume it will - but "what can an injected agent reach." That is a runtime question, and runtime questions have runtime answers.

The takeaway for anyone budgeting security work: dollars spent on prompt hardening buy you very little against this class of attack. Dollars spent on the four controls below buy you a lot.

The control set: treat every session as a workload

You already know how to secure a workload. A pod in Kubernetes gets a network policy, a mounted volume with defined scope, a service account with defined permissions, and logs that ship somewhere. Nobody would deploy a container with hostPath access to /, an allow-all egress rule, and the cluster admin token in its environment. That is roughly what a default coding agent install looks like on a laptop.

Four controls translate the workload model to agent sessions:

1. A filesystem boundary. The agent should see the repository it is working on and nothing else. Not ~/.ssh, not ~/.aws, not your browser's cookie jar. Containers and devcontainers are the strong version of this. Git worktrees are the weak version: useful for isolating parallel sessions from each other's changes, but they do nothing about the agent's read access to your home directory, since the process still runs as you. If a session touches anything sensitive, the boundary should be a container or a disposable VM, and we made the same argument from the harness-design side in our piece on building coding harnesses.

2. An egress allowlist. The exfiltration step of every observed attack requires an outbound connection to an attacker-controlled host. An allowlist that permits your package registries, your git remote, and the model API - and denies everything else - breaks the kill chain even when injection succeeds. This is the single highest-value control on the list, because it works without knowing anything about the attack.

3. A secret-free environment. Long-lived credentials should not exist where the agent runs. That means no AWS_ACCESS_KEY_ID in the inherited shell environment, no .env files with production strings in the working tree, and short-lived OIDC-issued tokens wherever a credential is genuinely needed. We covered the identity side of this in why AI agents should never hold keys; the endpoint corollary is that the agent should not be able to steal what is not there.

4. A reviewable command log. Every command the agent ran, every file it wrote, every URL it fetched, retained somewhere the agent cannot edit. This is your incident response story, and it is also your provenance story: if agent-authored code is entering your main branch, the log is what connects a commit to the session that produced it, which ties into the SLSA build provenance model and to tracking authorship of agent-authored commits.

A useful smell test: if you would not grant a new contractor the access your agent session has on day one, the session is over-provisioned. The principle extends to tool scoping generally, but the endpoint version is the urgent one because it is where the credentials live.

What the vendors actually ship

Here is the part that should annoy you: most of this control set exists in the products already. The gap is not vendor capability, it is that the primitives ship default-off or default-loose, and teams never turn them on.

Three observations from deploying these in practice.

First, the defaults encode a specific assumption: that the developer is watching. Permission prompts are a real control when a human reads them and a rubber stamp when the human has approval fatigue, which sets in around day three. Any workflow that encourages "accept all" (and every productivity-focused workflow does) needs the sandbox and egress layers underneath, because the human layer will erode.

Second, cloud-hosted agent modes are quietly the better security posture for most teams. Copilot's coding agent and Codex's cloud tasks run in vendor-managed isolation with no access to your laptop's filesystem at all. The tradeoff is latency and control, but "the agent physically cannot read ~/.ssh" is a stronger guarantee than any local policy you will maintain.

Third, the ecosystem is converging on this framing from the enterprise side too. Microsoft's Build 2026 security announcements put agent and model security into the same lifecycle as code security, with Purview and Defender extending visibility to agent activity, and Menlo Security extended its agent runtime protection to coding assistants in August. When the endpoint security vendors start shipping agent-specific products, the "is this really an endpoint problem" debate is over. The vendors have voted.

The counterintuitive part: restrictions make agents more useful, not less

The standard objection is that all of this friction defeats the purpose. Developers adopted these tools for speed; wrapping them in containers and allowlists sounds like the security team doing what the security team does.

The production experience runs the other way. An agent with a hard boundary can be granted more autonomy inside it. Anthropic's own sandboxing docs make this explicit: with OS-level isolation in place, Claude Code can run with reduced permission prompting, because the blast radius of a bad command is the sandbox, not the machine. The same logic holds for Codex's sandbox-then-approve model. Teams that skip isolation end up compensating with either constant human approval (slow) or unreviewed autonomy (the thing that gets you in the VentureBeat headline).

This mirrors something we see across agent deployments generally: guardrails are what make delegation possible. Nobody lets an intern push to prod on day one, and nobody sane gives them nothing to do either. You define a boundary, grant real autonomy inside it, and widen it with evidence. Agents are cheaper to constrain than interns, because their boundary is a config file.

There is also a compounding benefit on the audit side. Once command logs exist, they become training data for your own understanding of what agents do all day. Several teams we have worked with discovered their egress allowlist could be tighter than expected because months of logs showed agents contacting perhaps a dozen distinct hosts. You cannot get that information from a policy debate. You get it from telemetry.

A rollout that fits in two sprints

If you own platform or security for a team already running coding agents, here is the sequence that gets you from unmanaged to defensible without a migration project.

Sprint one: kill the free credentials and see what you have.

• Inventory which agents are in use and in what mode (local CLI, IDE extension, cloud agent). You will find more than you expect.
• Remove long-lived cloud credentials from shell profiles on developer machines. Move to short-lived tokens via your identity provider. This is disruptive for a day and permanently removes the highest-value theft target.
• Turn on session logging in whichever agents support it and ship the logs off the laptop.

Sprint two: boundaries and egress.

• Publish a devcontainer or sandbox config as the sanctioned way to run agent sessions on repos above a sensitivity threshold. Enforce socially first, technically later.
• Enable each vendor's network restriction primitive with an allowlist built from your sprint-one logs: registries, git remotes, model APIs, and whatever else the telemetry justifies.
• Route agent-authored changes through the same branch protection and review requirements as human changes, and record session provenance on the PR.

Then stop and measure before adding anything else. The most common failure mode we see is teams jumping straight to an agent-security platform purchase while their agents still inherit AWS_ACCESS_KEY_ID from .zshrc. Buy tooling to scale a control set you have already proven, not to substitute for one.

Closing the gap between policy and laptops

Most of the work above is unglamorous platform engineering: identity plumbing, container configs, log pipelines, allowlist maintenance. It is also exactly the kind of work that stalls, because it sits between the security team (which owns the risk but not the developer experience) and the engineering team (which owns the tooling but not the risk). OpenNash builds this layer for teams adopting agents in anger - the session isolation, credential scoping, and audit trail around coding and operational agents - with the same delivery model we apply to the agents themselves: senior-led, deployed into your infrastructure, fully owned by you afterward. If your developers are already running Copilot, Claude Code, or Codex and your security review consists of a Slack thread from March, an audit of what those sessions can currently reach is a one-week engagement that usually produces an uncomfortable list and a short fix queue.

Whether you do it with us or in-house, do the first check this week: open a terminal on a developer machine, run env | grep -iE 'key|token|secret', and ask whether you are comfortable with every line being readable by a process that takes instructions from the internet. That command is the whole argument, and it takes ten seconds to run.