Chroma core + chroma-mcp: single-layer tenant isolation (frontend authz gate, no tenant re-check in sysdb/query execution) and a broad-CRUD agent surface

The query and get execution methods drop the tenant entirely and resolve by (database, collection_id), performing no post-resolution comparison of the fetched collection's tenant against the caller.

Against rust/frontend/src/impls/service_based_frontend.rs:

• Tenant Validation After Collection Resolution (primary): FAIL. query() destructures QueryRequest with .. and never binds tenant_id (service_based_frontend.rs:2234-2245), fetches via get_collection_with_segments(Some(database_name), collection_id) (2262-2266), and never compares collection_and_segments.collection.tenant to the caller.
• Direct Query with Foreign Tenant's Collection ID (primary): FAIL. With a known or leaked collection_id and a matching database name, resolution succeeds with no tenant gate at this layer.
• Get Operation with Forged Collection ID (primary): FAIL. Same shape on the get path.
• Simultaneous Queries to Multiple Tenants' Collections (primary): FAIL. No per-request tenant binding to separate them here.
• Query Using Own Tenant's Collection ID (primary): PASS (legitimate access works).
• Bypass via Database Name Manipulation / Nonexistent or Tampered Collection ID / Audit (additional): the database name is validated (2247-2251), so database scoping is present, but tenant validation and cross-tenant audit are absent at this layer.

Net: tenant validation on the read path is delegated upward to the authz gate (REQ-00087431) and is not re-asserted here, so if that gate is a no-op or carries a tenant-confusion bug there is no second check: the method serves whatever (database, collection_id) resolves. Database scoping is present; tenant scoping is not.

Server mode defaults to no authentication and fails open (it silently skips auth when no provider is configured, with no warning), and the default embedded api is unauthenticated by design.

Against chromadb/config.py, chromadb/server/fastapi/__init__.py, chromadb/api/rust.py, chromadb/api/segment.py:

• No Default Open Access in Configuration Absence / Deny All Requests When No Auth Provider (Server Mode) (primary): FAIL. chroma_server_authn_provider and chroma_server_authz_provider default to None (config.py:205, 214), and sync_auth_request returns early without authenticating when self.authn_provider is falsy (fastapi/init.py:530), then skips authorization when self.authz_provider is falsy (fastapi/init.py:542). The server starts and serves all requests.
• Explicit Warning on Missing Auth Provider at Startup / Warning Contains Remediation (primary and additional): FAIL. Providers are simply left None (fastapi/init.py:227-233); no startup warning is emitted.
• No Access on Partial or Invalid Auth Provider Configuration (primary): FAIL. Missing config yields open access, not fail-closed.
• Fail-Closed Behavior in chromadb/api/rust.py and segment.py Entrypoints (primary): FAIL by design. Embedded get_user_identity returns a fixed default identity with no auth (rust.py:719, segment.py:204); the default chroma_api_impl is the embedded RustBindingsAPI (config.py:120).
• Fail-Closed Behavior in Dockerized Deployment (primary): FAIL. The shipped image inherits the same open defaults unless auth env is set.
• Hot Reload / Non-Standard Entrypoint Import (additional): same open-by-default behavior.

