Your Data. Your Control.
Kernel engagements keep ownership, access, and infrastructure under your control, with any exceptions stated plainly.
From Architecture Design onward, you own all accounts, credentials, and infrastructure, while Kernel uses only approved, time-limited access.
This is not just a policy position. It is a deployment constraint.
The 5-Day Blueprint works differently
The 5-Day Blueprint is a standalone assessment requiring no credentials or system access. Client-provided materials are handled temporarily in Kernel's environment under a separate data-handling summary available on request. The models below apply only to Architecture Design and later engagements.
How your data is handled
Source materials
Documents, transcripts, and operational context are processed through the client's AI provider account.
Architecture artifacts
Context inventories, lexicons, and architecture blueprints are stored in the client's repository.
Session logs
Practitioner session transcripts remain local by default and are committed only according to client preference.
Business system data
Business system exports are anonymized by default. Raw PII is never committed to the repository.
Deployment models
Deployment models range from cloud-hosted to fully air-gapped depending on your organization's security, compliance, and operational requirements.
Cloud-hosted
GitHub Cloud + external AI provider
Lowest-friction deployment. The client owns the GitHub organization, AI provider account, and API keys.
Local repository
Local Git + external AI provider
Repository remains on local infrastructure while AI processing occurs through the client's approved AI provider.
Client-hosted infrastructure
Client-managed Git infrastructure
Repository is hosted on client-controlled infrastructure with organization-managed access policies and network controls.
Air-gapped
Local Git + local language model
Repository and language model remain entirely inside the client's environment with zero external network calls.
Access models
Where your work is hosted and how much access we hold are two separate questions, and your agreement records both. A cloud-hosted repository does not imply broad access, and a restricted environment does not by itself limit it.
Reference-only
Kernel receives only the materials you choose to provide, and no credentials or direct access to your systems.
Client-mediated
Kernel provides instructions, content, or change sets. Your people perform the system access, execution, and provider interactions.
Limited named access
Named Kernel personnel receive time-bounded read or limited write access to the specific systems and permission levels recorded in the agreement.
Elevated controlled access
When required, additional time-limited permissions are documented in advance, without organization ownership, shared credentials, or authority beyond approved systems.
Before we receive access
Setting up the environment is part of the engagement, not something you have to arrive already able to do. If you have suitable systems we confirm and use them; if you are starting from nothing we walk you through creating your own.
Either way the specifics get written down first. The systems in scope, the access model, the exact permission level, the credential method, and where any temporary working copy may live are recorded in writing and confirmed by both parties before we receive access or run any model processing. If that record is never completed, we get no access and no processing happens.
Business systems & integrations
Business system data is handled as anonymized exports by default rather than persistent live connections. When integrations are required, Kernel operates through client-approved access without retaining client API credentials.
Common questions
Who at Kernel can access our materials?
Access is limited to the named Kernel practitioner assigned to your engagement, at the permission level recorded in the agreement, and is revoked when the engagement closes.
How do we verify that access was actually removed?
You revoke it, so you can confirm it in your own systems and access logs.
Can Kernel support fully air-gapped environments?
Yes. S4 deployment uses local Git and a locally hosted language model with zero external network calls.
Can you handle regulated data — health records, payment card data, and the like?
Not under a standard engagement. Regulated personal data requires a separate written agreement covering it, signed before that data comes into scope.
Can Kernel work within our existing security requirements?
Yes. Engagements are structured around your deployment, access, and data handling requirements, from cloud-hosted to fully air-gapped.