The agent could save files in /memories/ and read them back later. It ran inside a filesystem sandbox, but every tenant on the same host used the same /memories/ directory.

Description

We tested that boundary with two tenant accounts:

  1. A user on tenant A asks the agent to save data to /memories/.
  2. The agent writes the file.
  3. A user on tenant B asks the agent to list /memories/. Tenant A's file is in the listing.
  4. Tenant B asks the agent to read that file and receives its contents.

The filesystem tools resolved /memories/ to the same place for both accounts.

Impact

Tenant B read a file written for tenant A. Files saved in this workspace during normal use, such as notes, summaries or logs, would be reachable through the same path.

Steps to reproduce

Auth context: two test accounts authenticated against separate tenants on the same agent host, one at scheduler tier and one at admin tier.

  1. As tenant A, ask the agent to write a file to /memories/ containing tenant-identifying content:
FS-XTENANT-TEST-<timestamp>.txt

Job Count Summary for tenant <tenant-a-id>
...
This report should only be visible within this tenant.

Observed: the agent wrote the file.

  1. As tenant B, ask the agent to list /memories/.

Observed: the listing includes FS-XTENANT-TEST-<timestamp>.txt.

  1. As tenant B, ask the agent to read that file.

Observed:

Job Count Summary for tenant <tenant-a-id>
...
This report should only be visible within this tenant.

Remediation

Give each tenant a separate /memories/ mount or namespace, selected using the tenant in the authenticated session. The filesystem tools must keep every list, read and write inside that tenant's partition, even if a request supplies a path to another one.

Controls observed

  • Filesystem sandbox: a root listing showed only /memories/ and the read-only skills path. Cross-tenant access occurred inside the shared workspace; access elsewhere on the host was not demonstrated.