The same permission boundary, through six agent frameworks

If you put a shared memory store behind your agents through a framework like LangChain or LangGraph, you are trusting that framework's memory API with a boundary. Team A's data and team B's data sit in the same store. The question is whether team B's agent can pull team A's memory back through a normal retrieval call. We wrote a harness that tries to make exactly that happen, across six frameworks. It does not.

What the harness does

The harness drives the real framework, not our client. For LangChain it calls the retriever through as_retriever().invoke(); for LangGraph it goes through the BaseStore search; for LlamaIndex, CrewAI, Google ADK, and the OpenAI Agents SDK it uses each one's own memory interface. Verity sits underneath as the backing store, so what gets tested is the path a real integration takes.

For each framework it runs the same three checks. A roundtrip: write documents under a policy, read them back, confirm the content is there. An isolation check: write a secret under team A's policy, then, under team B's policy, run a query that semantically matches that secret and confirm none of team A's content comes back. And a construction check: building a store with no visibility policy raises an error instead of quietly defaulting to something permissive.

The isolation check is the one that matters, and it is deliberately not a soft test. Team A writes that the falcon-3 budget is 1.2M. Team B queries for the falcon-3 budget. That query matches. Team B still gets nothing of team A's, and then, once team B has written its own note, it can read that back while still seeing none of A's. So the empty result is the boundary holding, not the search being broken.

The empty result is the boundary holding, not the search being broken.

Why it holds

The boundary is not in the framework and not in the model. It is in the index. When team B's retriever runs, Verity mints a scope from team B's policy and compiles it into the retrieval query as a mandatory pre-filter. Team A's chunks are never in the candidate set, so there is nothing for the framework or the model to accidentally surface.

That is the difference from filtering after retrieval. A post-filter can be forgotten by a re-ranker, a tool that queries the store directly, or a cache that outlives it, and when it is forgotten the failure is open: you get data instead of nothing. A pre-filter in the index fails the other way. If the scope is missing, the result is empty.

A missing filter fails closed, not open.

From a policy to a real person

The checks above bind each store to a policy: a set of visibility tokens you assign. That is the honest shape of this lane, and I will come back to why. But the LangChain adapter can also bind to a real person and let the server work out what they are allowed to see.

A subject-bound retriever is constructed for a subject like user:alice@acme, not a token. On each read it mints a scope with that subject, and the server resolves it through the permission graph. Alice is in engineering, engineering is in all-staff, so alice inherits what all-staff can see: a document shared with all-staff comes back for her. For bob, who is in no group, the same query returns nothing. The agent never holds a token; the powers are resolved below it, server-side.

The two-agent demo does the same thing over MCP, and it holds even when bob's agent tries a prompt injection to pry the document loose. The filter already ran, one layer under where the prompt can reach.

The agent never holds a token; the powers are resolved below it.

The honest part

This lane is policy-based, and that is a real limit to be clear about. When you load documents through a framework's community loaders, those loaders strip whatever access controls the source system had. So here you assign visibility explicitly at ingest; Verity does not mirror your Google Drive or Salesforce ACLs on this path. Mirroring live source ACLs is a different lane, the connector plane, not the framework adapter.

The harness is a test suite, not a third-party audit. It runs against synthetic tenants with planted secrets, and it grades itself: two dozen tests, a roundtrip and an isolation check and a fail-closed construction check per framework. It is reproducible and I stand behind it, but nobody outside the project has signed anything, and there are no production users yet.

And the identity-inheritance path is proven through the LangChain adapter today. The other five adapters are exercised on the policy-based isolation checks; wiring subject resolution through each of them is on the list, not done.

The harness is one command (integrations/run_e2e.sh). Run it against your own stack and tell me where it falls over: github.com/RunAlphaLoop/verity