Milvus partition keys: tenant routing is not an authorization policy

A Milvus partition key helps organize and route data, but it is not an application authorization policy. Keep the requested tenant, database placement and authenticated access scope separate when several document sets share a retrieval collection.

Understand what the key controls

The partition-key documentation describes a designated scalar field used for partition placement and related search behavior. That mechanism does not establish who may choose a tenant value in an application request. Preserve the key field and its valid values in the schema record. A partitioning design can be technically correct while an application still constructs an overbroad query from an untrusted parameter.

Choose the actual tenancy boundary

Milvus’s multi-tenancy guide compares database, collection and partition arrangements. Select a boundary according to required isolation and operational constraints rather than assuming that every tenant needs a new server or that a shared collection is always sufficient. Document which component applies access decisions. A routing key, collection name and user account are different identities, even when a small demonstration gives them matching labels.

Bind queries to trusted scope

For an illustrative shared-document application, derive the authorized tenant scope from the authenticated request context. Form the intended predicate through the application’s controlled path. Do not accept a client-supplied tenant label as permission to read that label. Preserve the resulting filter in test logs without exposing document contents unnecessarily. The evaluation question is whether prohibited evidence can enter the candidate population, not merely whether the desired tenant’s documents rank first.

Test case	Required observation
Allowed source	Eligible evidence can be retrieved
Other tenant	Prohibited evidence remains outside the result
Missing scope	The application follows its defined rejection policy

Test negative cases explicitly

Use distinct document IDs with deliberately similar wording across tenants. Otherwise a weak test may pass because the wrong tenant has no semantically similar material. Check search, direct record access and any alternate retrieval paths exposed by the application separately. A successful predicate in one endpoint does not prove that every route constructs the same scope. Keep these as functional access tests rather than performance benchmarks.

Do not confuse visibility with permission

The consistency reference describes when writes become visible under selected read contracts. That is another axis from authorization. A prohibited document appearing later is still an access failure; a permitted new document missing temporarily may be a visibility question. Preserve both settings when diagnosing a result so changing consistency cannot conceal an incorrectly constructed tenant predicate.

Produce an auditable boundary record

Retain schema, tenant-key policy, trusted scope construction and negative fixtures together. State which data boundary was chosen and which application paths were tested. Recheck affected paths after introducing another retrieval operation or changing tenancy layout. The outcome should establish concrete evidence separation for the implemented system, not claim that enabling one database field automatically supplies complete multi-tenant security.