OpenHands Fork Audit - MEDIUM: Verify tenant isolation in multi-user agent-server (per-UID sandbox / mTLS)

FLEET AUDIT FINDING: OpenHands Zentra fork — fork-delta correctness/security audit

Location: vendor/openhands-agent-server/openhands/agent_server/ (multi-user scenarios)

Severity: MEDIUM (P2) — Correctness/security for multi-client server instances

The Issue:
The agent-server is launched per-client (Option A topology) with loopback binding (--host 127.0.0.1). In this model, a single agent-server process runs on each client machine.

However, the codebase contains references to multi-user / multi-client scenarios (mTLS, per-UID sandboxing, user context). If the agent-server is ever deployed in a multi-user/multi-tenant mode (shared appliance with multiple operator accounts), there could be isolation gaps:

1. Per-UID sandboxing: Are subprocess/tool runs isolated per user/UID?
2. State isolation: Are agent workspaces, conversations, and settings isolated by user?
3. Credential isolation: Can one user's LookupSecret / api_key leak to another user?
4. Authorization: Are ACLs enforced on tool execution, workspace access, KB access?

Scope of the audit:
This fork audit focused on egress/air-gap closure. Multi-user isolation is OUTSIDE the scope of this audit but should be verified separately before the Zentra appliance is deployed in a shared/multi-operator scenario.

Proof of concern:
The appliance documentation / deployment model should clarify: is the agent-server single-operator (per-client) or shared (multi-operator on one appliance)? If shared, a separate security review of user isolation is needed.

Fix guidance:

1. Document the deployment model clearly (single vs multi-operator)
2. If multi-operator is supported, conduct a separate tenant-isolation audit
3. Ensure workspaces, conversations, and credentials are tagged with owner/UID
4. Verify tool sandboxing and execution ACLs are enforced per user

Start with vendor/openhands-agent-server/openhands/agent_server/ and the appliance deployment documentation to determine whether the server is single-operator or shared. If multi-operator use is supported, review per-UID execution, workspace and conversation state, credential handling, and access controls, then document the deployment model and audit findings.