Security you can read.
KinLab is built on an open-source substrate, so the foundation of your security is not a vendor claim. It is source you can audit. Agent access is scoped, every change carries provenance, and risky merges meet a review gate. Here is our posture, stated honestly, including what we have not certified yet.
Open-source auditability: no black box
The Kin substrate underneath KinLab is open source under Apache-2.0. The semantic engine, the graph format, the transparent filesystem, the MCP server, and the retrieval internals are all public. You do not have to trust a description of how your code is parsed, stored, and served. You can read every line, run it locally, and verify it yourself.
The foundation is inspectable
Security posture usually depends on a vendor's word about code you cannot see. With Kin, the substrate that builds and serves your graph is public, so the most security-critical layer is open to your own review and to independent scrutiny.
Run it yourself to verify
Because the tooling is open and runs locally, you can confirm exactly what it does with your code before any of it touches the hosted plane. Adoption starts from something you can audit, not something you have to take on faith.
Agent access & provenance
AI agents write most of the code now, so security is no longer only about who has a login. It is about what an agent is allowed to change and whether you can prove afterward what it did. KinLab governs agents against the graph itself: scoped capabilities, provenance on every entity, and review gates on the changes that carry real blast radius.
Scoped agent capabilities
Agents work through declared intents that name the entities and the goal in scope. Access is bounded to a stated purpose on the graph rather than free reign over an entire checkout.
Per-entity provenance
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 attaches to the unit of meaning, not just a commit hash.
Review gates on impact
Changes with high graph blast radius can require explicit review before they land. The gate is decided against structural impact and provenance: a real check on what an agent touched, scored from the graph.
Honest about enforcement
Today, agent governance is strongest as advisory and forensic: KinLab records intent, coordinates concurrent work, and keeps per-entity provenance so you can see and audit exactly what every agent did. Hard pre-write veto (blocking a change before it is written, by policy on the graph) is opt-in and rolling out, not on by default. We will not pretend it blocks by default before it does.
Data handling
Your source and the semantic graph derived from it are your data. The hosted plane stores and serves that graph so a team can work on it together. It does not take ownership of it, and the same substrate is one you can run locally and inspect.
Your code, your graph
The semantic graph is derived from your repositories and belongs to you. It is the same substrate you can run locally with the open-source Kin tooling. The hosted plane stores and serves it, it does not change ownership of it.
Tenant isolation
Each org’s graph, blobs, and metadata are kept logically isolated per tenant, so one customer’s code and semantic state are never served into another’s context.
Auditable by design
Because provenance is recorded at the entity level, the record of who changed what (human or agent) is a first-class part of the graph rather than something reconstructed after the fact.
Compliance roadmap
We will be direct about this, because security pages should survive diligence. KinLab is a pre-release company, and we do not currently hold SOC 2, ISO 27001, HIPAA, or any other formal certification. We are not going to imply otherwise.
On our roadmap
SOC 2 is on our roadmap. As we move toward enterprise readiness, formalizing controls and pursuing a SOC 2 examination is a planned step. Not something we claim to have completed today.
What we offer now
An open, auditable substrate, scoped agent access, and per-entity provenance: concrete properties you can verify today, while the formal compliance program is built toward enterprise requirements.
If your team has specific compliance requirements, we want to hear them early. Design partners help shape what we prioritize on the road to enterprise readiness.
Pre-release · early access by request
A security posture you can verify, not just trust.
Read the open substrate, audit how your code is handled, and talk to us about your requirements. Early access is granted by request while the platform matures toward enterprise compliance.
Read the open Kin substrate, or see how agent governance works.