AI and technology guides
Understand how a Kubernetes-hosted agent can use DiskDrive without making the cluster the user’s data-ownership boundary.
The useful fit
DiskDrive is the persistence layer, not the model or app itself. It gives an operations team running AI services on Kubernetes a separate place for finished files, structured records, and explicit memories that should outlive one session. Each connected AI receives its own authorization and only the scopes the user approves.
An honest boundary
An API or MCP pathway is only the technical beginning. A real connector still needs authentication, tenant isolation, permission checks, audit events, rate limits, and revocation. DiskDrive does not claim an app is connected merely because its name appears in this research library.
A believable everyday use
A cooperative runs an internal assistant on Kubernetes. The cluster handles compute, while approved files and memories live in DiskDrive under user and Space permissions. Replacing the deployment does not require moving the authoritative archive.
Choose what is durable. Save finished source material, reviewed records, or a fact the user explicitly wants remembered—not an entire private conversation by default.
Authorize separately. Give this client the narrow read, search, or write permissions it needs. Write access never silently implies delete access.
Keep provenance. Preserve who created an item, where it came from, and what later corrected or superseded it.
Primary source
Product names, model availability, APIs, and MCP capabilities can change. This page links to the primary material used for the compatibility description.
Private beta
DiskDrive is designed so the AI is an authorized client and the user remains the owner.
DiskDrive is not affiliated with or endorsed by Kubernetes. Product and company names belong to their respective owners. This page explains a possible data-portability workflow and does not promise a native connector unless the status above explicitly says one is available.