Your Data. Your Control.
Your operational foundation, knowledge, and underlying assets remain yours. Kernel works within agreed access and ownership arrangements, with any exceptions stated plainly.
Across managed plans and custom engagements alike, you own your accounts, credentials, and infrastructure, while Kernel uses only approved, time-limited access.
This is not just a policy position. It is a deployment constraint.
Your brain. Your rules.
Kernel establishes and maintains the infrastructure. Your organization controls its knowledge, permissions, governance, and evolution. No proprietary AI work surface required.
What your AI tools can do with that knowledge depends on the tools you choose.
If the engagement ends
Your accounts, credentials, and infrastructure are already yours, so nothing has to be handed back. Kernel's access ends, and your knowledge and architecture stay where they are, in a portable foundation you can keep using with compatible AI tools.
Individual AI tool integrations and local setups may still need updates as those products change.
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-owned operational system.
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 written into the operational foundation.
Deployment models
Deployment models range from cloud-hosted to fully air-gapped depending on your organization's security, compliance, and operational requirements.
The customer selects and configures the AI tools used with the foundation. Kernel's maintenance responsibility covers the agreed underlying infrastructure, not the operation or configuration of those tools.
Cloud-hosted
GitHub Cloud + external AI provider
Lowest-friction deployment. The client owns the GitHub organization, AI provider account, and API keys.
Local infrastructure
Local Git + external AI provider
The operational foundation remains on local infrastructure while AI processing occurs through the client's approved AI provider.
Client-hosted infrastructure
Client-managed Git infrastructure
The operational foundation is hosted on client-controlled infrastructure with organization-managed access policies and network controls.
Air-gapped
Local Git + local language model
The operational foundation 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 foundation 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?
Available by agreement. Kernel is designed for it: the S4 deployment model uses local Git and a locally hosted language model with zero external network calls. An air-gapped deployment is scoped and agreed in writing before the engagement starts.
Can you handle regulated data, such as health records or payment card data?
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.