The Governance Perimeter Is Moving to the Endpoint

This is not really a post about Gemma

Every few months a new local-capable model lands and the conversation rehearses the same set of talking points: lower latency, better privacy, no inference cost, sovereignty over data. Those benefits are real. They are also not the most important thing that is happening.

The deeper shift is that execution itself is moving to the endpoint. A local-capable model is not interesting because it runs on a laptop. It is interesting because it lets an autonomous agent operate inside the terminal, the IDE, the simulator, the browser, the deployment tool, and increasingly the operating system — without crossing a network boundary that any centralized governance layer can intercept.

For the last generation of AI tooling, governance assumptions depended on centralization. Hosted APIs. Managed copilots. Centralized policy layers. Provider-side controls. On-device agents break that model.

The old governance assumption

Most AI governance infrastructure that exists today was designed for a world in which the model lived behind a network call. That assumption shaped everything else:

• Provider moderation — the model vendor enforces policy at the API boundary
• Centralized observability — every request is loggable, traceable, and replayable from a single vantage point
• Managed copilots — the IDE-side experience is a thin client over a controlled backend
• Policy gates in the cloud — usage limits, redaction, classification all live with the provider
• Workflow enforcement at the orchestrator — the hosted orchestration layer mediates tool calls

This stack works as long as the model is the network endpoint. The moment the model is the network endpoint plus a directory full of project files plus an agent loop that can call tools without ever leaving the machine, none of these layers are in the path of execution anymore.

What changes when agents go local

Once autonomous agents operate locally, they fan out into the environments that humans used to mediate. The list is longer than it sounds:

• terminals and shell sessions
• IDEs and editor extensions
• mobile and game simulators
• browsers, including agentic browsers built around computer-use loops
• deployment and infrastructure tooling
• configuration mutation across local files
• operating-system-level automation

Each of these is now a place where an autonomous workflow can read state, decide, act, and persist results without an opportunity for centralized inspection. The enforcement perimeter collapses inward, toward the repository and the execution workflow itself.

The governance implication

If the model can run locally and the workflow can run locally, then any governance that depends on a centralized chokepoint is structurally optional. It can be bypassed by simply not routing through it. That is true for security tools, observability tools, and policy tools alike.

This is not a hypothetical. It is already the operating reality for teams running Claude Code, Cursor, on-device coding agents, and computer-use loops on their own machines. The interesting question is no longer whether the centralized layer catches the violation. The interesting question is whether anything in the local execution workflow is structurally incapable of producing the violation in the first place.

That is a different design problem. It requires constraints to travel with the workflow rather than sit upstream of it.

What portable governance looks like

Portable governance is not a vague idea. It is a small set of properties that distinguish enforcement that survives endpoint execution from enforcement that does not.

• Repo-native — constraints live in the same repository as the code they govern, so any agent that reads the repo also reads the constraints
• Deterministic — same constraint, same codebase state, same verdict, regardless of which agent or harness invoked it
• Machine-evaluable — constraints encoded as records a process can execute, not prose a human has to interpret
• Provenance-aware — every verdict traceable to the originating architectural decision so violations are explainable
• Surface-agnostic — the same compiled constraint set fires from a pre-tool hook, a pre-commit hook, a CI step, or a runtime check

These are infrastructure properties, not platform properties. They survive the disappearance of any specific provider because they do not depend on a provider at all.

The expanding governance surface

It is tempting to think of this as a code-generation problem. It is not. When agents move local, the surface area that needs governance expands well beyond generated source files. The execution layer itself has become agentic.

Every one of these surfaces is an execution point where an architectural intent can fail to propagate. PR metadata can be edited by an agent without anyone reviewing the diff. Deployment configurations can be mutated by an agent that has tool access to infrastructure CLIs. Operating system automation can run commands the user never sees. Governance needs to be present at each of these surfaces, not just at code generation time.

Why platform-level governance is structurally insufficient

Platform-level governance — the governance baked into a specific copilot, IDE, or hosted orchestration product — works while the user is inside that product. The moment the workflow crosses into a different harness, a different agent runtime, or a local execution environment that the platform does not control, the constraints stop firing.

This is not a defect in any specific product. It is a structural property of platform-level controls: their scope ends at the product boundary. Endpoint-local agents routinely cross product boundaries within a single task. The set of constraints that fired at the start of the task is not the set of constraints that fires at the end.

What survives decentralization

If the centralized control plane fragments and platform-level enforcement only covers slices of the workflow, what survives? Constraints that live in the artifact the workflow is acting on. That artifact is, almost always, the repository.

This is why repo-native governance is becoming structural rather than optional. When the compiled constraint set lives in the repo:

• any agent that touches the repo can read the constraints
• any harness that runs the agent can invoke the constraint check
• any CI surface that observes the repo can re-run the same verdict
• any reviewer can audit the same enforcement trace

The constraint set becomes the one piece of governance that survives every handoff — from local agent to remote review to deployment runtime — because it is co-located with the thing being governed.

The strategic shift

The future governance challenge is not model intelligence. It is governance portability across decentralized execution environments. As agents move closer to the operating system, governance has to move closer to the repository. Not because repos are sacred. Because they are the one durable artifact every execution surface agrees to read.

This is the shift that on-device agents are quietly forcing. Centralized governance was a structural artifact of hosted inference. As inference and execution distribute, governance has to distribute with them — or stop existing.