Govern AI agents at the code, not just the container.
AI agents write most of the code now. Sandboxes and runners govern where an agent runs: which box, which network, which token. KinLab governs what an agent changes in your code's meaning. Scope intents, coordinate concurrent work, gate risky changes, and keep provenance on every entity.
Sandboxes govern where an agent runs, not what it changes.
Container isolation, scoped credentials, and network policy are real and necessary. But they answer a different question than the one that matters once an agent has a checkout: what is this agent allowed to change in the actual meaning of the codebase, and can you prove afterward what it did?
Runtime isolation is not code governance
A perfectly sandboxed agent can still rewrite a load-bearing contract, delete a function a dozen modules depend on, or quietly broaden a public API. The blast radius of a change lives in the code graph. Not in the container the agent happened to run in.
File permissions are too coarse for agents
Path-based access (this directory, that branch) has no notion of the functions, types, and contracts that actually carry risk. Governing agents at the file boundary cannot express "may refactor internals, may not change this public interface."
Governance at the semantic layer
KinLab governs agents against the graph itself: the entities and relationships that define what your code means. Intent, coordination, provenance, and review all operate on structure, not on byte ranges.
Scoped intents
Agents declare what they intend to change before they change it. An intent names the entities and the goal in scope, so work is bounded to a stated purpose rather than free reign over the whole repository.
Sessions & leases for coordination
Concurrent agents hold sessions and leases over the parts of the graph they are working on. That makes overlapping work visible and serializable instead of a silent race to overwrite each other.
Provenance per entity
Every changed function, type, and contract carries a record of who or which agent changed it, under what intent, and against what prior state. Authorship is attached to the unit of meaning, not just a commit hash.
Review gates on risky changes
Changes with high graph impact can require explicit review before they land. The gate is decided against structural blast radius and provenance: a real check on what an agent touched, scored from the graph.
Where this stands today
Be clear-eyed about the maturity here. Today, governance is strongest as advisory and forensic: KinLab records intent, coordinates sessions, and keeps per-entity provenance so you can see and audit exactly what every agent did. Hard pre-write enforcement (vetoing a change before it is written, by policy on the graph) is opt-in and rolling out, not on by default. We describe it as an advisory and audit layer you can opt into enforcement on, and we will not pretend it blocks by default before it does.
Multi-agent coordination on one shared graph
The interesting failure of agent fleets is not a single rogue agent. It is two or three agents editing the same code with no shared picture of what the others are doing. KinLab gives every agent the same standing semantic graph as its source of truth, and coordinates their work through sessions, intents, and leases so concurrent changes are visible and serialized instead of silently clobbering one another.
One shared graph every agent reads and writes. Not a fan-out of divergent per-agent checkouts.
Sessions and leases make overlapping work explicit, so two agents do not quietly fight over the same entity.
Every change leaves provenance, so the whole fleet's work stays auditable after the fact.
Pre-release · early access by request
Bounded, auditable, coordinated agents.
KinLab is the hosted control plane on the open Kin substrate: the place to give an agent fleet safe access to a shared code graph. Early access is granted by request while the platform matures.
Explore the open Kin ecosystem, read the proof, or see pricing.