Can this API prove who is allowed to see this record?

Before you sync any SaaS source into a shared memory layer, ask its API one question. Not "is it permission-aware," which every vendor answers yes to. Ask this: for this one record, can you prove who is allowed to see it? The answer sorts every connector you will ever write onto four rungs, and it tells you where you are safe and where you are guessing.

The one question that sorts every connector

An agent asks your memory layer: what do we know about the Acme renewal? Somewhere in Drive, Salesforce, Notion, and Intercom there are records that answer it. Some of those records the asking user is allowed to see. Some they are not. Your job is to return only the first set.

To do that you need each source to answer a narrow question about each record: who is allowed to see this? Marketing pages will tell you a product is 'permission-aware' or 'respects your permissions.' That phrase covers everything from a real per-file ACL to a shrug. The useful question is sharper, and it is about proof. Can the API hand you, per record, an audience you can stand behind?

Sources answer that question at four different strengths. Rank them by strength and you get a ladder. The rung a source lands on decides how much you can trust it, and what the safe fallback is when it lets you down.

Rung 1, mirrored: the API hands you the audience

The top rung is the easy one. The API returns real per-item sharing, and you mirror it.

Google Drive is the clean example. Call permissions.list on a file and you get the actual grants: this user, that group, this domain, anyone-with-link. Expand nested Google Group membership through the Directory API and you have the transitive audience. The file tells you who can open it, so your memory layer knows who can recall it.

On this rung the ACL is not inferred. It is copied. Verity tags these facts with provenance mirrored, because that is what they are, a faithful copy of the source's own decision. If the sharing changes at the source, a watch event updates the copy. This is the rung you want every source to be on. Most are not.

On this rung the ACL is not inferred. It is copied.

Rung 2, reconstructed and oracle-checked

The second rung has no single field that hands you the audience, but the pieces are all there, and the source will grade your work.

Salesforce is the case. There is no visible_to endpoint on a record. Visibility falls out of org-wide defaults, the role hierarchy, ownership, sharing tables, and View-All permissions. You reconstruct it from those inputs. That is real work, and it is easy to get subtly wrong.

What lifts Salesforce onto rung 2 instead of rung 3 is that it exposes its own answer. UserRecordAccess lets you ask Salesforce directly whether a given user can see a given record. So you reconstruct the audience, then check your reconstruction against the source's own oracle and count the disagreements. Verity's Salesforce fidelity harness did exactly this and measured zero disagreements, on a trial org with synthetic data. That is the honest scope of the claim, not a production org at scale. And parts of the model, sharing rules and territories, are still deferred until a real org can measure them. A reconstruction you can grade against the source is worlds apart from one you cannot.

A reconstruction you can grade against the source is worlds apart from one you cannot.

Rung 3, approximated: no per-record audience, so you build a floor

The third rung is where honesty starts doing the work. The API exposes no per-record audience at all. There is nothing to mirror and no oracle to check against.

Notion is the example everyone hits. The public Notion API returns page content and properties, but it does not tell you who a page is shared with. There is no per-page permissions list. So you cannot answer the one question from the record itself.

The move here is to refuse to guess. You fall back to a coarser boundary you can actually defend, a workspace or admin-assigned visibility floor, and fail closed to it. Notion content in Verity rides an admin-assigned floor and carries provenance approximated, never mirrored. Intercom is the same shape: a conversation rides the operator-declared teammate-audience floor plus the resolved assignee as a provable superset, and unassigned conversations fail closed. The floor is deliberately too tight rather than too loose. It will hide things the user could actually see. That is the trade, and it is the right one.

The floor is deliberately too tight rather than too loose.

Rung 4, no audience at all: quarantine, don't guess

The bottom rung is for records where you cannot prove the audience and you do not even have a trustworthy floor to fall back to. A payload arrives with no resolvable ACL, or every principal on it is unmappable, or the source shape is one you have no policy for.

The wrong instinct is to index it with a best guess and move on. In a shared memory layer that agents read from, a wrong guess is not a broken sync. It is customer B's data surfacing to customer A. So the rule is quarantine. The record is held, visible only in audit, never indexed permissively. An item with no visibility tokens stays invisible, a query with no resolvable subject returns empty, and a connector that cannot map an ACL holds the item rather than indexing it.

This is the same principle as rung 3, taken to its end. When the API cannot prove the audience, the only safe move is to over-hide. On rung 3 that means a tight floor. On rung 4 it means the record does not enter shared memory at all until a human resolves it.

When the API cannot prove the audience, the only safe move is to over-hide.

How to place a new source in five minutes

When you pick up a source you have not integrated, you can place it on the ladder before writing a line of connector code. Read the API docs for one thing: the per-record read path, and whether anything on it carries an audience.

Is there a per-item permissions or sharing endpoint that returns real grants? Rung 1. No such field, but the inputs to visibility exist and there is an access-check endpoint to verify against? Rung 2. Content comes back but nothing about who can see it, and the best you have is a workspace or team boundary? Rung 3, and you build a fail-closed floor. Not even that? Rung 4, and it quarantines until you supply a policy.

Bookmark the rung, not the vendor. Vendors move. An API that adds a real sharing endpoint climbs a rung, and one that deprecates a permissions scope drops one. The ladder is the durable thing.

Bookmark the rung, not the vendor. Vendors move; the ladder is the durable thing.

The honest part: rungs 3 and 4 are approximations, and they over-hide

Rungs 1 and 2 mirror or verify a real audience. Rungs 3 and 4 do not, and pretending otherwise would sink the whole thing.

Verity does not claim Notion-style sources give per-record ACLs they do not have. On rung 3 it fails closed to an admin-assigned floor and over-hides. That is a real cost, not a footnote: some records a user could see in the source get hidden in recall, because the API gave us no way to prove they were shareable to that user. On rung 4 the record does not get indexed at all until a human maps it. We would rather an agent miss a document the user was entitled to than surface one they were not. That asymmetry is the deliberate trade on the weak rungs, and it is why the provenance tag on every fact says mirrored, approximated, or quarantined out loud instead of flattening them into one 'permission-aware' badge.

Two more limits worth stating plainly. Fidelity on every rung is only as good as what the source API exposes, so a source that quietly changes its sharing model can move under you. And the Salesforce oracle result, zero disagreements, was measured on a trial org with synthetic data, not proof for every production org.

Walk your own sources down the ladder, and run the fidelity harness against your own org: github.com/RunAlphaLoop/verity