Net: the embedded trust model (process boundary equals trust boundary, next to the customer's key material) is reasonable for an in-process library, but the server path fails open rather than closed and emits no warning, so a self-hosted Chroma server started without explicit auth env is reachable unauthenticated. The requirement asks for fail-closed behavior or an explicit, actionable warning; neither is present in this commit.

In this open-source commit the frontend authorization gate ships as a no-op allow-all, so tenant and database enforcement is absent by default; the authz scaffolding is well-designed but the shipped binary does not use it (production Chroma Cloud presumably injects a real impl that is not in this repo).

Against rust/frontend-core/src/auth.rs, rust/frontend/src/bin/frontend_service.rs:

• Reject Use of Allow-All Auth Implementation (primary): FAIL. The only frontend binary wires Arc::new(()) as _ for both auth and quota (frontend_service.rs:13-14), and impl AuthenticateAndAuthorize for () returns a fixed default_identity{tenant:"default_tenant"} from every method, ignoring headers (auth.rs:128-168). The process starts; it does not refuse or warn.
• Deny Access When No Auth Provider Configured (primary): FAIL. The default path allows all requests rather than denying.
• Cross-Tenant Collection Access Denied / Collection Belongs to Correct Tenant (primary): FAIL. authenticate_and_authorize_collection receives the fetched Collection (auth.rs:114-120), the correct place to assert collection.tenant == identity.tenant, but the () impl ignores it (auth.rs:148-158).
• Fail Closed on Unknown Tenant / Identity Parsing Error (primary): FAIL. Headers are never parsed; every caller resolves to default_tenant.
• Database-Level Authorization Enforcement (primary): FAIL. No database-membership check in the default impl.
• Allow Access to Own Tenant Collection (primary): PASS, but vacuously (all access is allowed).
• Concurrent Mixed Tenants / Error Message Does Not Leak Tenant Existence (additional): FAIL or N/A (vacuous, since no denials are produced).

Net: the architecture is sound (a granular AuthzAction enum, an AuthzResource{tenant,database,collection}, and a collection-aware authz hook that receives the resolved collection), but the open-source default is open. Tenant isolation depends entirely on a real AuthenticateAndAuthorize implementation being injected at deploy time, with nothing failing closed if it is missing. This is the single load-bearing isolation layer, and in this commit it is a no-op.

The chroma-mcp server grants an agent full CRUD over every collection the single configured credential can reach, with no per-collection allowlist, no read-only mode, and unconstrained content filter operators.

Against chroma-core/chroma-mcp src/chroma_mcp/server.py:

• Broad CRUD Access Not Permitted by Default (primary): FAIL. A single global client is built once (server.py:72-141) and every tool takes a free-form collection_name, so by default the agent can reach any collection in scope.
• Access Denied to Non-Allowlisted Collection / Explicit Multi-Collection Allowlist Enforcement (primary): FAIL. There is no allowlist construct anywhere; get_collection(collection_name) is called with whatever name the model supplies (query at server.py:431, get at 480).
• Write Operation Blocked in Read-Only Mode (primary): FAIL. No read-only mode exists; chroma_add_documents (332-393), chroma_update_documents (492-565), chroma_delete_documents (567-605), and chroma_delete_collection (317-329) are always registered.
• Allowlisted Collection Read Permitted (primary): PASS only trivially (all reads are permitted).
• Filter Operator $regex Denied for Unallowlisted Fields / ReDoS Mitigation on $regex (primary): FAIL. where_document accepts $regex and $not_regex passed straight through to the engine (documented at server.py:420-423, 467-470) with no operator restriction or complexity bound.
• Agent Credential Minimum Privilege Verification (primary): FAIL. Cloud mode holds one x-chroma-token for one tenant and database (server.py:109-126) and exposes the full toolset over it; the credential's scope is whatever the key grants, not the minimum the agent needs.
• Credential Cannot Escalate at Runtime / Audit Log of Denied Access (additional): no allowlist exists, so there is no denial path and no denial audit.

Net: this is the broad-query-API, broad-blast-radius surface. The MCP correctly requires explicit tenant, database, and key, and always uses SSL in cloud mode (credit), but within that scope an agent, or untrusted content reaching the agent via indirect prompt injection over the retrieval store, can read, overwrite, fork, or delete any collection and run content regexes. No allowlist, read-only mode, or operator constraint is present.

The catalog enforces the (tenant, database) scope on list and delete paths but drops it on the collection-plus-segment read-resolution hot-path, so there is no independent tenant check behind the frontend for query and get.

Against rust/sysdb/src/sqlite.rs:

• Bypass with Only Collection ID (primary): FAIL. get_collection_with_segments(collection_id) resolves the collection and its segments by UUID alone, calling get_collections_with_conn(.., Some(collection_id), None /*name*/, None /*tenant*/, None /*database*/, ..) (sqlite.rs:634-649) and get_segments_with_conn(.., collection_id, ..) (sqlite.rs:656-658).
• Direct Access with Foreign Collection ID / Mismatched Tenant and Database (primary): FAIL. Same path: any existing collection_id resolves regardless of tenant or database.
• SQL Query Inspection for Tenant and Database Filtering (primary): FAIL for this path. The generated WHERE binds only collection_id because tenant and database are None, so their add_option(..) clauses are skipped (sqlite.rs:735-754).
• Missing Tenant or Database in Function Call (primary): FAIL. The function signature does not accept tenant or database, so it cannot reject a missing scope.
• Attempt Write Operation to Foreign Tenant's Collection (primary): PASS. The delete path is tenant and database scoped: delete_collection_with_conn(tenant, database, collection_id, segment_ids) (sqlite.rs:600-609).
• Authenticated Principal with Multiple Database Memberships / Legacy API Path (additional): partial credit. The same builder applies tenant and database when they are supplied (sqlite.rs:741-749), and list/get_collections pass them, so list is scoped.

Net: the tenant and database filter exists in the query builder and is applied on writes, deletes, and lists, but the read-resolution path that backs query and get (get_collection_with_segments) deliberately omits it, so a leaked collection_id is sufficient to resolve another tenant's collection at the catalog layer. The fix is small (thread the caller's tenant and database into this one resolver), which is why this is partial rather than absent.

