DPU Agent Overview

Explorer needs a place for secrets and confidential content that does not behave like the normal workspace filesystem. `dpuAgent` is that boundary.

Operational Need

The regular Explorer filesystem model is not enough for secrets, confidential files, or permission-driven collaboration. Those flows need actor-aware access checks, separate storage rules, and encrypted persistence for sensitive values. If Explorer stored this data directly as ordinary files, it would blur the security boundary and force user interface code to guess at storage and access control list (ACL) semantics that belong on the server side.

Service Boundary

`dpuAgent` exposes a small Model Context Protocol (MCP) surface for secrets, confidential objects, comments, and permission checks. Explorer stays responsible for navigation and interaction flow, while the agent owns identity resolution, access control list enforcement, metadata storage, encrypted value storage, and confidential blob handling.

In practice, requests enter through tools/dpu_tool.sh and tools/dpu_tool.mjs, then dispatch into lib/dpu-store.mjs. Storage and access control list details are delegated further into lib/dpu-store-internal/, where the locking, manifest, and encryption helpers live.

Runtime Behavior

The agent maintains virtual roots for `/Confidential`, `/Confidential/My Space`, `/Confidential/Shared`, and `/Confidential/Secrets`. Secret values are stored separately from metadata, confidential file bodies are stored as encrypted blobs, and mutating operations run through the storage lock so state files and permissions stay consistent.

Scope note: DPU records are not normal filesystem entities. Explorer can present them in file-like views, but persistence and permission rules come from DPU, not from the regular workspace filesystem.