6 ms·

> This means Vector databases, Search Indexes or fancy "AI Search Databases" would be required on a per user basis or track the access rights along with the con

> This means Vector databases, Search Indexes or fancy "AI Search Databases" would be required on a per user basis or track the access rights along with the content, which is infeasible and does not scale. I don't understand why you think tracking user access rights would be infeasible and would not scale. There is a query. You search for matching documents in your vector database / index. Once you have found the potentially relevant list of documents you check which ones can the current user access. You only pass the ones over to the LLM which the user can see. This is very similar to how banks provide phone based services. The operator on the other side of the line can only see your account details once you have authenticated yourself. They can't accidentally tell you someone else's account balance, because they themselves don't have access to it unless they typed in all the information you provide them to authenticate yourself. You can't trick the operator to provide you with someone else's account balance because they can't see the account balance of anyone without authenticating first.

chaosite 1y ago
> You search for matching documents in your vector database / index. Once you have found the potentially relevant list of documents you check which ones can the current user access. You only pass the ones over to the LLM which the user can see. Sometimes the potentially relevant list of documents itself is a leak all by itself.
- redwood 1y ago
  But you process that list in a trusted audited app tier not in the client environment
  - lixtra 1y ago
    A naive approach could still leak information through side channels. E.g. if you search regularly for foobar, the answer might suddenly get slower if foobar appears more in the document base. Depending on the context it could be relevant.
    - shawnz 1y ago
      That's nothing specific to LLM-enhanced search features though, right? Any search feature will have that side channel risk
    - hannasanarion 1y ago
      But we're talking about access control, so in this case "filtering for foobar" means "filtering for stuff I'm allowed to see", and the whole point is that you can never turn that filter off to get a point of comparison. If Joe's search is faster than Sally's because Sally has higher permissions, that's hardly a revelation.
lukan 1y ago
Thank you for context, I wondered the same. But I guess they want something like training the chatbot as a LLM once with all the confidential data - and then indeed you could never separate it again.
doomslice 1y ago
Let's say you have 100000 documents in your index that match your query but only 10 of them the user has access to: A basic implementation will return the top, let's say 1000, documents and then do the more expensive access check on each of them. Most of the time, you've now eliminated all of your search results. Your search must be access aware to do a reasonable job of pre-filtering the content to documents the user has access to, at which point you then can apply post-filtering with the "100% sure" access check.
- thunky 1y ago
  > Let's say you have 100000 documents in your index that match your query If the docs were indexed by groups/roles and you had some form of RBAC then this wouldn't happen.
  - beaviskhan 1y ago
    If you take this approach, you have to reindex when groups/roles changes - not always a feasible choice
    - thunky 1y ago
      You only have to update the metadata, not do a full reindex.
      - scott_w 1y ago
        You'd have to reindex the metadata (roles access), which may be substantial if you have a complex enough schema with enough users/roles.
        thunky 1y ago
        > You'd have to reindex the metadata (roles access), which may be substantial if you have a complex enough schema with enough users/roles. Right, but this compare this to the original proposal: > A basic implementation will return the top, let's say 1000, documents and then do the more expensive access check on each of them Using an index is much better than that. And it should be possible to update the index without a substantial cost, since most of the 100000 documents likely aren't changing their role access very often. You only have to reindex a document's metadata when that changes. This is also far less costly than updating the actual content index (the vector embeddings) when the document content changes, which you have to do regardless of your permissions model.
scott_w 1y ago
> I don't understand why you think tracking user access rights would be infeasible and would not scale. Allow me to try to inject my understanding of how these agents work vs regular applications. A regular SaaS will have an API endpoint that has permissions attached. Before the endpoint processes anything, the user making the request has their permissions checked against the endpoint itself. Once this request succeeds, anything that endpoint collects is considered "ok" ship to the user. AI Agents, instead, directly access the database, completely bypassing this layer. That means you need to embed the access permissions into the individual rows, rather than at the URL/API layer. It's much more complex as a result. For your bank analogy: they actually work in a similar way to how I described above. A temporary access is granted to the resources but, once it's granted, any data included in those screens is assumed to be ok. They won't see something like a blank box somewhere because there's info they're not supposed to see. DISCLAIMER: I'm making an assumption on how these AI Agents work, I could be wrong.
- GloriousMEEPT 1y ago
  The solution to this problem is to develop your agents to use delegation and exchange tokens for access to other services using an on-behalf-of flow. Agents are never operating under their own identity, but as the user.
- pc86 1y ago
  > I'm making an assumption on how these AI Agents work, I could be wrong. I don't understand the desire - borderline need - of folks on HN to just make stuff up. That is likely why you're being downvoted. I know we all love to do stuff "frOM fIRsT PRiNcIPlEs" around here but "let me just imagine how I think AI agents work then pass that off as truth" is taking it a bit far IMO. This is the human equivalent of an AI hallucination. You are just making stuff up, passing it off as truth ("injecting your understanding"), then adding a one-line throwaway "this might be completely wrong lol" at the end.
  - scott_w 1y ago
    And yet if we didn't do this, HN would be almost completely silent because 99% of commenters have a clue what they're talking about most of the time and nobody would ever have a chance to learn.
