Relevance and permission answer different questions
A record can be highly relevant to a query and still be outside the caller’s access. A useful retrieval design treats eligibility as part of the application boundary rather than assuming that ranking will make the decision.
Keep tenant, account, ownership, or other scope identifiers with source records where the application needs them. Decide how those identifiers map to the supported query path and your authorization model.
Carry scope through preparation
When documents become passages or entities become graph nodes, preserve the information needed to determine which records belong to the intended scope. Losing it during preparation can make later retrieval difficult to constrain correctly.
Relationships need attention too. A graph expansion can cross from an allowed starting record to a connected record with a different access boundary. Model and enforce the intended behavior in the application.
Do not assume synchronization copies application policy
A synchronized Postgres project copies selected data for retrieval. That does not establish that every source application rule, authentication integration, or row-level access behavior is reproduced automatically in the retrieval application.
Review the documented Polygres access mechanisms alongside your own application model. Keep privileged project operations separate from end-user query flows and avoid exposing server credentials in browser code.
Test the boundary with real cases
Include questions from more than one tenant or account in your evaluation. Check both direct retrieval and connected-record expansion, and inspect the identifiers of every returned record.
A safe design should be understandable without relying on the model to ignore unauthorized context. Decide what evidence the application is allowed to retrieve before passing that evidence to answer generation.
Explore the next step
Continue with the platform guide. For the current setup and API contract, use the Polygres documentation.