The Model Has Preferences. The Harness Has Controls.

Nine seconds. That is how long it took an AI coding agent at PocketOS in late April 2026 to delete the company's production database and take the attached backups offline right alongside it.

What happened, per Railway's technical write-up:

• The agent hit a credential mismatch and went looking for a fix.
• It found a cloud API token that let it do far more than fix anything.
• It deleted the production database volume and made the attached snapshots unavailable, leaving PocketOS with three-month-old backups and a 60-hour recovery.

Its own summary afterward was painfully candid:

The tempting question is the wrong one.

This post argues that the answer lives in the agent harness, not the model.

The most useful mental model for securing AI agents is also the simplest: Agent = Model + Harness.

• The model reasons. It is probabilistic. It predicts tokens, plans steps, and expresses preferences. It can be persuaded, confused, and tricked.
• The harness executes. It is everything that turns reasoning into action: the agent loop, shell and tool executors, MCP servers, repo config files, approval prompts, the OS sandbox, and (crucially) the credentials the agent runs with. Claude Code, Cursor, Codex CLI, Gemini CLI, and GitHub Copilot's agent mode are all harnesses.

None of this is new security philosophy. Least privilege, isolation, identity, and audit logging are decades old. What agents change is where those principles must be enforced and how fast.

Let's be blunt about something the industry keeps dancing around: the model will never be a reliable security boundary, and it is pointless to treat it as one.

Three reasons, none fixable with a better system prompt:

• It is non-deterministic. The same input can produce a different action tomorrow. A boundary that holds 97% of the time is not a boundary; it is a statistic. Security boundaries are supposed to be boring and repeatable.
• It consumes untrusted text as instructions. Agents read attacker-controlled text all day in READMEs, issues, PR comments, web pages, and tool descriptions, and models fail to reliably separate retrieved data from instructions. The UK NCSC calls LLMs "inherently confusable"; OpenAI says prompt injection is "unlikely to ever be fully 'solved'". Model refusals help, but they do not hold: in the Nx supply-chain attack, guardrails rejected roughly a quarter of Claude invocations and the attack still succeeded.
• It cannot police itself (self-review). Asking the actor model whether its own next action is safe is asking the suspect to run the investigation. And you do not need a rogue-AI scenario to see the risk: well-intentioned agents have already wiped production databases at Replit during a declared code freeze and at PocketOS, simply because their judgment failed and their blast radius was too wide.

"What about a second model that checks the first?"