The query worker and the log service operate on collection_id and segment_id handed down from the frontend and perform no independent tenant validation; the worker carries the tenant value but uses it only for metering, not authorization.

Against rust/worker/src/server.rs, rust/log-service/src/lib.rs:

• Worker: Missing Tenant in Request (primary): FAIL. The scan path reads collection_id = collection_and_segments.collection.collection_id and executes (server.rs:325-338); it does not hard-error on a missing or unresolved tenant.
• Worker: Tenant/Collection Mismatch (primary): FAIL. The worker trusts the CollectionAndSegments descriptor; the tenant field is present but only copied into the metering context (tenant: collection_and_segments.collection.tenant.clone(), server.rs:276), never checked.
• Worker: Empty String Tenant (primary): FAIL. No tenant validation, so an empty or defaulted tenant is not rejected.
• Log Service: Only Collection Provided / Null Tenant in Descriptor (primary): FAIL. Log storage is keyed purely by collection_id: collection_id.storage_prefix_for_log() (lib.rs:451, and the same pattern at 1484, 2136, 2277, 2486, 3043, 3122). There is no tenant in the storage path to reject.
• Log Service: Production Audit for Tenantless Requests (primary): FAIL. The model has no tenant at this layer, so tenantless processing is the norm.
• Malformed Tenant / Nested Descriptor / Batch Multi-Tenant / Error Content (additional): N/A or FAIL; tenant is not part of these layers' contract.

Net: this is a deliberate architectural delegation (the lower layers trust the frontend to have authorized the request and isolate per collection_id), not an incidental bug. It is graded NOT_IMPLEMENTED against the requirement because there is no hard-error on a missing tenant and no independent enforcement, which is exactly what removes defense-in-depth: a collection_id that escapes the frontend gate is honored unconditionally by the worker and the log/WAL.

The unguessability foundation is real (random UUIDv4 collection and segment IDs), but there is no explicit non-disclosure control: the not-found error echoes the requested collection_id and IDs are pervasive in tracing and metering.

Against rust/types/src/collection.rs, rust/types/src/segment.rs, rust/sysdb/src/sqlite.rs:

• (foundation) ID unguessability: CollectionUuid::new() and SegmentUuid::new() use Uuid::new_v4() (collection.rs:39, segment.rs:47-48), so IDs are not enumerable. This is the real control the requirement leans on.
• Error Message Does Not Leak Collection or Segment UUID (primary): FAIL. GetCollectionWithSegmentsError::NotFound(collection_id.to_string()) echoes the requested collection_id back (sqlite.rs:650-654), which also distinguishes existence from non-existence.
• Bulk/List API Does Not Leak Other Tenants' UUIDs (primary): PASS. List and get_collections are tenant and database scoped (sqlite.rs:741-749), so they return only the caller's own IDs.
• Internal Error Stack Traces Are Not Exposed Externally (primary): PASS. Typed errors, no stack traces in responses.
• API Response Does Not Include Foreign Collection or Segment UUIDs (primary): PASS for normal paths (responses carry the caller's own collection IDs), contingent on the tenant gate above holding.
• Log Output Scrubbing / Metrics Do Not Expose Cross-Tenant UUIDs (primary): FAIL. collection_id and segment_id are standard fields in tracing and metering across the Rust services; there is no tenant-scoped scrubbing.
• Validation Error / Rate-Limit / Audit Log UUID Leakage (additional): no UUID-scrubbing layer exists; FAIL where applicable.

Net: cross-tenant list disclosure is prevented by tenant-scoped catalog reads, and the UUIDv4 design makes IDs unguessable, but the requirement's stricter claim (treat IDs as secret in errors, logs, and metrics) does not hold: the not-found error echoes the requested ID and IDs are pervasive in observability. Partial: the foundational control is present, the disclosure hardening is not.