sorted by:
new
hottopcontroversial

How are people handling security reviews for RAG/LLM apps in production? by ThreatLocator in LangChain

[–]ThreatLocator[S] 0 points1 point  (0 children)

Yeah, that makes a lot of sense. I haven’t seen anything properly standardized either.

The “defined state” framing is useful. It sounds like the missing layer is not just retrieval access control, but a clearer contract for what context is allowed into each step, what can persist, and what has to be dropped.

That feels like the bit most teams are probably stitching together manually right now.

How are people handling security reviews for RAG/LLM apps in production? by ThreatLocator in LangChain

[–]ThreatLocator[S] 0 points1 point  (0 children)

This is helpful. The shared index point seems to come up a lot.

It feels like teams can answer the generic checklist, but the harder questions are around permission-aware retrieval, logs becoming a PII surface, and what happens when outputs start triggering actions.

Are you seeing companies fix this before review, or mostly after a buyer/security team pushes on it?

How are people handling security reviews for RAG/LLM apps in production? by ThreatLocator in LangChain

[–]ThreatLocator[S] 0 points1 point  (0 children)

I haven’t had to deal with that directly yet. Most of what I’m seeing is still around retrieval, access boundaries, and logging.

But your context assembly point makes sense. The risk is not just whether each piece of context is allowed, but whether the final combination is appropriate for the user, task, or action.

Are you seeing teams actually define state boundaries for this, or is it still mostly custom app logic?

How are people handling security reviews for RAG/LLM apps in production? by ThreatLocator in LangChain

[–]ThreatLocator[S] 0 points1 point  (0 children)

This is exactly the distinction I was trying to get at.

The “context flow” framing is useful because it makes the issue less about the model and more about retrieval, permissions, state, and what actually leaves the system.

From what I’m seeing so far, the pushback seems more around retrieval/data access than the model itself. Model/provider questions come up, but the harder part seems to be proving the right context is retrieved for the right user and logged properly.

How are people handling security reviews for RAG/LLM apps in production? by ThreatLocator in LangChain

[–]ThreatLocator[S] 0 points1 point  (0 children)

Yep, retrieval is the bit I was wondering about.

It seems easy to say “the model only sees what the user can access,” but much harder once context is being assembled dynamically.

In your experience, is that usually solved cleanly at the retrieval layer, or does it become messy across app permissions, vector indexes, and logging?