Nobody is watching the execution layer.
Most deployed AI governance reads the model's text. An agent's capacity to do damage runs somewhere else entirely — through the shell commands, file writes, and network calls its harness dispatches on its behalf. That layer is largely ungoverned, and the incident record shows what happens as a result.
The controls did not keep up.
Coding agents moved from pilot projects to production work in about eighteen months. They now run in developer terminals, in CI pipelines, and on schedules with nobody watching. The controls around them did not move at the same speed, and the gap is not evenly distributed: what an agent is allowed to say has attracted far more attention than what it is allowed to do.
A market has formed around the phrase "AI agent governance," but vendors mean materially different things by it. Prompt and content filtering inspects what goes into a model and what comes out. Identity and credential management governs what an agent can authenticate as. Runtime action enforcement decides whether a specific command, file write, or outbound connection is permitted to proceed. These are three distinct control points at three different layers of the stack, and they are frequently sold under one name. A team that has bought the first two often believes it has bought the third.
The regulatory picture is thinner than the marketing implies. The major published AI governance frameworks — the ones most commonly cited in procurement documents and compliance checklists — contain no agent-specific provisions. They were written for models that produce text and predictions, not for processes that hold credentials and execute commands. The vocabulary is running well ahead of anything codified.
Some governments have moved. One jurisdiction published a dedicated agentic governance framework in early 2026, the first to treat autonomous action rather than model output as the unit of regulation. Two national cyber authorities issued joint guidance in May 2026 addressing agent deployment in operational environments. Elsewhere, regulators have taken a principles-based approach, issuing expectations without dedicated legislation. The direction is consistent, but the coverage is patchy, and none of it yet prescribes what enforcement at the execution layer should actually look like.
This leaves the practical burden with engineering teams, who are generally aware that the gap exists and generally unsure what to put in it.
Reasoning and execution are different code paths.
A model reasons about what to do. A harness executes. Those are separate code paths, and the separation is genuinely a mitigation rather than an accident of architecture: a manipulated model cannot reach the filesystem directly. It has to emit a tool call, and that call has to pass a permission check before anything happens on the machine.
The permission check is therefore where the enforcement lives. It is also thinner than it looks. Permission systems in widely used harnesses commonly include modes that auto-approve whole categories of action — every file write inside a working directory, every command matching a pattern, every request to a previously approved tool. These modes exist because the alternative is a prompt every few seconds, and engineers turn them on for exactly that reason.
Performance pressure compounds it. Fine-grained checking costs something on every call: parsing a command, resolving a path, matching it against a policy. Where that cost is material, systems fall back to a single coarse approval prompt covering a batch of actions, or to a check performed against the command as written rather than the command as it will actually run. Both fallbacks are reasonable engineering. Both widen the gap between what was approved and what happened.
Content filtering does not see any of this. It reads what the model said, not what the machine did. An agent can be perfectly compliant in its text and destructive in its effects, and to a content filter those are the same session.
Different harnesses, one failure class.
Across publicly documented incidents between mid-2025 and mid-2026, agents destroyed data on developer machines, dropped tables in production databases, and deleted resources in cloud infrastructure. The harnesses differed. The permission models differed. The failure class did not.
This page does not name the vendors involved. Every incident referenced here is documented publicly and could be attributed, but naming them turns a structural finding into a list of competitors' bad days — and it invites the reader to conclude that the problem belongs to whoever is named. It does not. The recurrence across independently built systems is the entire point.
From mid-2026 the picture changed character. The earlier incidents were accidents: misfires by agents doing what they were told, badly, with nobody in the loop to catch the difference between the instruction and the effect. The later ones include deliberate attacks on the execution layer itself — attempts to reach past the harness's boundary rather than to manipulate the model inside it, including sandbox escapes.
Accidental and adversarial failure now share the same surface. That matters for how the surface should be instrumented: a control designed only to catch mistakes assumes the agent is cooperating, and an attacker on the same path is not.
A gap, not a bug.
The same five failure classes recur across systems built independently, by different teams, with different permission models and different threat assumptions. A defect that appears once is a bug. A defect that appears in every implementation of a pattern is a property of the pattern. The execution layer is where all of these systems converge, and it is the layer none of them instrument thoroughly.
An independent comparative study of production agent harnesses published in 2026 names the problem directly. Among its open problems it lists silent failure and what it calls the observability–evaluation gap: systems lack adequate visibility when a safety layer fails quietly rather than loudly. A layer that fails loudly gets fixed. A layer that fails quietly gets trusted.
Standards bodies have begun naming it too. The risk category covering agents granted more functionality, permissions, or autonomy than their task requires moved up the rankings in the 2026 revision of a major application-security list — a revision built partly on incident evidence rather than expert opinion alone. Excessive agency stopped being a theoretical concern and became a measured one.
Four principles.
Enforcement has to sit where actions happen, not where text is generated. A control that inspects model output is inspecting an intention; a control at the syscall and process boundary is inspecting an event. Only one of those can be stopped.
Recording must be independent of the agent's own account of itself. An agent that reports its actions is a witness to its own conduct, and the incidents above include cases where the report and the effect diverged — not through deception, but because the harness recorded the call it dispatched rather than the command that ran. Evidence collected at the boundary does not have that problem.
Instrumentation must state its own limits. Platforms differ in what they permit an observer to see, and coverage is uneven in ways that matter. A boundary that overstates what it observed is worse than no boundary, because it produces false confidence — and false confidence is what turns a gap into an incident.
Every action needs an owner: a person, a repo, a commit, a named agent, a host. "Something happened on a laptop" is not an audit trail. Attribution is what makes a record reconstructable months later, by someone who was not there.
These four principles are what we built Bantay to satisfy. It runs inline at the execution boundary, records independently of the agent, and labels what it could not see.