Local-first governance is an approach in which agent actions are evaluated, and the resulting record is kept by default, on the operator’s own machine, with no account, service or network connection required. It describes where governance runs, not what the agent itself connects to.
The term borrows from a 2019 essay by Ink & Switch, which described local-first software as software that prioritizes local storage and local networks over servers in remote datacenters. Its ideals included that the network is optional, that security and privacy are the default, and that users retain ultimate ownership and control of their data. Applied to agent governance, the same ideals answer a practical question: when governance evaluates what an agent does and keeps a record of it, where does that happen, and who holds the record?
Why where governance runs matters
A governance record, the governance evidence an agent’s actions leave behind, is sensitive. It contains the commands an agent ran, the files it touched, the systems it reached and what it was asked to do. Where that record lives decides several things at once:
- Custody. Who holds the evidence, and who can read, keep or delete it.
- Egress. Whether using the governance tool sends that information anywhere. A governance tool with telemetry is itself a path out of the environment it governs.
- Availability. Whether governance works when the network does not, or when a vendor’s service is unavailable.
- Adoption. Whether an individual developer can start without an account, a contract or an approval to send data to a third party.
Local-first governance answers all four the same way: on the operator’s machine, under the operator’s control, by default.
Local-first, self-hosted, on-premises, air-gapped
These terms are often used as if they were the same. They describe different properties, and they can overlap: an on-premises deployment is usually also self-hosted, an air-gapped environment can be either, and a local-first tool can run inside any of them.
| Arrangement | Who holds the record | Who controls the infrastructure | Dependence on external networks |
|---|---|---|---|
| Local-first | The operator, on the machine where the agent runs | The operator | None by default |
| Self-hosted | The organization that runs the system | The organization, on servers or cloud accounts it operates | Depends on the deployment; not inherent |
| On-premises | The organization | The organization, in its own facilities | Depends on the deployment; not inherent |
| Air-gapped | The organization | The organization, on systems isolated from external networks, which may still share an isolated internal network | None permitted |
What sets local-first apart is that it needs nothing beyond the machine it runs on: one person on one laptop can use it with nothing else in place. Self-hosted, on-premises and air-gapped describe where an organization runs its infrastructure, and a local-first tool’s records can feed them when exported deliberately.
What it does not mean
Local-first governance says nothing about the agent’s own connections. A coding agent can call a cloud model, fetch web pages and push to a remote repository while its governance runs entirely on the developer’s machine. Local governance is not a local model, it is not an air gap, and it does not stop the agent from sending data anywhere. It keeps the governance layer’s own evaluation and evidence local.
Trade-offs
Keeping the record local has costs:
- No central view by default. Each machine holds its own record. Seeing across a team requires exporting records to somewhere shared, deliberately.
- Durability is the operator’s job. A record on one disk is lost with that disk unless it is backed up.
- Remote execution changes the picture. When an agent runs on a hosted executor, “local” means the executor, not the operator’s laptop. In one integration we describe in A Valve Is Not a Read, records written on a hosted runtime stayed there, out of the operator’s reach, until we added a way to bring summaries home.
How Sentience Governor applies it
Sentience Governor is local-first by design. It requires no account, no API key and no network connection; its execution record is a set of files on the operator’s disk; it sends no telemetry, usage beacon or license check; and governance runs with the network off. It has two explicit network-capable paths, neither on the default governance path: an optional sink that posts events to a URL the operator configures, and a one-time prompt to join a launch list, which sends an email address only if the user chooses to.
Where the concept stops
Local-first governance establishes where evaluation runs and who holds the record. It does not make the record tamper-evident, it does not give an organization a combined view of many machines, and it does not govern what the agent itself connects to. It is a statement about custody and independence, and a starting point for governance that can later be shared on the operator’s terms.