Search Authorizationは検索集合と認可集合のIntersection問題になる
Search AuthorizationはList Authorizationより難しい。検索条件、全文検索・vector search、sort、paginationをApplication DB/Search Engineが担当し、細粒度認可を別systemが担当する場合、最終結果は 検索集合と認可集合のintersection になる。
OpenFGAは2026年8月時点の公式docsでこの問題をそのまま「Search With Permissions」として整理している。選択肢は大きく、(1) searchしてからBatch Check、(2) authorization changesからlocal indexを作ってintersection、(3) ListObjectsでaccessible IDsを得てからDB検索、の3系統である。どれが適切かは検索候補数、accessible object数、全体に占める許可率で変わる。
これは単一 Can() APIだけをAuthorization abstractionにすると不足する具体例である。例えばvector searchでは、top-kを取得してからdenyを除くと結果がk件未満になり、さらに検索し直す必要がある。逆に許可IDをすべて先に列挙する方式は、accessible setが巨大だと破綻する。
RAGでも同じ問題がsecurity boundaryになる。OpenFGAは、LLMへ渡す前にretrieval結果をpermissionでfilterすることを推奨し、pre-filterとpost-filterのtrade-offを扱っている。
したがってApplication Protocolでは、Search Operation自身がauthorization strategyをownershipするか、AuthorizerがListAuthorizedResources/predicate/indexのような集合向けinterfaceを持つ必要がある。
ただし認可systemへ検索metadataまで複製するとsource of truthが二重化する。OpenFGA自身もfilter/sort/joinに必要なdataはApplication DB側へ置くことを勧めている。Authorization GraphはResource Hierarchyとは別のRelationship Graphとして持つ を検索indexそのものにしないことが重要である。