planb 1y ago
I’ll answer to this as a placeholder for all the „just do xyz“ replies: Searching the whole index and then filtering is possible, but infeasible for large indexes where a specific user only has access to a few docs. And for diverse data sources (as we want to access), this would be really slow, many systems would need to be checked. So, access rights should be part of the index. In that case, we are just storing a copy of the access rights, so this is prone to races. Besides that, we have multiple systems with different authorization systems, groups, roles, whatever. To homogenize this, we would need to store the info down to each individual user. Besides this, not all systems even support asking which users have access to resource Y, they only allow to ask „has X access to Y“.

chaosite 1y ago

> You search for matching documents in your vector database / index. Once you have found the potentially relevant list of documents you check which ones can the current user access. You only pass the ones over to the LLM which the user can see. Sometimes the potentially relevant list of documents itself is a leak all by itself.

redwood 1y ago
But you process that list in a trusted audited app tier not in the client environment
- lixtra 1y ago
  A naive approach could still leak information through side channels. E.g. if you search regularly for foobar, the answer might suddenly get slower if foobar appears more in the document base. Depending on the context it could be relevant.
  - shawnz 1y ago
    That's nothing specific to LLM-enhanced search features though, right? Any search feature will have that side channel risk
  - hannasanarion 1y ago
    But we're talking about access control, so in this case "filtering for foobar" means "filtering for stuff I'm allowed to see", and the whole point is that you can never turn that filter off to get a point of comparison. If Joe's search is faster than Sally's because Sally has higher permissions, that's hardly a revelation.

lukan 1y ago

Thank you for context, I wondered the same. But I guess they want something like training the chatbot as a LLM once with all the confidential data - and then indeed you could never separate it again.

doomslice 1y ago

Let's say you have 100000 documents in your index that match your query but only 10 of them the user has access to: A basic implementation will return the top, let's say 1000, documents and then do the more expensive access check on each of them. Most of the time, you've now eliminated all of your search results. Your search must be access aware to do a reasonable job of pre-filtering the content to documents the user has access to, at which point you then can apply post-filtering with the "100% sure" access check.

thunky 1y ago
> Let's say you have 100000 documents in your index that match your query If the docs were indexed by groups/roles and you had some form of RBAC then this wouldn't happen.
- beaviskhan 1y ago
  If you take this approach, you have to reindex when groups/roles changes - not always a feasible choice
  - thunky 1y ago
    You only have to update the metadata, not do a full reindex.
    - scott_w 1y ago
      You'd have to reindex the metadata (roles access), which may be substantial if you have a complex enough schema with enough users/roles.
      - thunky 1y ago
        > You'd have to reindex the metadata (roles access), which may be substantial if you have a complex enough schema with enough users/roles. Right, but this compare this to the original proposal: > A basic implementation will return the top, let's say 1000, documents and then do the more expensive access check on each of them Using an index is much better than that. And it should be possible to update the index without a substantial cost, since most of the 100000 documents likely aren't changing their role access very often. You only have to reindex a document's metadata when that changes. This is also far less costly than updating the actual content index (the vector embeddings) when the document content changes, which you have to do regardless of your permissions model.

scott_w 1y ago

> I don't understand why you think tracking user access rights would be infeasible and would not scale. Allow me to try to inject my understanding of how these agents work vs regular applications. A regular SaaS will have an API endpoint that has permissions attached. Before the endpoint processes anything, the user making the request has their permissions checked against the endpoint itself. Once this request succeeds, anything that endpoint collects is considered "ok" ship to the user. AI Agents, instead, directly access the database, completely bypassing this layer. That means you need to embed the access permissions into the individual rows, rather than at the URL/API layer. It's much more complex as a result. For your bank analogy: they actually work in a similar way to how I described above. A temporary access is granted to the resources but, once it's granted, any data included in those screens is assumed to be ok. They won't see something like a blank box somewhere because there's info they're not supposed to see. DISCLAIMER: I'm making an assumption on how these AI Agents work, I could be wrong.

GloriousMEEPT 1y ago
The solution to this problem is to develop your agents to use delegation and exchange tokens for access to other services using an on-behalf-of flow. Agents are never operating under their own identity, but as the user.
pc86 1y ago
> I'm making an assumption on how these AI Agents work, I could be wrong. I don't understand the desire - borderline need - of folks on HN to just make stuff up. That is likely why you're being downvoted. I know we all love to do stuff "frOM fIRsT PRiNcIPlEs" around here but "let me just imagine how I think AI agents work then pass that off as truth" is taking it a bit far IMO. This is the human equivalent of an AI hallucination. You are just making stuff up, passing it off as truth ("injecting your understanding"), then adding a one-line throwaway "this might be completely wrong lol" at the end.
- scott_w 1y ago
  And yet if we didn't do this, HN would be almost completely silent because 99% of commenters have a clue what they're talking about most of the time and nobody would ever have a chance to learn.

planb 1y ago

I’ll answer to this as a placeholder for all the „just do xyz“ replies: Searching the whole index and then filtering is possible, but infeasible for large indexes where a specific user only has access to a few docs. And for diverse data sources (as we want to access), this would be really slow, many systems would need to be checked. So, access rights should be part of the index. In that case, we are just storing a copy of the access rights, so this is prone to races. Besides that, we have multiple systems with different authorization systems, groups, roles, whatever. To homogenize this, we would need to store the info down to each individual user. Besides this, not all systems even support asking which users have access to resource Y, they only allow to ask „has X access to Y“.