Independent guard and reviewer models (Google's Model Armor, Cisco AI Defense, and the reviewer models OpenAI and Anthropic now ship inside their harnesses) are a real risk-reduction layer, and we recommend them. But a reviewer model is still a probabilistic filter, not a final authorization boundary. You have stacked a second set of preferences on top of the first set: Anthropic's own reviewer publishes a 17% false-negative rate across 52 real overeager actions. A useful filter. Not a wall.

The appsec vs. firewall analogy

We have been here before with web applications. Application security (secure coding, input validation, code review) makes the app harder to exploit, but every serious app still ships bugs, so we put runtime boundaries (firewalls, WAFs, OS sandboxes, IAM) around the app to enforce rules it cannot violate even when it is buggy or actively exploited. Agents work the same way:

• Model alignment, safety training, and prompting ≈ agent appsec (fewer bad decisions, never zero).
• The harness ≈ runtime enforcement (sandbox, tool policy, and IAM that keep bad decisions from becoming irreversible actions).

Saying "the harness is the primary execution boundary" does not mean "only the harness matters." In practice, an enterprise running agents relies on three control layers with distinct jobs:

1. The model (alignment, safety training, refusals). Run by the model vendor to reduce the rate of bad decisions. Probabilistic.
2. The harness (OS sandbox, tool policy, scoped identity, secrets handling, egress allowlist, approval gates, hooks, telemetry). Shipped by the AI vendor and configured by the customer to constrain all execution, both local and remote.
3. The enterprise agentic gateway (policy, identity brokering, MCP proxying, DLP, and logging across external model, tool, and data traffic). Run by the enterprise security team to centralize policy and SOC visibility across agents.

The layers are not interchangeable:

And the harness is the least mature of the three. The model gets the research attention. The gateway is where enterprise vendors (ours included) are converging. The harness sits in the middle: shipped by AI vendors, configured by developers, treated as a productivity plugin, and mostly invisible to security.

Once you look at the harness as a security boundary rather than a developer convenience, three specific gaps stand out in how harnesses are deployed today.

1. Approval fatigue and bypass modes (--yolo)

• A coding agent makes hundreds of tool calls in a single session. Ask a human to approve each one at machine speed and they stop reading within the hour: Anthropic measured users approving 93% of permission prompts before it introduced auto mode. A control that everyone clicks through is not a control.
• When friction gets too high, developers turn it off, and most major coding-agent harnesses expose an explicit bypass mode for exactly that (--dangerously-skip-permissions in Claude Code, --yolo in Gemini CLI and Codex).

2. Over-privileged credentials and shared identity

• Today, local harnesses typically inherit the developer's ambient git keys, cloud tokens, and MCP connections into Slack, GitHub, and production consoles.
• Unless sessions carry a separate agent identity, the agent's blast radius equals the human's, and the SOC cannot easily tell human and agent apart.

3. The harness itself is an unmonitored software attack surface

Harness CVEs and bypasses

• Cursor's MCPoison bound trust to a server's name rather than its contents (Tenable).
• A GitHub Copilot exploit used prompt injection to flip on its own auto-approve setting (Embrace The Red).
• Even actively maintained harnesses ship bugs fast: Anthropic's claude-code repository lists more than 30 security advisories.

Weaponized configs and flags

• Agent config files are executable. In June 2026, the Miasma worm planted malicious configs across 73 Microsoft repositories that ran on open. No CVE required.
• In the Nx attack, which leaked 2,000+ verified secrets, the malware invoked victims' own AI CLIs with bypass flags to do its reconnaissance.

SOC blindness

• Harness telemetry is opt-in and redacts prompts and tool arguments by default (Elastic Security Labs).
• Copilot's audit log omits local prompts entirely (GitHub).
• Raw chain-of-thought is never released to customers (Anthropic).

Closing those gaps means doing two jobs at once:

• Controlling what the agent can do (security within the harness): enforcing hard limits on execution and reach so a bad model decision cannot become a catastrophe.
• Protecting the boundary itself (security for the harness): governing the harness's code, configs, dependencies, and telemetry. A firewall with a remote code execution bug is not a boundary; neither is a harness whose config file can be rewritten by a README.

In practice, that comes down to three architectural moves:

Each move gets its own deep dive in Part 2.

A boundary is only trustworthy if you are honest about where it ends.

1. Prompt injection at the model layer remains unsolved. That is not a gap in the harness story; it is the premise of it. Every harness control assumes injection can succeed and asks what happens next.
2. Bugs inside the vendor's harness are the vendor's to fix. Pick vendors who publish advisories and ship fixes fast, and treat harness updates like browser updates.
3. The endpoint remains the thinnest layer. AI detection and response on developer laptops, where most harnesses actually run, is immature. Cloud-hosted sessions sidestep part of this; local agents do not.

Strip away the new vocabulary and harness security is least privilege, isolation, identity, and logging, applied to a process that reads untrusted text and acts at machine speed. AI changes the speed of the attack, not the fundamentals of defense.

Coming next:

• Part 2: Three moves to secure the harness. Moves A, B, and C in detail: OS sandboxing and reviewer models (with the error and prompt-reduction rates vendors have published); dedicated identity, scoped tokens, and egress allowlists that break the lethal trifecta; and agent config as code, pinned MCP dependencies, and action telemetry in the SIEM.
• Part 3: Nobody owns the whole problem. The shared-responsibility split between model providers and enterprises, which vendors ship which control today, the prerequisites that have to be true first, and five actions for this quarter.

Got comments? What stands between a coding agent’s bad decision and your production environment today? If the honest answer is “the model’s judgment,” you have a preference in a place where you need a control.