Enterprise

Intelligence your company controls, end to end. Kaba Enterprise puts models to work on your own infrastructure, with your people, policies and expertise in every loop.

This page separates two things clearly: the building blocks that are in the product you can deploy today, and the fleet features that are part of Kaba Enterprise.

What fleet control changes

Kaba Personal is all local. Your account, your keys, your policies, your devices and your settings live on hardware you own and answer only to you. Unless a page says otherwise, that is what the rest of this site describes.

Kaba Enterprise with fleet management is centrally controlled. Authentication, policy, enrolment and updates move from the individual to the organisation. If your device is fleet-managed, read the Personal pages with this table in mind.

Area	Kaba Personal	Kaba Enterprise with fleet management
Accounts and sign-in	A local account on your device. No sign-up and no account server.	Authentication is centralized. Your organisation issues and controls identities.
Keys and recovery	Only you hold the key that encrypts your data. A forgotten password cannot be reset.	The organisation can revoke keys and data on a device remotely.
Devices	You invite and evict your own devices with join tickets.	Devices are enrolled into the fleet and grouped by team, site or business unit. Removal is central.
Policies	You create, choose and lock your own policies.	Policies are pushed to each group and enforced in the engine. Users cannot loosen them.
Models and adapters	You download, import and train what you like.	Models and adapters are pushed per group.
Settings	Every switch is yours.	Settings can be enforced by policy: allowed models, ad blocking, default search engines, themes and branding, proxy and comms, local versus remote inference.
Updates	You decide when to update.	Updates are pushed centrally.
Sensitive actions	You approve commands yourself.	Named approvers sign off before sensitive actions run.
Visibility	Nobody else can see your data or activity.	Audit trails and metering by team, project and model. Fleet search runs where the data lives and returns only what policy allows the requester to see.
Retention	You decide what to keep and what to delete.	Residency and retention are set centrally.
Compute	Your devices and your peers.	A shared pool of GPU machines, with budgets enforced by policy.

In both cases data, prompts and weights stay on systems the owner controls: yours in Personal, your organisation’s in Enterprise. Kaba Labs is not in the path.

[todo: confirm each row of this table against the Enterprise product, and document the specifics: how centralized sign-in works, account and key recovery, and exactly what an administrator can and cannot see on a device.]

What you can deploy today

Everything in this table is in Kaba 0.146 and kabactl 0.87.

Need	What provides it	Docs
Data, prompts and weights stay on systems you own	Local storage and inference; no vendor service in the path	Privacy
Policy inside every call	Policies with deny-wins tool ceilings, command and network modes	Machine learning
Policies people cannot loosen	Prevent overriding policy settings, enforced per request	Security
Sandboxed tools	Containers, gVisor preferred, network off by default	Security
A record of what automation did	Each tool-loop step recorded as a trajectory	Governance & controls
Device enrolment and removal	Join tickets, eviction, tombstones	Cluster & mesh
Private networking with no open ports	The mesh, with your own relay	Protocols
Shared GPU capacity	Remote inference and training on designated peers	Models & training
Company expertise as adapters	LoRA training on curated memories; adapters with manifests	Machine learning
Distributing a standard policy	.kabap bundles	File formats
Deploys on your platform	systemd, containers, Helm	Deployment
Air-gapped operation	Isolated configuration	kaba-enclave
Encryption at rest	Per-account keys for memories and credentials	Security

A reference layout

A small deployment that uses only the above:

1. GPU nodes. One or more headless kabactl nodes with models, on Kubernetes or systemd. They accept remote inference and training.
2. A relay you host, set in every node’s cluster_options.
3. Workstations running the client, joined to the cluster. Their policy names a GPU node as the inference target, so laptops stay light.
4. A standard policy, exported as .kabap and imported on each workstation, with Prevent overriding policy settings on.
5. Firewall rules blocking the API and proxy ports from outside each host.

What Kaba Enterprise adds

These are the fleet-scale capabilities described for Kaba Enterprise. They are not part of the release documented on this site.

Capability	Description
Fleet management	Enrol devices and group them by team, site or business unit. Push policies, models and adapters to each group. See health, versions and GPU capacity for every peer in one view.
Fleet search	Search memories, documents, trajectories and adapters across devices without copying data into a central index. Queries run where the data lives and return only what policy allows.
Fleet training	Schedule jobs across idle GPUs. Distil, tune and evaluate candidates before they ship.
Approvals	People sign off on sensitive actions before they run.
Ontology rules	The entities, relationships and rules of your business, respected at every step.
Metering and budgets	Every run attributed by team, project and model; limits enforced by policy.
Remote revocation	Revoke keys and data on a device centrally.
Company mixture of experts	A router across team-trained adapters that improves with use.

[todo: confirm which Enterprise capabilities are generally available, and link each to its own documentation as it is published.]

Two foundations for these already exist in the engine: device groups, and a tool-loop knowledge graph that records each step’s tool, phase and outcome and can be queried.

Not VDI

Virtual desktop infrastructure keeps data safe by running every desktop in a data center and streaming the screen. Model-driven work makes thousands of small decisions, and a round trip for each one is too slow.

Kaba takes the other route: central control, distributed compute. Work runs natively on each device or the nearest peer. Policy travels with the workload. Data stays where it was created, encrypted.

Compliance

Kaba provides controls you can map to your own program. See governance & controls.

Talk to us

For a self-hosted pilot on your infrastructure, with your policies and approvers in place from day one, get in touch through kaba.ai.